From n.oxyde@REDACTED Sun Feb 2 14:48:36 2014
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Sun, 2 Feb 2014 14:48:36 +0100
Subject: [erlang-patches] Rewrite merge of clause variable tables (in
case, try, etc)
In-Reply-To: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com>
References: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com>
Message-ID:
Thinking twice about this patch, it should probably be done another way, with a function taking the accumulated variable table from the merging of previous clauses, the variable table of the current clause, and the variable table of the surrounding environment. It currently relies too much on the implementation details of orddict, I think.
--
Anthony Ramine
Le 14 nov. 2013 ? 13:26, Anthony Ramine a ?crit :
> Hello,
>
> I have finally got around fixing the two regressions reported in R16B02 with regard to unused variable warnings.
>
> The fix was more complicated than what I expected it to be.
>
> git fetch https://github.com/nox/otp.git fix-exporting-rules
>
> https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules
> https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules.patch
>
> Regards,
>
> --
> Anthony Ramine
>
From florz@REDACTED Mon Feb 3 06:38:46 2014
From: florz@REDACTED (Florian Zumbiehl)
Date: Mon, 3 Feb 2014 06:38:46 +0100
Subject: [erlang-patches] [PATCH] crypto: fix a few memleaks/undefined
pointer dereferences
In-Reply-To: <52B45EA6.6020703@ericsson.com>
References: <20131216121905.GO5636@florz.florz.dyndns.org>
<52AF1B0A.3010704@erix.ericsson.se>
<20131216162423.GX5636@florz.florz.dyndns.org>
<52B45EA6.6020703@ericsson.com>
Message-ID: <20140203053845.GA29730@florz.florz.dyndns.org>
Hi,
> A simple fix to this would be to let the crypto_alloc (in
> crypto_callback.c) to call abort() if the allocation failed as that
> is the strategy otherwise in out-of-memory scenarios. Thus a "nice
> crash" with an "Out of memory" message instead of a segmentation
> violation.
below you find a patch that does just that. I hope it can still make it
into R17? Mind you, pointer arithmetic with and dereference of null
pointers give undefined behaviour, not (necessarily just) a segfault, so
this could have security implications.
Regards, Florian
diff --git a/lib/crypto/c_src/crypto_callback.c b/lib/crypto/c_src/crypto_callback.c
index 81106b4..750e9b1 100644
--- a/lib/crypto/c_src/crypto_callback.c
+++ b/lib/crypto/c_src/crypto_callback.c
@@ -53,11 +53,19 @@ static ErlNifRWLock** lock_vec = NULL; /* Static locks used by openssl */
static void* crypto_alloc(size_t size)
{
- return enif_alloc(size);
+ void *ret;
+
+ if (!(ret = enif_alloc(size)) && size)
+ abort();
+ return ret;
}
static void* crypto_realloc(void* ptr, size_t size)
{
- return enif_realloc(ptr, size);
+ void *ret;
+
+ if (!(ret = enif_realloc(ptr, size)) && size)
+ abort();
+ return ret;
}
static void crypto_free(void* ptr)
{
From henrik@REDACTED Mon Feb 3 10:09:43 2014
From: henrik@REDACTED (Henrik Nord)
Date: Mon, 3 Feb 2014 10:09:43 +0100
Subject: [erlang-patches] [erlang-bugs] erlang.el indenter
In-Reply-To:
References: <5034B0F9.2000007@erlang.org> <52E27ECB.4060801@erlang.org>
Message-ID: <52EF5CD7.6070805@erlang.org>
Ok!
I will consider this particular patch closed.
If anyone does find the time to implement the other suggestion they will
have to submit a new patch
Thank you for your contributions!
On 2014-01-27 00:25, Steve Vinoski wrote:
>
>
>
> On Fri, Jan 24, 2014 at 11:49 AM, Tuncer Ayaz > wrote:
>
> On Fri, Jan 24, 2014 at 3:55 PM, Henrik Nord > wrote:
> > Ping?!
> >
> > Any update regarding this?
>
> Fredrik's patch introduced a regression, so should not be merged, but
> the bugs in the indenter are still there.
>
> Steve Vinoski also analyzed the issues a couple days ago, and he has
> a more complete understanding of the Elisp code. Steve, can you
> summarize what's broken?
>
>
> In August 2013 Magnus Henoch posted a suggestion to use emacs syntax
> properties to solve these kinds of issues:
>
> http://erlang.org/pipermail/erlang-bugs/2013-August/003729.html
>
> I agree that's the right way to go, but I don't think it's a small
> amount of work.
>
> --steve
--
/Henrik Nord Erlang/OTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From n.oxyde@REDACTED Mon Feb 3 14:10:24 2014
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Mon, 3 Feb 2014 14:10:24 +0100
Subject: [erlang-patches] [erlang-bugs] erlang.el indenter
In-Reply-To: <52EF5CD7.6070805@erlang.org>
References: <5034B0F9.2000007@erlang.org> <52E27ECB.4060801@erlang.org>
<52EF5CD7.6070805@erlang.org>
Message-ID:
As much as I hate GitHub, that sounds like a good use case for its Issues system.
--
Anthony Ramine
Le 3 f?vr. 2014 ? 10:09, Henrik Nord a ?crit :
> If anyone does find the time to implement the other suggestion they will have to submit a new patch
From daniel.goertzen@REDACTED Mon Feb 3 18:35:36 2014
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Mon, 3 Feb 2014 11:35:36 -0600
Subject: [erlang-patches] R17.0-rc1 patch for gzio.c compile breakage.
Message-ID:
A dependency on zlib.h was recently removed (commit 8a147a7365). This also
removes the definition of the macro "OF" which is required by gzio.c. Now
"OF" is evidently defined by other headers on some systems, but on at least
Gentoo Linux this is not the case.
OF was needed to support compilation on now ancient C compilers. I assume
R17 and newer doesn't need to support ancient C compilers. See details at
http://stackoverflow.com/questions/7299310/of-macro-in-iowin32-h
The attached patch removes usage of OF in gzio.c
Regards,
Dan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gzio_OF.patch
Type: text/x-patch
Size: 1104 bytes
Desc: not available
URL:
From sverker.eriksson@REDACTED Tue Feb 4 12:30:28 2014
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Tue, 4 Feb 2014 12:30:28 +0100
Subject: [erlang-patches] [PATCH] crypto: fix a few memleaks/undefined
pointer dereferences
In-Reply-To: <20140203053845.GA29730@florz.florz.dyndns.org>
References: <20131216121905.GO5636@florz.florz.dyndns.org>
<52AF1B0A.3010704@erix.ericsson.se>
<20131216162423.GX5636@florz.florz.dyndns.org>
<52B45EA6.6020703@ericsson.com>
<20140203053845.GA29730@florz.florz.dyndns.org>
Message-ID: <52F0CF54.5030709@ericsson.com>
Thanks, I'll include this for 17.0-rc2.
/Sverker
On 02/03/2014 06:38 AM, Florian Zumbiehl wrote:
> Hi,
>
>> A simple fix to this would be to let the crypto_alloc (in
>> crypto_callback.c) to call abort() if the allocation failed as that
>> is the strategy otherwise in out-of-memory scenarios. Thus a "nice
>> crash" with an "Out of memory" message instead of a segmentation
>> violation.
> below you find a patch that does just that. I hope it can still make it
> into R17? Mind you, pointer arithmetic with and dereference of null
> pointers give undefined behaviour, not (necessarily just) a segfault, so
> this could have security implications.
>
> Regards, Florian
>
> diff --git a/lib/crypto/c_src/crypto_callback.c b/lib/crypto/c_src/crypto_callback.c
> index 81106b4..750e9b1 100644
> --- a/lib/crypto/c_src/crypto_callback.c
> +++ b/lib/crypto/c_src/crypto_callback.c
> @@ -53,11 +53,19 @@ static ErlNifRWLock** lock_vec = NULL; /* Static locks used by openssl */
>
> static void* crypto_alloc(size_t size)
> {
> - return enif_alloc(size);
> + void *ret;
> +
> + if (!(ret = enif_alloc(size)) && size)
> + abort();
> + return ret;
> }
> static void* crypto_realloc(void* ptr, size_t size)
> {
> - return enif_realloc(ptr, size);
> + void *ret;
> +
> + if (!(ret = enif_realloc(ptr, size)) && size)
> + abort();
> + return ret;
> }
> static void crypto_free(void* ptr)
> {
From bjorn@REDACTED Tue Feb 4 15:27:42 2014
From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=)
Date: Tue, 4 Feb 2014 15:27:42 +0100
Subject: [erlang-patches] R17.0-rc1 patch for gzio.c compile breakage.
In-Reply-To:
References:
Message-ID:
On Mon, Feb 3, 2014 at 6:35 PM, Daniel Goertzen
wrote:
> A dependency on zlib.h was recently removed (commit 8a147a7365). This also
> removes the definition of the macro "OF" which is required by gzio.c. Now
> "OF" is evidently defined by other headers on some systems, but on at least
> Gentoo Linux this is not the case.
The OF() macro is defined in zconf.h, which is included by zlib.h, so
I don't understand why the build should break on Gentoo Linux.
But since the use of OF() is completely unnecessary and is an
unnecessary dependency I have written a commit message for your
patch and included it in our daily builds.
git fetch git@REDACTED:bjorng/otp.git bjorn/erts/zlib-1.2.8/OTP-11669
/Bjorn
--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
From daniel.goertzen@REDACTED Tue Feb 4 16:16:54 2014
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Tue, 4 Feb 2014 09:16:54 -0600
Subject: [erlang-patches] R17.0-rc1 patch for gzio.c compile breakage.
In-Reply-To:
References:
Message-ID:
Thank you for the merge. And you piqued my curiosity as to the why.
My gentoo zconf.h defines the macro as _Z_OF instead of OF. Digging
deeper, they made the change on the premise that OF is a stupid, polluting
name for an internal macro. There was disagreement as to the value of the
change (https://bugs.gentoo.org/show_bug.cgi?id=383179)
Dan.
On Tue, Feb 4, 2014 at 8:27 AM, Bj?rn Gustavsson wrote:
> On Mon, Feb 3, 2014 at 6:35 PM, Daniel Goertzen
> wrote:
> > A dependency on zlib.h was recently removed (commit 8a147a7365). This
> also
> > removes the definition of the macro "OF" which is required by gzio.c.
> Now
> > "OF" is evidently defined by other headers on some systems, but on at
> least
> > Gentoo Linux this is not the case.
>
> The OF() macro is defined in zconf.h, which is included by zlib.h, so
> I don't understand why the build should break on Gentoo Linux.
>
> But since the use of OF() is completely unnecessary and is an
> unnecessary dependency I have written a commit message for your
> patch and included it in our daily builds.
>
> git fetch git@REDACTED:bjorng/otp.git bjorn/erts/zlib-1.2.8/OTP-11669
>
> /Bjorn
>
> --
> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bjorn@REDACTED Tue Feb 4 17:14:18 2014
From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=)
Date: Tue, 4 Feb 2014 17:14:18 +0100
Subject: [erlang-patches] R17.0-rc1 patch for gzio.c compile breakage.
In-Reply-To:
References:
Message-ID:
On Tue, Feb 4, 2014 at 4:16 PM, Daniel Goertzen
wrote:
> Thank you for the merge. And you piqued my curiosity as to the why.
>
> My gentoo zconf.h defines the macro as _Z_OF instead of OF. Digging deeper,
> they made the change on the premise that OF is a stupid, polluting name for
> an internal macro. There was disagreement as to the value of the change
> (https://bugs.gentoo.org/show_bug.cgi?id=383179)
>
Thanks for the additional information. I have updated the commit message.
/Bjorn
--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
From lukas@REDACTED Tue Feb 4 18:24:37 2014
From: lukas@REDACTED (Lukas Larsson)
Date: Tue, 4 Feb 2014 18:24:37 +0100
Subject: [erlang-patches] Fix DTrace build on Illumos
In-Reply-To:
References:
<52A71690.7000808@erlang.org>
Message-ID: <52F12255.6050704@erlang.org>
Hello Ryan,
I just noticed that you removed the "2> /dev/null" for the 2STEP_TEST in
erts/configure.in. Was there a reason for doing that? As it is now when
the test fails on osx in prints the output of the dtrace command to the
shell which is not really what you want.
Lukas
On 15/01/14 23:32, Ryan Zezeski wrote:
> Any news? Would be nice if R17 worked with DTrace on latest Illumos
> kernel.
>
>
> On Tue, Dec 10, 2013 at 8:26 AM, Henrik Nord > wrote:
>
> Thank you for your contribution !
>
> patch has been assigned to be reviewed
>
>
>
> On 2013-12-07 22:00, Ryan Zezeski wrote:
>> https://github.com/erlang/otp/pull/156
>>
>> This patch fixes the configure and Makefile scripts to work with
>> newer DTrace. This applies to all Illumos derivatives including
>> OpenIndiana, SmartOS and OmnioOS. I've copied the commit message
>> here verbatim.
>>
>> --- SNIP ---
>>
>> Fix DTrace build on Illumos
>>
>> DTrace was recently patched in Illumos to fail to create an
>> object
>> file if no probes are found.
>>
>> * https://www.illumos.org/issues/4248
>> *
>> https://github.com/illumos/illumos-gate/commit/54a20ab41aadcb81c53e72fc65886e964e9add59
>>
>> This patch fixes two issues:
>>
>> * Modify the configure script to pass an object file to
>> `dtrace -G`
>> that actually invokes a probe.
>>
>> * Remove creation of `dtrace_user.o` from the dyntrace
>> Makefile. In a
>> previous commit [1] Scott Fritchie relocated all the user
>> probes
>> into the VM proper due to difficulties with DTrace probes
>> in shared
>> libraries. The `dtrace_user.d` file is now empty and
>> generates a
>> header file with nothing in it. There is no longer any
>> reason to
>> generate `dtrace_user.o` because all the probes are in the
>> VM. Thus
>> all the steps for building `dtrace_user.o` have been removed.
>>
>> [1]:
>> https://github.com/erlang/otp/commit/75552bd3bb4e7f3cf4dab81a5c81cf73b1d3fb99
>>
>> --- END SNIP ---
>>
>> -Z
>>
>>
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-patches
>
> --
> /Henrik Nord Erlang/OTP
>
>
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sverker.eriksson@REDACTED Tue Feb 4 18:45:54 2014
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Tue, 4 Feb 2014 18:45:54 +0100
Subject: [erlang-patches] run_erl: propagate exit status
In-Reply-To: <4ED5061D.2050801@erix.ericsson.se>
References:
<4ED5061D.2050801@erix.ericsson.se>
Message-ID: <52F12752.7030702@erix.ericsson.se>
Magnus ! ping.
Any interest in trying to get this two year old patch into OTP 17?
The feature of propagating exit status seems reasonable and useful.
/Sverker, Erlang/OTP
On 11/29/2011 05:19 PM, Sverker Eriksson wrote:
> Henrik:
>
> This one should replace the current mh/run_erl-exit-status in pu:
>
> git fetch git://github.com/legoscia/otp.git run_erl_exit_status_simple
>
>
> Magnus:
>
> I got two objections on the the other version using select timeout.
>
> 1. You don't check if it actually was a timeout from select() before
> doing "want_to_exit = 1".
> 2. No test that reproduces the more complicated case.
>
> /Sverker
>
>
> Magnus Henoch wrote:
>> Good catch, exit() is indeed not safe inside a signal handler, as it
>> flushes stdio buffers etc.
>>
>> I committed a new version that uses a select timeout:
>>
>> git fetch git://github.com/legoscia/otp.git run_erl_exit_status
>> https://github.com/legoscia/otp/commit/run_erl_exit_status
>>
>> But since I still haven't been able to reproduce the case that the
>> alarm is supposed to handle, I also committed a simpler change
>> that leaves the alarm signal as it used to be:
>>
>> git fetch git://github.com/legoscia/otp.git run_erl_exit_status_simple
>> https://github.com/legoscia/otp/commit/run_erl_exit_status_simple
>>
>> That change still gives the correct result with all invocations I've
>> tried. It might be a safer bet...
>>
>> Regards,
>> Magnus
>>
>> ----- Original Message -----
>>> Patch review:
>>>
>>> Is it really right to call exit() from a signal handler like that.
>>> Wouldn't it be safer to use the select() timeout instead of alarm().
>>>
>>> Sorry for the late review, code stop is tomorrow for R15B.
>>>
>>> /Sverker, Erlang/OTP
>>>
>>>
>>> Magnus Henoch wrote:
>>>> Hi all,
>>>>
>>>> Here is a patch that makes run_erl return the exit status of its
>>>> child
>>>> process. (Probably only useful when using run_erl without -daemon,
>>>> just for convenient logging.)
>>>>
>>>> I added a signal handler for SIGALRM, since that appeared to be one
>>>> of
>>>> the ways run_erl exits, but I haven't been able to trigger that in
>>>> my
>>>> testing (it always exits because it can't read from the child's
>>>> pty).
>>>> I would appreciate informed opinions about whether that part is
>>>> necessary and correct.
>>>>
>>>> git fetch git://github.com/legoscia/otp.git run_erl_exit_status
>>>> https://github.com/legoscia/otp/commit/29364cf9a6e1fcfd032503ff9888cffc4327b867
>>>>
>>>>
>>>> Regards,
>>>> Magnus
>>>> _______________________________________________
>>>> erlang-patches mailing list
>>>> erlang-patches@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-patches
>>>>
>>
>
>
From magnus@REDACTED Tue Feb 4 19:08:23 2014
From: magnus@REDACTED (Magnus Henoch)
Date: Tue, 04 Feb 2014 18:08:23 +0000
Subject: [erlang-patches] run_erl: propagate exit status
In-Reply-To: <52F12752.7030702@erix.ericsson.se> (Sverker Eriksson's message
of "Tue, 4 Feb 2014 18:45:54 +0100")
References:
<4ED5061D.2050801@erix.ericsson.se>
<52F12752.7030702@erix.ericsson.se>
Message-ID:
Not at the moment; I'm no longer using run_erl without the -daemon
option, so this is not a problem I need to solve anymore. I guess it
should be dropped for now.
Regards,
Magnus
Sverker Eriksson writes:
> Magnus ! ping.
>
> Any interest in trying to get this two year old patch into OTP 17?
>
> The feature of propagating exit status seems reasonable and useful.
>
> /Sverker, Erlang/OTP
>
>
> On 11/29/2011 05:19 PM, Sverker Eriksson wrote:
>> Henrik:
>>
>> This one should replace the current mh/run_erl-exit-status in pu:
>>
>> git fetch git://github.com/legoscia/otp.git run_erl_exit_status_simple
>>
>>
>> Magnus:
>>
>> I got two objections on the the other version using select timeout.
>>
>> 1. You don't check if it actually was a timeout from select() before
>> doing "want_to_exit = 1".
>> 2. No test that reproduces the more complicated case.
>>
>> /Sverker
>>
>>
>> Magnus Henoch wrote:
>>> Good catch, exit() is indeed not safe inside a signal handler, as it
>>> flushes stdio buffers etc.
>>>
>>> I committed a new version that uses a select timeout:
>>>
>>> git fetch git://github.com/legoscia/otp.git run_erl_exit_status
>>> https://github.com/legoscia/otp/commit/run_erl_exit_status
>>>
>>> But since I still haven't been able to reproduce the case that the
>>> alarm is supposed to handle, I also committed a simpler change
>>> that leaves the alarm signal as it used to be:
>>>
>>> git fetch git://github.com/legoscia/otp.git run_erl_exit_status_simple
>>> https://github.com/legoscia/otp/commit/run_erl_exit_status_simple
>>>
>>> That change still gives the correct result with all invocations I've
>>> tried. It might be a safer bet...
>>>
>>> Regards,
>>> Magnus
>>>
>>> ----- Original Message -----
>>>> Patch review:
>>>>
>>>> Is it really right to call exit() from a signal handler like that.
>>>> Wouldn't it be safer to use the select() timeout instead of alarm().
>>>>
>>>> Sorry for the late review, code stop is tomorrow for R15B.
>>>>
>>>> /Sverker, Erlang/OTP
>>>>
>>>>
>>>> Magnus Henoch wrote:
>>>>> Hi all,
>>>>>
>>>>> Here is a patch that makes run_erl return the exit status of its
>>>>> child
>>>>> process. (Probably only useful when using run_erl without -daemon,
>>>>> just for convenient logging.)
>>>>>
>>>>> I added a signal handler for SIGALRM, since that appeared to be one
>>>>> of
>>>>> the ways run_erl exits, but I haven't been able to trigger that in
>>>>> my
>>>>> testing (it always exits because it can't read from the child's
>>>>> pty).
>>>>> I would appreciate informed opinions about whether that part is
>>>>> necessary and correct.
>>>>>
>>>>> git fetch git://github.com/legoscia/otp.git run_erl_exit_status
>>>>> https://github.com/legoscia/otp/commit/29364cf9a6e1fcfd032503ff9888cffc4327b867
>>>>>
>>>>>
>>>>> Regards,
>>>>> Magnus
>>>>> _______________________________________________
>>>>> erlang-patches mailing list
>>>>> erlang-patches@REDACTED
>>>>> http://erlang.org/mailman/listinfo/erlang-patches
>>>>>
>>>
>>
>>
From rzezeski@REDACTED Tue Feb 4 22:10:48 2014
From: rzezeski@REDACTED (Ryan Zezeski)
Date: Tue, 4 Feb 2014 16:10:48 -0500
Subject: [erlang-patches] Fix DTrace build on Illumos
In-Reply-To: <52F12255.6050704@erlang.org>
References:
<52A71690.7000808@erlang.org>
<52F12255.6050704@erlang.org>
Message-ID:
Hi Lukas,
If I recall correctly, I did that so that the exact failure reason would be
more obvious when dtrace fails build. When I first ran into this problem
months ago it was hard for me to determine what the issue was and my
thinking is that this output would help. Perhaps it is not useful? I will
not object if you feel this particular change needs to be reverted but I
also didn't make the change by accident.
-Z
On Tue, Feb 4, 2014 at 12:24 PM, Lukas Larsson wrote:
> Hello Ryan,
>
> I just noticed that you removed the "2> /dev/null" for the 2STEP_TEST in
> erts/configure.in. Was there a reason for doing that? As it is now when
> the test fails on osx in prints the output of the dtrace command to the
> shell which is not really what you want.
>
>
> Lukas
> On 15/01/14 23:32, Ryan Zezeski wrote:
>
> Any news? Would be nice if R17 worked with DTrace on latest Illumos kernel.
>
>
> On Tue, Dec 10, 2013 at 8:26 AM, Henrik Nord wrote:
>
>> Thank you for your contribution !
>>
>> patch has been assigned to be reviewed
>>
>>
>>
>> On 2013-12-07 22:00, Ryan Zezeski wrote:
>>
>> https://github.com/erlang/otp/pull/156
>>
>> This patch fixes the configure and Makefile scripts to work with newer
>> DTrace. This applies to all Illumos derivatives including OpenIndiana,
>> SmartOS and OmnioOS. I've copied the commit message here verbatim.
>>
>> --- SNIP ---
>>
>> Fix DTrace build on Illumos
>>
>> DTrace was recently patched in Illumos to fail to create an object
>> file if no probes are found.
>>
>> * https://www.illumos.org/issues/4248
>> *
>> https://github.com/illumos/illumos-gate/commit/54a20ab41aadcb81c53e72fc65886e964e9add59
>>
>> This patch fixes two issues:
>>
>> * Modify the configure script to pass an object file to `dtrace -G`
>> that actually invokes a probe.
>>
>> * Remove creation of `dtrace_user.o` from the dyntrace Makefile. In
>> a
>> previous commit [1] Scott Fritchie relocated all the user probes
>> into the VM proper due to difficulties with DTrace probes in shared
>> libraries. The `dtrace_user.d` file is now empty and generates a
>> header file with nothing in it. There is no longer any reason to
>> generate `dtrace_user.o` because all the probes are in the VM. Thus
>> all the steps for building `dtrace_user.o` have been removed.
>>
>> [1]:
>> https://github.com/erlang/otp/commit/75552bd3bb4e7f3cf4dab81a5c81cf73b1d3fb99
>>
>> --- END SNIP ---
>>
>> -Z
>>
>>
>> _______________________________________________
>> erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches
>>
>>
>> --
>> /Henrik Nord Erlang/OTP
>>
>>
>
>
> _______________________________________________
> erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lukas@REDACTED Wed Feb 5 10:03:00 2014
From: lukas@REDACTED (Lukas Larsson)
Date: Wed, 5 Feb 2014 10:03:00 +0100
Subject: [erlang-patches] Fix DTrace build on Illumos
In-Reply-To:
References:
<52A71690.7000808@erlang.org>
<52F12255.6050704@erlang.org>
Message-ID: <52F1FE44.3080100@erlang.org>
Ok, thanks, good to know. I'll rewrite it so that the error message gets
put in the config.log instead of being printed to stdout.
Lukas
On 04/02/14 22:10, Ryan Zezeski wrote:
> Hi Lukas,
>
> If I recall correctly, I did that so that the exact failure reason
> would be more obvious when dtrace fails build. When I first ran into
> this problem months ago it was hard for me to determine what the issue
> was and my thinking is that this output would help. Perhaps it is not
> useful? I will not object if you feel this particular change needs to
> be reverted but I also didn't make the change by accident.
>
> -Z
>
>
> On Tue, Feb 4, 2014 at 12:24 PM, Lukas Larsson > wrote:
>
> Hello Ryan,
>
> I just noticed that you removed the "2> /dev/null" for the
> 2STEP_TEST in erts/configure.in . Was there a
> reason for doing that? As it is now when the test fails on osx in
> prints the output of the dtrace command to the shell which is not
> really what you want.
>
>
> Lukas
> On 15/01/14 23:32, Ryan Zezeski wrote:
>> Any news? Would be nice if R17 worked with DTrace on latest
>> Illumos kernel.
>>
>>
>> On Tue, Dec 10, 2013 at 8:26 AM, Henrik Nord > > wrote:
>>
>> Thank you for your contribution !
>>
>> patch has been assigned to be reviewed
>>
>>
>>
>> On 2013-12-07 22:00, Ryan Zezeski wrote:
>>> https://github.com/erlang/otp/pull/156
>>>
>>> This patch fixes the configure and Makefile scripts to work
>>> with newer DTrace. This applies to all Illumos derivatives
>>> including OpenIndiana, SmartOS and OmnioOS. I've copied the
>>> commit message here verbatim.
>>>
>>> --- SNIP ---
>>>
>>> Fix DTrace build on Illumos
>>>
>>> DTrace was recently patched in Illumos to fail to create
>>> an object
>>> file if no probes are found.
>>>
>>> * https://www.illumos.org/issues/4248
>>> *
>>> https://github.com/illumos/illumos-gate/commit/54a20ab41aadcb81c53e72fc65886e964e9add59
>>>
>>> This patch fixes two issues:
>>>
>>> * Modify the configure script to pass an object file to
>>> `dtrace -G`
>>> that actually invokes a probe.
>>>
>>> * Remove creation of `dtrace_user.o` from the dyntrace
>>> Makefile. In a
>>> previous commit [1] Scott Fritchie relocated all the
>>> user probes
>>> into the VM proper due to difficulties with DTrace
>>> probes in shared
>>> libraries. The `dtrace_user.d` file is now empty and
>>> generates a
>>> header file with nothing in it. There is no longer any
>>> reason to
>>> generate `dtrace_user.o` because all the probes are in
>>> the VM. Thus
>>> all the steps for building `dtrace_user.o` have been
>>> removed.
>>>
>>> [1]:
>>> https://github.com/erlang/otp/commit/75552bd3bb4e7f3cf4dab81a5c81cf73b1d3fb99
>>>
>>> --- END SNIP ---
>>>
>>> -Z
>>>
>>>
>>> _______________________________________________
>>> erlang-patches mailing list
>>> erlang-patches@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-patches
>>
>> --
>> /Henrik Nord Erlang/OTP
>>
>>
>>
>>
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-patches
>
>
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vladdu55@REDACTED Wed Feb 5 16:08:09 2014
From: vladdu55@REDACTED (Vlad Dumitrescu)
Date: Wed, 5 Feb 2014 16:08:09 +0100
Subject: [erlang-patches] (no subject)
Message-ID:
I have found a few warnings in the debugger code and fixed them. The
changes are trivial, so I didn't think that new tests are necessary.
Also, they are based on master because at this point they can only be
included in some R17, I think.
git fetch git://github.com/vladdu/otp.git debugger_fixes
https://github.com/vladdu/otp/compare/erlang:master...debugger_fixes
https://github.com/vladdu/otp/compare/erlang:master...debugger_fixes.patch
regards,
Vlad
From vladdu55@REDACTED Wed Feb 5 16:14:06 2014
From: vladdu55@REDACTED (Vlad Dumitrescu)
Date: Wed, 5 Feb 2014 16:14:06 +0100
Subject: [erlang-patches] Additions to the debugger to support the erlide
debugger
Message-ID:
There are mostly new functions and messages that don't affect the
regular debugger. The only exception is in dbg_ieval, where the exit_at
message has more detailed information (the pid of the process, a
stacktrace and the current bindings).
The new API is about
getting the current stacktrace
setting the value of a variable
storing stacktrace and bindings for exited processes, it is useful for
post-mortem analysis
If these changes are accepted, erlide can stop using a copy of the
debugger code with patches. Even the regular debugger might like to
use these.
I don't know what level of testing would this need. I'm sending
without any yet, in case the additions are not interesting at all.
Feedback is appreciated.
git fetch git://github.com/vladdu/otp.git debugger_update
https://github.com/vladdu/otp/compare/erlang:master...debugger_update
https://github.com/vladdu/otp/compare/erlang:master...debugger_update.patch
regards,
Vlad
From lukas@REDACTED Wed Feb 5 16:29:03 2014
From: lukas@REDACTED (Lukas Larsson)
Date: Wed, 5 Feb 2014 16:29:03 +0100
Subject: [erlang-patches] Fix DTrace build on Illumos
In-Reply-To:
References:
<52A71690.7000808@erlang.org>
<52F12255.6050704@erlang.org>
Message-ID: <52F258BF.3080108@erlang.org>
Hello,
Would you mind testing my modifications on Illumos? You can get them
here[1], I've tested on os x and freebsd.
Lukas
[1]:
https://github.com/garazdawi/otp/tree/lukas/erts/dtrace-config-logging
On 04/02/14 22:10, Ryan Zezeski wrote:
> Hi Lukas,
>
> If I recall correctly, I did that so that the exact failure reason
> would be more obvious when dtrace fails build. When I first ran into
> this problem months ago it was hard for me to determine what the issue
> was and my thinking is that this output would help. Perhaps it is not
> useful? I will not object if you feel this particular change needs to
> be reverted but I also didn't make the change by accident.
>
> -Z
>
>
> On Tue, Feb 4, 2014 at 12:24 PM, Lukas Larsson > wrote:
>
> Hello Ryan,
>
> I just noticed that you removed the "2> /dev/null" for the
> 2STEP_TEST in erts/configure.in . Was there a
> reason for doing that? As it is now when the test fails on osx in
> prints the output of the dtrace command to the shell which is not
> really what you want.
>
>
> Lukas
> On 15/01/14 23:32, Ryan Zezeski wrote:
>> Any news? Would be nice if R17 worked with DTrace on latest
>> Illumos kernel.
>>
>>
>> On Tue, Dec 10, 2013 at 8:26 AM, Henrik Nord > > wrote:
>>
>> Thank you for your contribution !
>>
>> patch has been assigned to be reviewed
>>
>>
>>
>> On 2013-12-07 22:00, Ryan Zezeski wrote:
>>> https://github.com/erlang/otp/pull/156
>>>
>>> This patch fixes the configure and Makefile scripts to work
>>> with newer DTrace. This applies to all Illumos derivatives
>>> including OpenIndiana, SmartOS and OmnioOS. I've copied the
>>> commit message here verbatim.
>>>
>>> --- SNIP ---
>>>
>>> Fix DTrace build on Illumos
>>>
>>> DTrace was recently patched in Illumos to fail to create
>>> an object
>>> file if no probes are found.
>>>
>>> * https://www.illumos.org/issues/4248
>>> *
>>> https://github.com/illumos/illumos-gate/commit/54a20ab41aadcb81c53e72fc65886e964e9add59
>>>
>>> This patch fixes two issues:
>>>
>>> * Modify the configure script to pass an object file to
>>> `dtrace -G`
>>> that actually invokes a probe.
>>>
>>> * Remove creation of `dtrace_user.o` from the dyntrace
>>> Makefile. In a
>>> previous commit [1] Scott Fritchie relocated all the
>>> user probes
>>> into the VM proper due to difficulties with DTrace
>>> probes in shared
>>> libraries. The `dtrace_user.d` file is now empty and
>>> generates a
>>> header file with nothing in it. There is no longer any
>>> reason to
>>> generate `dtrace_user.o` because all the probes are in
>>> the VM. Thus
>>> all the steps for building `dtrace_user.o` have been
>>> removed.
>>>
>>> [1]:
>>> https://github.com/erlang/otp/commit/75552bd3bb4e7f3cf4dab81a5c81cf73b1d3fb99
>>>
>>> --- END SNIP ---
>>>
>>> -Z
>>>
>>>
>>> _______________________________________________
>>> erlang-patches mailing list
>>> erlang-patches@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-patches
>>
>> --
>> /Henrik Nord Erlang/OTP
>>
>>
>>
>>
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-patches
>
>
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From henrik@REDACTED Thu Feb 6 10:27:27 2014
From: henrik@REDACTED (Henrik Nord)
Date: Thu, 6 Feb 2014 10:27:27 +0100
Subject: [erlang-patches] Fix SSL ETS table element leak and error
cleanup
In-Reply-To: <52A69C3F.4020502@shoretel.com>
References: <52A69C3F.4020502@shoretel.com>
Message-ID: <52F3557F.6060207@erlang.org>
Hi!
Patch solves two problems, one (trap exit) is already solved in R16B03.
The other part of the patch we do want, but it should be ammended nice
with a test case.
On 2013-12-10 05:44, Bernard Duggan wrote:
> Hi list,
> The SSL library maintains an internal table of CA certificates
> (ssl_otp_cacertificate_db). This is supposed to be cleaned up when the
> last connection using a certificate closes, however there's two problems
> in R16B02 (and in the current master branch on github):
>
> * When CA certificates are provided as binary blobs, rather than by
> filename (ie, #ssl_options.cacerts is set, but #ssl_options.cacertfile
> is not) the cleanup never occurs due to an incorrect pattern match in
> tls_connection:handle_trusted_certs_db/1. This causes the table to grow
> unchecked because each connection adds a new entry.
>
> * When the process exits abnormally, tls_connection:terminate/1 is never
> called because the trap_exit process flag is not set and so similarly
> the table (and everything else cleaned in terminate/1, for that matter)
> is not cleaned up. This doesn't affect "normal" termination caused by
> the connection closing because terminate/1 is called explicitly from
> handle_sync_event/4, rather that relying on gen_fsm's automatic calling.
>
> Fixes for both are here:
>
> git fetch git://github.com/bernardd/otp ssl_cert_cache_fix
> https://github.com/bernardd/otp/compare/erlang:master...ssl_cert_cache_fix
>
>
> Credit goes to my colleague Nick Marino for doing the initial legwork to
> track this down.
>
> Cheers,
>
> Bernard
>
> ________________________________
>
> This e-mail and any attachments are confidential. If it is not
> intended for you, please notify the sender, and please erase and
> ignore the contents.
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/Henrik Nord Erlang/OTP
From tuncer.ayaz@REDACTED Thu Feb 6 19:26:15 2014
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Thu, 6 Feb 2014 19:26:15 +0100
Subject: [erlang-patches] public_key(3): fix private_key/0 type definition
Message-ID:
https://github.com/erlang/otp/pull/226
https://github.com/erlang/otp/pull/226.patch
git fetch git://github.com/tuncer/otp.git fix-public_key-specs
From tuncer.ayaz@REDACTED Thu Feb 6 19:45:45 2014
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Thu, 6 Feb 2014 19:45:45 +0100
Subject: [erlang-patches] Properly export public_key types (Reported-by:
Kostis Sagonas)
Message-ID:
Kostis Sagonas reported[1] that public_key's types are not exported. To
fix that, add a complete export_type directive in public_key.erl.
[1] http://erlang.org/pipermail/erlang-bugs/2014-February/004050.html
https://github.com/erlang/otp/pull/227
https://github.com/erlang/otp/pull/227.patch
git fetch git://github.com/tuncer/otp.git export-public_key-types
From henrik@REDACTED Fri Feb 7 10:59:08 2014
From: henrik@REDACTED (Henrik Nord)
Date: Fri, 7 Feb 2014 10:59:08 +0100
Subject: [erlang-patches] Properly export public_key types (Reported-by:
Kostis Sagonas)
In-Reply-To:
References:
Message-ID: <52F4AE6C.9050408@erlang.org>
Thank you for your contribution!
On 2014-02-06 19:45, Tuncer Ayaz wrote:
> Kostis Sagonas reported[1] that public_key's types are not exported. To
> fix that, add a complete export_type directive in public_key.erl.
>
> [1] http://erlang.org/pipermail/erlang-bugs/2014-February/004050.html
>
>
> https://github.com/erlang/otp/pull/227
> https://github.com/erlang/otp/pull/227.patch
>
> git fetch git://github.com/tuncer/otp.git export-public_key-types
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/Henrik Nord Erlang/OTP
From henrik@REDACTED Fri Feb 7 11:00:20 2014
From: henrik@REDACTED (Henrik Nord)
Date: Fri, 7 Feb 2014 11:00:20 +0100
Subject: [erlang-patches] public_key(3): fix private_key/0 type
definition
In-Reply-To:
References:
Message-ID: <52F4AEB4.8080201@erlang.org>
Thank you for your contribution!
I will try to add this as the same ticket as the one this should have
been included in.
On 2014-02-06 19:26, Tuncer Ayaz wrote:
> https://github.com/erlang/otp/pull/226
> https://github.com/erlang/otp/pull/226.patch
>
> git fetch git://github.com/tuncer/otp.git fix-public_key-specs
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/Henrik Nord Erlang/OTP
From henrik@REDACTED Fri Feb 7 12:07:06 2014
From: henrik@REDACTED (Henrik Nord)
Date: Fri, 7 Feb 2014 12:07:06 +0100
Subject: [erlang-patches] (no subject)
In-Reply-To:
References:
Message-ID: <52F4BE5A.8090703@erlang.org>
Thank you for your contribution.
Your patches to the debugger are already appointed to a developer
On 2014-02-05 16:08, Vlad Dumitrescu wrote:
> I have found a few warnings in the debugger code and fixed them. The
> changes are trivial, so I didn't think that new tests are necessary.
>
> Also, they are based on master because at this point they can only be
> included in some R17, I think.
>
> git fetch git://github.com/vladdu/otp.git debugger_fixes
>
> https://github.com/vladdu/otp/compare/erlang:master...debugger_fixes
> https://github.com/vladdu/otp/compare/erlang:master...debugger_fixes.patch
>
> regards,
> Vlad
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/Henrik Nord Erlang/OTP
From daniel.goertzen@REDACTED Fri Feb 7 18:34:14 2014
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Fri, 7 Feb 2014 11:34:14 -0600
Subject: [erlang-patches] customized ERL_NIF_TERM type support
Message-ID:
When writing NIFs in C++, it is impossible to employ C++ function
overloading because the underlying type of ERL_NIF_TERM is "unsigned int".
For example:
// won't compile :(
#include
void my_func(ERL_NIF_TERM a) {...}
void my_func(unsigned int a) {...}
This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
underlying unsigned integer type gets wrapped as a C++11 typed
enumeration. The type of ERL_NIF_TERM is now unique and can be used in
overloaded functions.
// compiles! :)
#define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
#include
void my_func(ERL_NIF_TERM a) {...}
void my_func(unsigned int a) {...}
The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not defined
(other than flipping the definition order of ERL_NIF_TERM and ERL_NIF_UINT).
A similar approach has been used on my C++11 NIF wrapper (
https://github.com/goertzenator/nifpp). The wrapper requires manual
installation of a similar patch, and I would love to remove that
requirement.
Regards,
Dan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: custom_erl_nif_term.patch
Type: text/x-patch
Size: 889 bytes
Desc: not available
URL:
From sverker.eriksson@REDACTED Fri Feb 7 19:46:20 2014
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Fri, 7 Feb 2014 19:46:20 +0100
Subject: [erlang-patches] customized ERL_NIF_TERM type support
In-Reply-To:
References:
Message-ID: <52F529FC.6080909@erix.ericsson.se>
Thanks for the patch.
I got one objection/question though. My C++ knowledge is a bit rusty but
as I understand it
the "enum class" construct demands that Type is an integer type.
This is currently true for ERL_NIF_TERM but it might not be in the future.
I earlier tried to define ERL_NIF_TERM as
typedef struct { int x; } ERL_NIF_TERM;
to get stronger type checking even for C. I reverted that due to bad
performance
as gcc has different calling conventions for int and struct {int}.
However, future compilers
might be better at passing struct{int} by value in which case we might
want to change
the definition of ERL_NIF_TERM.
What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?
/Sverker, Erlang/OTP
On 02/07/2014 06:34 PM, Daniel Goertzen wrote:
> When writing NIFs in C++, it is impossible to employ C++ function
> overloading because the underlying type of ERL_NIF_TERM is "unsigned int".
> For example:
>
> // won't compile :(
> #include
> void my_func(ERL_NIF_TERM a) {...}
> void my_func(unsigned int a) {...}
>
>
> This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
> defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
> underlying unsigned integer type gets wrapped as a C++11 typed
> enumeration. The type of ERL_NIF_TERM is now unique and can be used in
> overloaded functions.
>
> // compiles! :)
> #define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
> #include
> void my_func(ERL_NIF_TERM a) {...}
> void my_func(unsigned int a) {...}
>
>
> The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not defined
> (other than flipping the definition order of ERL_NIF_TERM and ERL_NIF_UINT).
>
> A similar approach has been used on my C++11 NIF wrapper (
> https://github.com/goertzenator/nifpp). The wrapper requires manual
> installation of a similar patch, and I would love to remove that
> requirement.
>
> Regards,
> Dan.
>
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From daniel.goertzen@REDACTED Fri Feb 7 20:21:27 2014
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Fri, 7 Feb 2014 13:21:27 -0600
Subject: [erlang-patches] customized ERL_NIF_TERM type support
In-Reply-To: <52F529FC.6080909@erix.ericsson.se>
References:
<52F529FC.6080909@erix.ericsson.se>
Message-ID:
Thank you for your feedback. Maybe the "hook" approach I suggested is too
generic. My original patch from nifpp actually looks like this...
#ifdef CPP11_UNIQUE_TERM_TYPE
enum class ERL_NIF_TERM : ERL_NIF_UINT;
#else
typedef ERL_NIF_UINT ERL_NIF_TERM;
#endif
...and then to use the typed enum in your c++ nif you write...
#define CPP11_UNIQUE_TERM_TYPE
#include
In the future ERL_NIF_TERM can be changed to a struct and the
CPP11_UNIQUE_TERM_TYPE option can just be ignored. What do you think?
Cheers,
Dan.
On Fri, Feb 7, 2014 at 12:46 PM, Sverker Eriksson <
sverker.eriksson@REDACTED> wrote:
> Thanks for the patch.
>
> I got one objection/question though. My C++ knowledge is a bit rusty but
> as I understand it
> the "enum class" construct demands that Type is an integer type.
>
> This is currently true for ERL_NIF_TERM but it might not be in the future.
> I earlier tried to define ERL_NIF_TERM as
>
> typedef struct { int x; } ERL_NIF_TERM;
>
> to get stronger type checking even for C. I reverted that due to bad
> performance
> as gcc has different calling conventions for int and struct {int}.
> However, future compilers
> might be better at passing struct{int} by value in which case we might
> want to change
> the definition of ERL_NIF_TERM.
>
> What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?
>
>
> /Sverker, Erlang/OTP
>
>
>
> On 02/07/2014 06:34 PM, Daniel Goertzen wrote:
>
> When writing NIFs in C++, it is impossible to employ C++ function
> overloading because the underlying type of ERL_NIF_TERM is "unsigned int".
> For example:
>
> // won't compile :(
> #include
> void my_func(ERL_NIF_TERM a) {...}
> void my_func(unsigned int a) {...}
>
>
> This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
> defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
> underlying unsigned integer type gets wrapped as a C++11 typed
> enumeration. The type of ERL_NIF_TERM is now unique and can be used in
> overloaded functions.
>
> // compiles! :)
> #define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
> #include
> void my_func(ERL_NIF_TERM a) {...}
> void my_func(unsigned int a) {...}
>
>
> The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not defined
> (other than flipping the definition order of ERL_NIF_TERM and ERL_NIF_UINT).
>
> A similar approach has been used on my C++11 NIF wrapper (https://github.com/goertzenator/nifpp). The wrapper requires manual
> installation of a similar patch, and I would love to remove that
> requirement.
>
> Regards,
> Dan.
>
>
>
>
> _______________________________________________
> erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sverker.eriksson@REDACTED Mon Feb 10 14:09:11 2014
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Mon, 10 Feb 2014 14:09:11 +0100
Subject: [erlang-patches] customized ERL_NIF_TERM type support
In-Reply-To:
References: <52F529FC.6080909@erix.ericsson.se>
Message-ID: <52F8CF77.4050407@ericsson.com>
The "hook" solution has an advantage I think. It leaves it up to the
user to define the type and thereby to "make it work".
I actually don't understand how you get this to work. How can you mix
C++ types within a extern "C" declaration?
/Sverker
On 02/07/2014 08:21 PM, Daniel Goertzen wrote:
> Thank you for your feedback. Maybe the "hook" approach I suggested is too
> generic. My original patch from nifpp actually looks like this...
>
> #ifdef CPP11_UNIQUE_TERM_TYPE
> enum class ERL_NIF_TERM : ERL_NIF_UINT;
> #else
> typedef ERL_NIF_UINT ERL_NIF_TERM;
> #endif
>
> ...and then to use the typed enum in your c++ nif you write...
>
> #define CPP11_UNIQUE_TERM_TYPE
> #include
>
>
> In the future ERL_NIF_TERM can be changed to a struct and the
> CPP11_UNIQUE_TERM_TYPE option can just be ignored. What do you think?
>
> Cheers,
> Dan.
>
>
> On Fri, Feb 7, 2014 at 12:46 PM, Sverker Eriksson <
> sverker.eriksson@REDACTED> wrote:
>
>> Thanks for the patch.
>>
>> I got one objection/question though. My C++ knowledge is a bit rusty but
>> as I understand it
>> the "enum class" construct demands that Type is an integer type.
>>
>> This is currently true for ERL_NIF_TERM but it might not be in the future.
>> I earlier tried to define ERL_NIF_TERM as
>>
>> typedef struct { int x; } ERL_NIF_TERM;
>>
>> to get stronger type checking even for C. I reverted that due to bad
>> performance
>> as gcc has different calling conventions for int and struct {int}.
>> However, future compilers
>> might be better at passing struct{int} by value in which case we might
>> want to change
>> the definition of ERL_NIF_TERM.
>>
>> What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?
>>
>>
>> /Sverker, Erlang/OTP
>>
>>
>>
>> On 02/07/2014 06:34 PM, Daniel Goertzen wrote:
>>
>> When writing NIFs in C++, it is impossible to employ C++ function
>> overloading because the underlying type of ERL_NIF_TERM is "unsigned int".
>> For example:
>>
>> // won't compile :(
>> #include
>> void my_func(ERL_NIF_TERM a) {...}
>> void my_func(unsigned int a) {...}
>>
>>
>> This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
>> defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
>> underlying unsigned integer type gets wrapped as a C++11 typed
>> enumeration. The type of ERL_NIF_TERM is now unique and can be used in
>> overloaded functions.
>>
>> // compiles! :)
>> #define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
>> #include
>> void my_func(ERL_NIF_TERM a) {...}
>> void my_func(unsigned int a) {...}
>>
>>
>> The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not defined
>> (other than flipping the definition order of ERL_NIF_TERM and ERL_NIF_UINT).
>>
>> A similar approach has been used on my C++11 NIF wrapper (https://github.com/goertzenator/nifpp). The wrapper requires manual
>> installation of a similar patch, and I would love to remove that
>> requirement.
>>
>> Regards,
>> Dan.
>>
>>
>>
>>
>> _______________________________________________
>> erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches
>>
>>
>>
From daniel.goertzen@REDACTED Mon Feb 10 20:28:43 2014
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Mon, 10 Feb 2014 13:28:43 -0600
Subject: [erlang-patches] customized ERL_NIF_TERM type support
In-Reply-To: <52F8CF77.4050407@ericsson.com>
References:
<52F529FC.6080909@erix.ericsson.se>
<52F8CF77.4050407@ericsson.com>
Message-ID:
Regarding C++ types in extern "C": That is a very good question...
I looked into the C++ standard and other documents. The answer is that
extern "C" just changes the default linkage to "C" instead of "C++".
Everything else remains the same, so you can still use the rest of C++
inside an extern "C", but the linkage may impose some limitations (like no
function overloading). "C" linkage names only indicate the name the of the
function but not the parameter or return types like C++ linkage names.
Now that I am a little more educated on linking and calling conventions, I
am uncomfortable with the patches I have suggested. Sure, they work on
linux with gcc, but will they work on MSVC? What about the other less
common unices? I think depending on linker looseness is brittle.
As an alternate idea, I think I can generate inline C++ wrappers for the
whole NIF API and get a unique ERL_NIF_TERM type that way. It's not very
elegant, but everything gets resolved at compile time with no linker
tricks, and the compiler should flatten the wrapper away so that there is
no overhead.
So, if you agree, I'd like to take this patch out back and shoot it. :)
Dan.
On Mon, Feb 10, 2014 at 7:09 AM, Sverker Eriksson <
sverker.eriksson@REDACTED> wrote:
> The "hook" solution has an advantage I think. It leaves it up to the user
> to define the type and thereby to "make it work".
>
> I actually don't understand how you get this to work. How can you mix C++
> types within a extern "C" declaration?
>
> /Sverker
>
>
> On 02/07/2014 08:21 PM, Daniel Goertzen wrote:
>
>> Thank you for your feedback. Maybe the "hook" approach I suggested is too
>> generic. My original patch from nifpp actually looks like this...
>>
>> #ifdef CPP11_UNIQUE_TERM_TYPE
>> enum class ERL_NIF_TERM : ERL_NIF_UINT;
>> #else
>> typedef ERL_NIF_UINT ERL_NIF_TERM;
>> #endif
>>
>> ...and then to use the typed enum in your c++ nif you write...
>>
>> #define CPP11_UNIQUE_TERM_TYPE
>> #include
>>
>>
>> In the future ERL_NIF_TERM can be changed to a struct and the
>> CPP11_UNIQUE_TERM_TYPE option can just be ignored. What do you think?
>>
>> Cheers,
>> Dan.
>>
>>
>> On Fri, Feb 7, 2014 at 12:46 PM, Sverker Eriksson <
>> sverker.eriksson@REDACTED> wrote:
>>
>> Thanks for the patch.
>>>
>>> I got one objection/question though. My C++ knowledge is a bit rusty but
>>> as I understand it
>>> the "enum class" construct demands that Type is an integer type.
>>>
>>> This is currently true for ERL_NIF_TERM but it might not be in the
>>> future.
>>> I earlier tried to define ERL_NIF_TERM as
>>>
>>> typedef struct { int x; } ERL_NIF_TERM;
>>>
>>> to get stronger type checking even for C. I reverted that due to bad
>>> performance
>>> as gcc has different calling conventions for int and struct {int}.
>>> However, future compilers
>>> might be better at passing struct{int} by value in which case we might
>>> want to change
>>> the definition of ERL_NIF_TERM.
>>>
>>> What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?
>>>
>>>
>>> /Sverker, Erlang/OTP
>>>
>>>
>>>
>>> On 02/07/2014 06:34 PM, Daniel Goertzen wrote:
>>>
>>> When writing NIFs in C++, it is impossible to employ C++ function
>>> overloading because the underlying type of ERL_NIF_TERM is "unsigned
>>> int".
>>> For example:
>>>
>>> // won't compile :(
>>> #include
>>> void my_func(ERL_NIF_TERM a) {...}
>>> void my_func(unsigned int a) {...}
>>>
>>>
>>> This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
>>> defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
>>> underlying unsigned integer type gets wrapped as a C++11 typed
>>> enumeration. The type of ERL_NIF_TERM is now unique and can be used in
>>> overloaded functions.
>>>
>>> // compiles! :)
>>> #define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
>>> #include
>>> void my_func(ERL_NIF_TERM a) {...}
>>> void my_func(unsigned int a) {...}
>>>
>>>
>>> The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not
>>> defined
>>> (other than flipping the definition order of ERL_NIF_TERM and
>>> ERL_NIF_UINT).
>>>
>>> A similar approach has been used on my C++11 NIF wrapper (
>>> https://github.com/goertzenator/nifpp). The wrapper requires manual
>>>
>>> installation of a similar patch, and I would love to remove that
>>> requirement.
>>>
>>> Regards,
>>> Dan.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-patches mailing listerlang-patches@REDACTED://
>>> erlang.org/mailman/listinfo/erlang-patches
>>>
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sverker.eriksson@REDACTED Tue Feb 11 12:33:33 2014
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Tue, 11 Feb 2014 12:33:33 +0100
Subject: [erlang-patches] customized ERL_NIF_TERM type support
In-Reply-To:
References: <52F529FC.6080909@erix.ericsson.se> <52F8CF77.4050407@ericsson.com>
Message-ID: <52FA0A8D.60102@ericsson.com>
I agree. Shoot!
/Sverker
On 02/10/2014 08:28 PM, Daniel Goertzen wrote:
> Regarding C++ types in extern "C": That is a very good question...
>
> I looked into the C++ standard and other documents. The answer is that
> extern "C" just changes the default linkage to "C" instead of "C++".
> Everything else remains the same, so you can still use the rest of C++
> inside an extern "C", but the linkage may impose some limitations (like no
> function overloading). "C" linkage names only indicate the name the of the
> function but not the parameter or return types like C++ linkage names.
>
> Now that I am a little more educated on linking and calling conventions, I
> am uncomfortable with the patches I have suggested. Sure, they work on
> linux with gcc, but will they work on MSVC? What about the other less
> common unices? I think depending on linker looseness is brittle.
>
> As an alternate idea, I think I can generate inline C++ wrappers for the
> whole NIF API and get a unique ERL_NIF_TERM type that way. It's not very
> elegant, but everything gets resolved at compile time with no linker
> tricks, and the compiler should flatten the wrapper away so that there is
> no overhead.
>
> So, if you agree, I'd like to take this patch out back and shoot it. :)
>
> Dan.
>
>
>
>
>
>
> On Mon, Feb 10, 2014 at 7:09 AM, Sverker Eriksson <
> sverker.eriksson@REDACTED> wrote:
>
>> The "hook" solution has an advantage I think. It leaves it up to the user
>> to define the type and thereby to "make it work".
>>
>> I actually don't understand how you get this to work. How can you mix C++
>> types within a extern "C" declaration?
>>
>> /Sverker
>>
>>
>> On 02/07/2014 08:21 PM, Daniel Goertzen wrote:
>>
>>> Thank you for your feedback. Maybe the "hook" approach I suggested is too
>>> generic. My original patch from nifpp actually looks like this...
>>>
>>> #ifdef CPP11_UNIQUE_TERM_TYPE
>>> enum class ERL_NIF_TERM : ERL_NIF_UINT;
>>> #else
>>> typedef ERL_NIF_UINT ERL_NIF_TERM;
>>> #endif
>>>
>>> ...and then to use the typed enum in your c++ nif you write...
>>>
>>> #define CPP11_UNIQUE_TERM_TYPE
>>> #include
>>>
>>>
>>> In the future ERL_NIF_TERM can be changed to a struct and the
>>> CPP11_UNIQUE_TERM_TYPE option can just be ignored. What do you think?
>>>
>>> Cheers,
>>> Dan.
>>>
>>>
>>> On Fri, Feb 7, 2014 at 12:46 PM, Sverker Eriksson <
>>> sverker.eriksson@REDACTED> wrote:
>>>
>>> Thanks for the patch.
>>>> I got one objection/question though. My C++ knowledge is a bit rusty but
>>>> as I understand it
>>>> the "enum class" construct demands that Type is an integer type.
>>>>
>>>> This is currently true for ERL_NIF_TERM but it might not be in the
>>>> future.
>>>> I earlier tried to define ERL_NIF_TERM as
>>>>
>>>> typedef struct { int x; } ERL_NIF_TERM;
>>>>
>>>> to get stronger type checking even for C. I reverted that due to bad
>>>> performance
>>>> as gcc has different calling conventions for int and struct {int}.
>>>> However, future compilers
>>>> might be better at passing struct{int} by value in which case we might
>>>> want to change
>>>> the definition of ERL_NIF_TERM.
>>>>
>>>> What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?
>>>>
>>>>
>>>> /Sverker, Erlang/OTP
>>>>
>>>>
>>>>
>>>> On 02/07/2014 06:34 PM, Daniel Goertzen wrote:
>>>>
>>>> When writing NIFs in C++, it is impossible to employ C++ function
>>>> overloading because the underlying type of ERL_NIF_TERM is "unsigned
>>>> int".
>>>> For example:
>>>>
>>>> // won't compile :(
>>>> #include
>>>> void my_func(ERL_NIF_TERM a) {...}
>>>> void my_func(unsigned int a) {...}
>>>>
>>>>
>>>> This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
>>>> defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
>>>> underlying unsigned integer type gets wrapped as a C++11 typed
>>>> enumeration. The type of ERL_NIF_TERM is now unique and can be used in
>>>> overloaded functions.
>>>>
>>>> // compiles! :)
>>>> #define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
>>>> #include
>>>> void my_func(ERL_NIF_TERM a) {...}
>>>> void my_func(unsigned int a) {...}
>>>>
>>>>
>>>> The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not
>>>> defined
>>>> (other than flipping the definition order of ERL_NIF_TERM and
>>>> ERL_NIF_UINT).
>>>>
>>>> A similar approach has been used on my C++11 NIF wrapper (
>>>> https://github.com/goertzenator/nifpp). The wrapper requires manual
>>>>
>>>> installation of a similar patch, and I would love to remove that
>>>> requirement.
>>>>
>>>> Regards,
>>>> Dan.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-patches mailing listerlang-patches@REDACTED://
>>>> erlang.org/mailman/listinfo/erlang-patches
>>>>
>>>>
>>>>
>>>>
From davidnwelton@REDACTED Tue Feb 11 14:09:06 2014
From: davidnwelton@REDACTED (David Welton)
Date: Tue, 11 Feb 2014 14:09:06 +0100
Subject: [erlang-patches] human readable strings from {Errorline, Module,
ErrorDescriptor}
Message-ID:
This is very minor, so I'm just sending a patch here:
--- a/lib/stdlib/doc/src/erl_parse.xml
+++ b/lib/stdlib/doc/src/erl_parse.xml
@@ -200,6 +200,12 @@
Module:format_error(ErrorDescriptor)
+
+ It is also possible to obtain a human-readable string
describing the error with this function:
+
+
+ file:format_error({Errorline, Module, ErrorDescriptor})
+
This could also be added to io.xml, epp.xml, erl_lint.xml and erl_scan.xml.
If needs be, I guess I could create a branch, pull request, and so on.
--
David N. Welton
http://www.welton.it/davidw/
http://www.dedasys.com/
From vladdu55@REDACTED Tue Feb 11 14:24:30 2014
From: vladdu55@REDACTED (Vlad Dumitrescu)
Date: Tue, 11 Feb 2014 14:24:30 +0100
Subject: [erlang-patches] implement maps support in jinterface
Message-ID:
The API and implementation are simplistic, like for lists and tuples,
using arrays and without any connection to java.util.Map.
git fetch git://github.com/vladdu/jinterface_maps
https://github.com/vladdu/otp/compare/erlang:master...jinterface_maps
https://github.com/vladdu/otp/compare/erlang:master...jinterface_maps.patch
From daniel.goertzen@REDACTED Thu Feb 13 16:37:20 2014
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Thu, 13 Feb 2014 09:37:20 -0600
Subject: [erlang-patches] customized ERL_NIF_TERM type support
In-Reply-To: <52F529FC.6080909@erix.ericsson.se>
References:
<52F529FC.6080909@erix.ericsson.se>
Message-ID:
Hi Sverker.
I want to look at the bad performance issue you observed with respect to
passing "struct{int}" as a parameter vs just passing "int". I wrote a tiny
test program to observe the assembly generated by gcc and the code for the
two cases looked identical. Also, some research into calling conventions
hasn't offered me any explanations yet.
Do you have any details you can share that will help me understand when and
why performance degrades?
I want to understand because I am looking at a struct{int} approach as part
of a C++ nif solution, and I am very sensitive about adding bloat.
Thanks,
Dan.
On Fri, Feb 7, 2014 at 12:46 PM, Sverker Eriksson <
sverker.eriksson@REDACTED> wrote:
> Thanks for the patch.
>
> I got one objection/question though. My C++ knowledge is a bit rusty but
> as I understand it
> the "enum class" construct demands that Type is an integer type.
>
> This is currently true for ERL_NIF_TERM but it might not be in the future.
> I earlier tried to define ERL_NIF_TERM as
>
> typedef struct { int x; } ERL_NIF_TERM;
>
> to get stronger type checking even for C. I reverted that due to bad
> performance
> as gcc has different calling conventions for int and struct {int}.
> However, future compilers
> might be better at passing struct{int} by value in which case we might
> want to change
> the definition of ERL_NIF_TERM.
>
> What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?
>
>
> /Sverker, Erlang/OTP
>
>
>
> On 02/07/2014 06:34 PM, Daniel Goertzen wrote:
>
> When writing NIFs in C++, it is impossible to employ C++ function
> overloading because the underlying type of ERL_NIF_TERM is "unsigned int".
> For example:
>
> // won't compile :(
> #include
> void my_func(ERL_NIF_TERM a) {...}
> void my_func(unsigned int a) {...}
>
>
> This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
> defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
> underlying unsigned integer type gets wrapped as a C++11 typed
> enumeration. The type of ERL_NIF_TERM is now unique and can be used in
> overloaded functions.
>
> // compiles! :)
> #define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
> #include
> void my_func(ERL_NIF_TERM a) {...}
> void my_func(unsigned int a) {...}
>
>
> The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not defined
> (other than flipping the definition order of ERL_NIF_TERM and ERL_NIF_UINT).
>
> A similar approach has been used on my C++11 NIF wrapper (https://github.com/goertzenator/nifpp). The wrapper requires manual
> installation of a similar patch, and I would love to remove that
> requirement.
>
> Regards,
> Dan.
>
>
>
>
> _______________________________________________
> erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sverker.eriksson@REDACTED Thu Feb 13 17:19:44 2014
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Thu, 13 Feb 2014 17:19:44 +0100
Subject: [erlang-patches] customized ERL_NIF_TERM type support
In-Reply-To:
References: <52F529FC.6080909@erix.ericsson.se>
Message-ID: <52FCF0A0.1070301@ericsson.com>
As I remember, it was the convention of *returning* int vs struct{int}
that differed (at least).
int was returned in a register while struct{int} was stored on stack and
returning
pointer to it in register.
Maybe there is a difference between C and C++ conventions also.
The top commit on this branch was my attempt with a struct:
git fetch https://github.com/sverker/otp.git ERL_NIF_TERM_as_struct
Just did a little test myself now:
struct X {
int b;
};
struct X bar(struct X);
int foo(int x);
int main()
{
struct X a = {0x77};
struct X x = bar(a);
int y = foo(0x88);
return x.b + y;
}
And gcc 4.6.3 uses the same calling conventions for foo and bar (arg in
edi and return value in eax)
on my x86_64 Linux machine.
I don't remember if it was some other architecture that I saw the
difference on.
/Sverker
On 02/13/2014 04:37 PM, Daniel Goertzen wrote:
> Hi Sverker.
>
> I want to look at the bad performance issue you observed with respect to
> passing "struct{int}" as a parameter vs just passing "int". I wrote a tiny
> test program to observe the assembly generated by gcc and the code for the
> two cases looked identical. Also, some research into calling conventions
> hasn't offered me any explanations yet.
>
> Do you have any details you can share that will help me understand when and
> why performance degrades?
>
> I want to understand because I am looking at a struct{int} approach as part
> of a C++ nif solution, and I am very sensitive about adding bloat.
>
> Thanks,
> Dan.
>
>
>
>
> On Fri, Feb 7, 2014 at 12:46 PM, Sverker Eriksson <
> sverker.eriksson@REDACTED> wrote:
>
>> Thanks for the patch.
>>
>> I got one objection/question though. My C++ knowledge is a bit rusty but
>> as I understand it
>> the "enum class" construct demands that Type is an integer type.
>>
>> This is currently true for ERL_NIF_TERM but it might not be in the future.
>> I earlier tried to define ERL_NIF_TERM as
>>
>> typedef struct { int x; } ERL_NIF_TERM;
>>
>> to get stronger type checking even for C. I reverted that due to bad
>> performance
>> as gcc has different calling conventions for int and struct {int}.
>> However, future compilers
>> might be better at passing struct{int} by value in which case we might
>> want to change
>> the definition of ERL_NIF_TERM.
>>
>> What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?
>>
>>
>> /Sverker, Erlang/OTP
>>
>>
>>
>> On 02/07/2014 06:34 PM, Daniel Goertzen wrote:
>>
>> When writing NIFs in C++, it is impossible to employ C++ function
>> overloading because the underlying type of ERL_NIF_TERM is "unsigned int".
>> For example:
>>
>> // won't compile :(
>> #include
>> void my_func(ERL_NIF_TERM a) {...}
>> void my_func(unsigned int a) {...}
>>
>>
>> This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
>> defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
>> underlying unsigned integer type gets wrapped as a C++11 typed
>> enumeration. The type of ERL_NIF_TERM is now unique and can be used in
>> overloaded functions.
>>
>> // compiles! :)
>> #define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
>> #include
>> void my_func(ERL_NIF_TERM a) {...}
>> void my_func(unsigned int a) {...}
>>
>>
>> The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not defined
>> (other than flipping the definition order of ERL_NIF_TERM and ERL_NIF_UINT).
>>
>> A similar approach has been used on my C++11 NIF wrapper (https://github.com/goertzenator/nifpp). The wrapper requires manual
>> installation of a similar patch, and I would love to remove that
>> requirement.
>>
>> Regards,
>> Dan.
>>
>>
>>
>>
>> _______________________________________________
>> erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches
>>
>>
>>
From daniel.goertzen@REDACTED Thu Feb 13 18:18:10 2014
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Thu, 13 Feb 2014 11:18:10 -0600
Subject: [erlang-patches] customized ERL_NIF_TERM type support
In-Reply-To: <52FCF0A0.1070301@ericsson.com>
References:
<52F529FC.6080909@erix.ericsson.se>
<52FCF0A0.1070301@ericsson.com>
Message-ID:
Thank you for the details.
I see that there are gcc code generation options to choose register or
stack returns for short structs (-fpcc-struct-return and
-freg-struct-return). If not specified the platform default is selected,
whatever that may be. "register" returns must be selected for the tests we
are compiling this week, but on your test years ago "stack" must have been
selected.
Anyway, for my use case I am comfortable going ahead with struct{int} usage.
Thanks again for leading me to the answer,
Dan.
On Thu, Feb 13, 2014 at 10:19 AM, Sverker Eriksson <
sverker.eriksson@REDACTED> wrote:
> As I remember, it was the convention of *returning* int vs struct{int}
> that differed (at least).
> int was returned in a register while struct{int} was stored on stack and
> returning
> pointer to it in register.
>
> Maybe there is a difference between C and C++ conventions also.
>
> The top commit on this branch was my attempt with a struct:
>
> git fetch https://github.com/sverker/otp.git ERL_NIF_TERM_as_struct
>
>
> Just did a little test myself now:
>
> struct X {
> int b;
> };
>
> struct X bar(struct X);
> int foo(int x);
>
>
> int main()
> {
> struct X a = {0x77};
> struct X x = bar(a);
> int y = foo(0x88);
>
> return x.b + y;
> }
>
> And gcc 4.6.3 uses the same calling conventions for foo and bar (arg in
> edi and return value in eax)
> on my x86_64 Linux machine.
>
> I don't remember if it was some other architecture that I saw the
> difference on.
>
>
> /Sverker
>
>
>
>
>
> On 02/13/2014 04:37 PM, Daniel Goertzen wrote:
>
>> Hi Sverker.
>>
>> I want to look at the bad performance issue you observed with respect to
>> passing "struct{int}" as a parameter vs just passing "int". I wrote a
>> tiny
>> test program to observe the assembly generated by gcc and the code for the
>> two cases looked identical. Also, some research into calling conventions
>> hasn't offered me any explanations yet.
>>
>> Do you have any details you can share that will help me understand when
>> and
>> why performance degrades?
>>
>> I want to understand because I am looking at a struct{int} approach as
>> part
>> of a C++ nif solution, and I am very sensitive about adding bloat.
>>
>> Thanks,
>> Dan.
>>
>>
>>
>>
>> On Fri, Feb 7, 2014 at 12:46 PM, Sverker Eriksson <
>> sverker.eriksson@REDACTED> wrote:
>>
>> Thanks for the patch.
>>>
>>> I got one objection/question though. My C++ knowledge is a bit rusty but
>>> as I understand it
>>> the "enum class" construct demands that Type is an integer type.
>>>
>>> This is currently true for ERL_NIF_TERM but it might not be in the
>>> future.
>>> I earlier tried to define ERL_NIF_TERM as
>>>
>>> typedef struct { int x; } ERL_NIF_TERM;
>>>
>>> to get stronger type checking even for C. I reverted that due to bad
>>> performance
>>> as gcc has different calling conventions for int and struct {int}.
>>> However, future compilers
>>> might be better at passing struct{int} by value in which case we might
>>> want to change
>>> the definition of ERL_NIF_TERM.
>>>
>>> What then? Do we ignore CUSTOM_NIF_TERM_TYPE in such a scenario?
>>>
>>>
>>> /Sverker, Erlang/OTP
>>>
>>>
>>>
>>> On 02/07/2014 06:34 PM, Daniel Goertzen wrote:
>>>
>>> When writing NIFs in C++, it is impossible to employ C++ function
>>> overloading because the underlying type of ERL_NIF_TERM is "unsigned
>>> int".
>>> For example:
>>>
>>> // won't compile :(
>>> #include
>>> void my_func(ERL_NIF_TERM a) {...}
>>> void my_func(unsigned int a) {...}
>>>
>>>
>>> This patch allows NIF authors to mutate the type of ERL_NIF_TERM by
>>> defining the macro CUSTOM_NIF_TERM_TYPE(). In the example below, the
>>> underlying unsigned integer type gets wrapped as a C++11 typed
>>> enumeration. The type of ERL_NIF_TERM is now unique and can be used in
>>> overloaded functions.
>>>
>>> // compiles! :)
>>> #define CUSTOM_NIF_TERM_TYPE(Type) enum class ERL_NIF_TERM : Type {};
>>> #include
>>> void my_func(ERL_NIF_TERM a) {...}
>>> void my_func(unsigned int a) {...}
>>>
>>>
>>> The patch has no impact on erl_nif.h if CUSTOM_NIF_TERM_TYPE is not
>>> defined
>>> (other than flipping the definition order of ERL_NIF_TERM and
>>> ERL_NIF_UINT).
>>>
>>> A similar approach has been used on my C++11 NIF wrapper (
>>> https://github.com/goertzenator/nifpp). The wrapper requires manual
>>>
>>> installation of a similar patch, and I would love to remove that
>>> requirement.
>>>
>>> Regards,
>>> Dan.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-patches mailing listerlang-patches@REDACTED://
>>> erlang.org/mailman/listinfo/erlang-patches
>>>
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From tuncer.ayaz@REDACTED Fri Feb 14 21:48:28 2014
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Fri, 14 Feb 2014 21:48:28 +0100
Subject: [erlang-patches] compiler: update 'asm' deprecation message
Message-ID:
Adapt 'asm' deprecation message to new version scheme.
https://github.com/erlang/otp/pull/241
https://github.com/erlang/otp/pull/241.patch
git fetch git://github.com/tuncer/otp.git update-deprecation-message
From henrik@REDACTED Mon Feb 17 07:51:30 2014
From: henrik@REDACTED (Henrik Nord)
Date: Mon, 17 Feb 2014 07:51:30 +0100
Subject: [erlang-patches] compiler: update 'asm' deprecation message
In-Reply-To:
References:
Message-ID: <5301B172.3030802@erlang.org>
Thank you Tuncer.
On 2014-02-14 21:48, Tuncer Ayaz wrote:
> Adapt 'asm' deprecation message to new version scheme.
>
> https://github.com/erlang/otp/pull/241
> https://github.com/erlang/otp/pull/241.patch
>
> git fetch git://github.com/tuncer/otp.git update-deprecation-message
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/Henrik Nord Erlang/OTP
From henrik@REDACTED Mon Feb 17 07:56:16 2014
From: henrik@REDACTED (Henrik Nord)
Date: Mon, 17 Feb 2014 07:56:16 +0100
Subject: [erlang-patches] implement maps support in jinterface
In-Reply-To:
References:
Message-ID: <5301B290.1050501@erlang.org>
Thank you for your contribution.
Patch is merged to master.
On 2014-02-11 14:24, Vlad Dumitrescu wrote:
> The API and implementation are simplistic, like for lists and tuples,
> using arrays and without any connection to java.util.Map.
>
> git fetch git://github.com/vladdu/jinterface_maps
>
> https://github.com/vladdu/otp/compare/erlang:master...jinterface_maps
> https://github.com/vladdu/otp/compare/erlang:master...jinterface_maps.patch
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/Henrik Nord Erlang/OTP
From henrik@REDACTED Mon Feb 17 07:59:14 2014
From: henrik@REDACTED (Henrik Nord)
Date: Mon, 17 Feb 2014 07:59:14 +0100
Subject: [erlang-patches] human readable strings from {Errorline, Module,
ErrorDescriptor}
In-Reply-To:
References:
Message-ID: <5301B342.6070601@erlang.org>
Hello
I will take a look at this today.
If possible, try to follow
https://github.com/erlang/otp/wiki/Submitting-patches when submitting a
patch.
Even minor ones, if you make use of githubs "pull-request" it will save
us alot of manual labor.
On 2014-02-11 14:09, David Welton wrote:
> This is very minor, so I'm just sending a patch here:
>
> --- a/lib/stdlib/doc/src/erl_parse.xml
> +++ b/lib/stdlib/doc/src/erl_parse.xml
> @@ -200,6 +200,12 @@
>
>
> Module:format_error(ErrorDescriptor)
> +
> + It is also possible to obtain a human-readable string
> describing the error with this function:
> +
> +
> + file:format_error({Errorline, Module, ErrorDescriptor})
> +
>
>
>
>
> This could also be added to io.xml, epp.xml, erl_lint.xml and erl_scan.xml.
>
> If needs be, I guess I could create a branch, pull request, and so on.
>
--
/Henrik Nord Erlang/OTP
From henrik@REDACTED Mon Feb 17 10:00:06 2014
From: henrik@REDACTED (Henrik Nord)
Date: Mon, 17 Feb 2014 10:00:06 +0100
Subject: [erlang-patches] Non-overlapping Application Distribution Node
Sets
In-Reply-To:
References: <20130503080752.GZ21384@aluminium> <51837891.9020207@erlang.org>
<20130503134345.GB21384@aluminium> <5188BDFB.8090703@erlang.org>
<20130508133013.GR31110@aluminium.local> <518A5581.2080401@erlang.org>
<20130613091638.GE32127@aluminium.local>
<20130614033619.GF32127@aluminium.local>
Message-ID: <5301CF96.5070507@erlang.org>
Ping!
On 2013-06-19 16:01, Siri Hansen wrote:
> Hi Vance,
>
> we have decided that we would like to take in this functionality if
> the bug I mentioned in my last mail is corrected and some more
> extensive tests are added. We also need an update of the
> documentation, of course.
>
> Thanks for your contribution!
> /siri
>
>
> 2013/6/14 Vance Shipley >
>
> On Thu, Jun 13, 2013 at 02:46:38PM +0530, Vance Shipley wrote:
> } The use case is simply that we run the same application on each
> node in
> } a distributed Erlang cluster and want to designate a standby
> node for
> } each as depicted below:
>
> Siri,
>
> For further clarification I should add that the node pairs need to
> know about each other because they use distributed mnesia. The node
> pairs which may run an instance of an application each maintain a copy
> of the mnesia tables which they need to run. If serverA fails node2
> will take over it's app1 instance and continue operation with the
> current
> tables. The problem comes in with the fact that the active nodes all
> use mnesia distribution and pg2 betwen them (e.g. node & node4) as
> well.
>
> --
> -Vance
>
>
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/Henrik Nord Erlang/OTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From davidnwelton@REDACTED Mon Feb 17 10:39:30 2014
From: davidnwelton@REDACTED (David Welton)
Date: Mon, 17 Feb 2014 10:39:30 +0100
Subject: [erlang-patches] human readable strings from {Errorline, Module,
ErrorDescriptor}
In-Reply-To: <5301B342.6070601@erlang.org>
References:
<5301B342.6070601@erlang.org>
Message-ID:
Ok, I think I can follow that and do a pull request with all the man
pages to patch if the basic information to include in the patch makes
sense. If it should not be included there, I guess no one needs to do
any work.
Thanks.
BTW, that page says:
"whether it is a bug-fix och if it is a new feature"
'och' should probably be 'or'. I took the liberty of changing it.
On Mon, Feb 17, 2014 at 7:59 AM, Henrik Nord wrote:
> Hello
>
> I will take a look at this today.
>
> If possible, try to follow
> https://github.com/erlang/otp/wiki/Submitting-patches when submitting a
> patch.
> Even minor ones, if you make use of githubs "pull-request" it will save us
> alot of manual labor.
>
>
> On 2014-02-11 14:09, David Welton wrote:
>>
>> This is very minor, so I'm just sending a patch here:
>>
>> --- a/lib/stdlib/doc/src/erl_parse.xml
>> +++ b/lib/stdlib/doc/src/erl_parse.xml
>> @@ -200,6 +200,12 @@
>>
>>
>> Module:format_error(ErrorDescriptor)
>> +
>> + It is also possible to obtain a human-readable string
>> describing the error with this function:
>> +
>> +
>> + file:format_error({Errorline, Module, ErrorDescriptor})
>> +
>>
>>
>>
>>
>> This could also be added to io.xml, epp.xml, erl_lint.xml and
>> erl_scan.xml.
>>
>> If needs be, I guess I could create a branch, pull request, and so on.
>>
>
> --
> /Henrik Nord Erlang/OTP
>
--
David N. Welton
http://www.welton.it/davidw/
http://www.dedasys.com/
From pierrefenoll@REDACTED Mon Feb 17 13:34:40 2014
From: pierrefenoll@REDACTED (Pierre Fenoll)
Date: Mon, 17 Feb 2014 13:34:40 +0100
Subject: [erlang-patches] human readable strings from {Errorline, Module,
ErrorDescriptor}
In-Reply-To:
References:
<5301B342.6070601@erlang.org>
Message-ID:
Hey David,
Maybe there are more man pages to change:
http://erldocs.com/?search=format_error#format_error
I did not look into all of those modules but I guess some may lack the
information you're adding.
Cheers,
--
Pierre Fenoll
On 17 February 2014 10:39, David Welton wrote:
> Ok, I think I can follow that and do a pull request with all the man
> pages to patch if the basic information to include in the patch makes
> sense. If it should not be included there, I guess no one needs to do
> any work.
>
> Thanks.
>
> BTW, that page says:
>
> "whether it is a bug-fix och if it is a new feature"
>
> 'och' should probably be 'or'. I took the liberty of changing it.
>
>
> On Mon, Feb 17, 2014 at 7:59 AM, Henrik Nord wrote:
> > Hello
> >
> > I will take a look at this today.
> >
> > If possible, try to follow
> > https://github.com/erlang/otp/wiki/Submitting-patches when submitting a
> > patch.
> > Even minor ones, if you make use of githubs "pull-request" it will save
> us
> > alot of manual labor.
> >
> >
> > On 2014-02-11 14:09, David Welton wrote:
> >>
> >> This is very minor, so I'm just sending a patch here:
> >>
> >> --- a/lib/stdlib/doc/src/erl_parse.xml
> >> +++ b/lib/stdlib/doc/src/erl_parse.xml
> >> @@ -200,6 +200,12 @@
> >>
> >>
> >> Module:format_error(ErrorDescriptor)
> >> +
> >> + It is also possible to obtain a human-readable string
> >> describing the error with this function:
> >> +
> >> +
> >> + file:format_error({Errorline, Module, ErrorDescriptor})
> >> +
> >>
> >>
> >>
> >>
> >> This could also be added to io.xml, epp.xml, erl_lint.xml and
> >> erl_scan.xml.
> >>
> >> If needs be, I guess I could create a branch, pull request, and so on.
> >>
> >
> > --
> > /Henrik Nord Erlang/OTP
> >
>
>
>
> --
> David N. Welton
>
> http://www.welton.it/davidw/
>
> http://www.dedasys.com/
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vances@REDACTED Tue Feb 18 09:39:18 2014
From: vances@REDACTED (Vance Shipley)
Date: Tue, 18 Feb 2014 14:09:18 +0530
Subject: [erlang-patches] Non-overlapping Application Distribution Node
Sets
In-Reply-To: <5301CF96.5070507@erlang.org>
References: <51837891.9020207@erlang.org> <20130503134345.GB21384@aluminium>
<5188BDFB.8090703@erlang.org>
<20130508133013.GR31110@aluminium.local>
<518A5581.2080401@erlang.org>
<20130613091638.GE32127@aluminium.local>
<20130614033619.GF32127@aluminium.local>
<5301CF96.5070507@erlang.org>
Message-ID: <20140218083918.GJ96250@wavenets-mbp.motivity.ca>
Henrik,
Yes, I haven't forgotten about this. It will get the required attention
in the next few weeks.
--
-Vance
On Mon, Feb 17, 2014 at 10:00:06AM +0100, Henrik Nord wrote:
} Ping!
}
}
}
} On 2013-06-19 16:01, Siri Hansen wrote:
} >Hi Vance,
} >
} >we have decided that we would like to take in this functionality
} >if the bug I mentioned in my last mail is corrected and some more
} >extensive tests are added. We also need an update of the
} >documentation, of course.
} >
} >Thanks for your contribution!
} >/siri
} >
} >
} >2013/6/14 Vance Shipley >
} >
} > On Thu, Jun 13, 2013 at 02:46:38PM +0530, Vance Shipley wrote:
} > } The use case is simply that we run the same application on each
} > node in
} > } a distributed Erlang cluster and want to designate a standby
} > node for
} > } each as depicted below:
} >
} > Siri,
} >
} > For further clarification I should add that the node pairs need to
} > know about each other because they use distributed mnesia. The node
} > pairs which may run an instance of an application each maintain a copy
} > of the mnesia tables which they need to run. If serverA fails node2
} > will take over it's app1 instance and continue operation with the
} > current
} > tables. The problem comes in with the fact that the active nodes all
} > use mnesia distribution and pg2 betwen them (e.g. node & node4) as
} > well.
} >
} > --
} > -Vance
} >
} >
} >
} >
} >_______________________________________________
} >erlang-patches mailing list
} >erlang-patches@REDACTED
} >http://erlang.org/mailman/listinfo/erlang-patches
}
} --
} /Henrik Nord Erlang/OTP
}
--
-Vance
From tuncer.ayaz@REDACTED Tue Feb 18 19:48:43 2014
From: tuncer.ayaz@REDACTED (Tuncer Ayaz)
Date: Tue, 18 Feb 2014 19:48:43 +0100
Subject: [erlang-patches] Silent rules fixes
Message-ID:
* Default enable silent rules
* Use correct variable name for silent rule C++ compiler
https://github.com/erlang/otp/pull/243
https://github.com/erlang/otp/pull/243.patch
git fetch git://github.com/tuncer/otp.git silent-rules
From daniel.goertzen@REDACTED Tue Feb 18 20:55:33 2014
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Tue, 18 Feb 2014 13:55:33 -0600
Subject: [erlang-patches] maps: pattern-match absent key?
Message-ID:
Is there a way to pattern-match the absence of a key in a map?
Dan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From wallentin.dahlberg@REDACTED Tue Feb 18 21:23:00 2014
From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=)
Date: Tue, 18 Feb 2014 21:23:00 +0100
Subject: [erlang-patches] maps: pattern-match absent key?
In-Reply-To:
References:
Message-ID:
Yes, with fail clauses.
f(#{ a := _ }) -> {a,present};
f(_) -> {a,absent}.
2014-02-18 20:55 GMT+01:00 Daniel Goertzen :
> Is there a way to pattern-match the absence of a key in a map?
>
> Dan.
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rzezeski@REDACTED Wed Feb 19 01:59:55 2014
From: rzezeski@REDACTED (Ryan Zezeski)
Date: Tue, 18 Feb 2014 19:59:55 -0500
Subject: [erlang-patches] Fix DTrace build on Illumos
In-Reply-To: <52F258BF.3080108@erlang.org>
References:
<52A71690.7000808@erlang.org>
<52F12255.6050704@erlang.org>
<52F258BF.3080108@erlang.org>
Message-ID:
Hi Lukas,
On Wed, Feb 5, 2014 at 10:29 AM, Lukas Larsson wrote:
>
> Would you mind testing my modifications on Illumos? You can get them
> here[1], I've tested on os x and freebsd.
>
Sorry for the delay. I tested on SmartOS and everything worked (I made sure
the probes showed up).
-Z
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From henrik@REDACTED Wed Feb 19 09:58:16 2014
From: henrik@REDACTED (Henrik Nord)
Date: Wed, 19 Feb 2014 09:58:16 +0100
Subject: [erlang-patches] Silent rules fixes
In-Reply-To:
References:
Message-ID: <53047228.7020100@erlang.org>
Thank you for your contribution!
On 2014-02-18 19:48, Tuncer Ayaz wrote:
> * Default enable silent rules
> * Use correct variable name for silent rule C++ compiler
>
> https://github.com/erlang/otp/pull/243
> https://github.com/erlang/otp/pull/243.patch
>
> git fetch git://github.com/tuncer/otp.git silent-rules
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/Henrik Nord Erlang/OTP
From lukas@REDACTED Wed Feb 19 10:28:16 2014
From: lukas@REDACTED (Lukas Larsson)
Date: Wed, 19 Feb 2014 10:28:16 +0100
Subject: [erlang-patches] Fix DTrace build on Illumos
In-Reply-To:
References:
<52A71690.7000808@erlang.org>
<52F12255.6050704@erlang.org>
<52F258BF.3080108@erlang.org>
Message-ID: <53047930.40307@erlang.org>
On 19/02/14 01:59, Ryan Zezeski wrote:
> Hi Lukas,
>
> On Wed, Feb 5, 2014 at 10:29 AM, Lukas Larsson > wrote:
>
> Would you mind testing my modifications on Illumos? You can get
> them here[1], I've tested on os x and freebsd.
>
>
> Sorry for the delay. I tested on SmartOS and everything worked (I made
> sure the probes showed up).
Great! thanks!
Lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From henrik@REDACTED Thu Feb 20 14:41:37 2014
From: henrik@REDACTED (Henrik Nord)
Date: Thu, 20 Feb 2014 14:41:37 +0100
Subject: [erlang-patches] Information Release dates and patching summary
Message-ID: <53060611.1080703@erlang.org>
Hello Erlang-patches!
This is a summary email that will be sent out to the erlang-patches list
from time to time. In this email you will find information regarding
code-stops, release dates, and useful links to ease your patching.
I will also take this opportunity to describe our way of working and
testing.
RELEASE DATES
Below you can find the planned release dates, and code stop dates for 17.0.
Note: We will not accept any NEW feature patches for inclusion in
Erlang/OTP 17.0 after 2014-02-21.
Preliminary dates for the upcoming release:
Release: erts, emu,comp |Code stop |Documentation
stop |Release Date
17.0-rc2 2014-02-21 2014-02-21 2014-02-21
2014-02-26
17.0 2014-03-10 2014-03-17 2014-03-19
2014-03-26
We will focus the time between 17.0-rc2 and 17.0 on bug fixes,
improvements, and testing. Therefore you are most welcome to submit
patches regarding such issues and we will try our best to include them
before 17.0 is released.
Especially bugs introduced in 17.0-rcX.
PATCHES:
Make sure to look at our Github wiki page before submitting a patch to
Erlang/OTP
https://github.com/erlang/otp/wiki
We also have a page on Erlang.org concerning the status of submitted patches
http://www.erlang.org/development/
There you can find information about patches that are "awaiting_action",
Waiting for the topic author to correct one thing or another.
Assigned to a team within Erlang/OTP, to be reviewed and approved/dropped.
Or scroll through the list of graduated patches since R16B.
We currently have ~25 patches that are "awaiting_action".
There is a total of 27 patches that are assigned to a developer or a
team, awaiting their review. And we have 5 patches that are approved but
still needs to pass our nightly builds and tests.
After a request from the Industrial Erlang User Group, we started using
Github pull requests for accepting patches into Erlang/OTP. This has
resulted in over 200 pull requests sent in less than 8 months of
accepting pull requests.
We are looking into ways of improving this especially in regards to
information preservation.
BEFORE SUBMITTING A PATCH:
To facilitate a faster review process please make sure that your commit
message conforms to the rules at the github wiki page.
https://github.com/erlang/otp/wiki/Writing-good-commit-messages
Make sure that your code compiles.
Make sure that all tests for the changed application pass.
If applicable you will be asked to add tests and documentation for your
patch.
TESTING:
We currently test on ~60 different setups, including but not limited to
Bsd, linux, solaris, darwin and windows. This includes different
hardware as well as software. This sums up to about ~850 000 test cases
each night. We also run dialyzer and cover.
Unfortunately the test coverage is not 100% in all tools and
applications. Some tools and applications have bad or missing tests.
This is something we aim to improve and you are all invited to help by
submitting patches in these areas.
When we are aiming for a new major release, as we currently are, all
platforms tests the master branch. When we are releasing a minor
version, we have a reasonable split amongst the test platforms so that
we still run tests for the master branch and new features.
All builds consists of a mix of internal development branches, and open
source contributions. This limits the amount of open source branches we
are willing to test at the same time. We do not wish them to interfere
with our branches or other open source branches.
This might be another reason as to why your branch is not tested for a
few days.
Useful links
https://github.com/erlang/otp/wiki
http://www.erlang.org/development/
https://github.com/erlang/otp/wiki/Writing-good-commit-messages
--
/Henrik Nord Erlang/OTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mononcqc@REDACTED Thu Feb 20 14:49:23 2014
From: mononcqc@REDACTED (Fred Hebert)
Date: Thu, 20 Feb 2014 08:49:23 -0500
Subject: [erlang-patches] Information Release dates and patching summary
In-Reply-To: <53060611.1080703@erlang.org>
References: <53060611.1080703@erlang.org>
Message-ID: <20140220134922.GX62889@ferdair.local>
http://www.erlang.org/development/ looks totally sweet as page to follow
development, and the graduated page is neat. Any idea when there will be
content in "What you could do"?
On 02/20, Henrik Nord wrote:
> Hello Erlang-patches!
>
> This is a summary email that will be sent out to the erlang-patches list
> from time to time. In this email you will find information regarding
> code-stops, release dates, and useful links to ease your patching.
>
> I will also take this opportunity to describe our way of working and
> testing.
>
> RELEASE DATES
>
> Below you can find the planned release dates, and code stop dates for 17.0.
> Note: We will not accept any NEW feature patches for inclusion in Erlang/OTP
> 17.0 after 2014-02-21.
>
> Preliminary dates for the upcoming release:
> Release: erts, emu,comp |Code stop |Documentation stop
> |Release Date
> 17.0-rc2 2014-02-21 2014-02-21 2014-02-21
> 2014-02-26
> 17.0 2014-03-10 2014-03-17 2014-03-19
> 2014-03-26
>
> We will focus the time between 17.0-rc2 and 17.0 on bug fixes, improvements,
> and testing. Therefore you are most welcome to submit patches regarding such
> issues and we will try our best to include them before 17.0 is released.
> Especially bugs introduced in 17.0-rcX.
>
> PATCHES:
>
> Make sure to look at our Github wiki page before submitting a patch to
> Erlang/OTP
> https://github.com/erlang/otp/wiki
>
> We also have a page on Erlang.org concerning the status of submitted patches
> http://www.erlang.org/development/
>
> There you can find information about patches that are "awaiting_action",
> Waiting for the topic author to correct one thing or another.
> Assigned to a team within Erlang/OTP, to be reviewed and approved/dropped.
> Or scroll through the list of graduated patches since R16B.
>
> We currently have ~25 patches that are "awaiting_action".
> There is a total of 27 patches that are assigned to a developer or a team,
> awaiting their review. And we have 5 patches that are approved but still
> needs to pass our nightly builds and tests.
>
> After a request from the Industrial Erlang User Group, we started using
> Github pull requests for accepting patches into Erlang/OTP. This has
> resulted in over 200 pull requests sent in less than 8 months of accepting
> pull requests.
> We are looking into ways of improving this especially in regards to
> information preservation.
>
>
> BEFORE SUBMITTING A PATCH:
>
> To facilitate a faster review process please make sure that your commit
> message conforms to the rules at the github wiki page.
> https://github.com/erlang/otp/wiki/Writing-good-commit-messages
> Make sure that your code compiles.
> Make sure that all tests for the changed application pass.
>
> If applicable you will be asked to add tests and documentation for your
> patch.
>
> TESTING:
>
> We currently test on ~60 different setups, including but not limited to Bsd,
> linux, solaris, darwin and windows. This includes different hardware as well
> as software. This sums up to about ~850 000 test cases each night. We also
> run dialyzer and cover.
>
> Unfortunately the test coverage is not 100% in all tools and applications.
> Some tools and applications have bad or missing tests. This is something we
> aim to improve and you are all invited to help by submitting patches in
> these areas.
>
> When we are aiming for a new major release, as we currently are, all
> platforms tests the master branch. When we are releasing a minor version, we
> have a reasonable split amongst the test platforms so that we still run
> tests for the master branch and new features.
>
> All builds consists of a mix of internal development branches, and open
> source contributions. This limits the amount of open source branches we are
> willing to test at the same time. We do not wish them to interfere with our
> branches or other open source branches.
> This might be another reason as to why your branch is not tested for a few
> days.
>
>
> Useful links
> https://github.com/erlang/otp/wiki
> http://www.erlang.org/development/
> https://github.com/erlang/otp/wiki/Writing-good-commit-messages
>
> --
> /Henrik Nord Erlang/OTP
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
From henrik@REDACTED Thu Feb 20 14:54:25 2014
From: henrik@REDACTED (Henrik Nord)
Date: Thu, 20 Feb 2014 14:54:25 +0100
Subject: [erlang-patches] Information Release dates and patching summary
In-Reply-To: <20140220134922.GX62889@ferdair.local>
References: <53060611.1080703@erlang.org>
<20140220134922.GX62889@ferdair.local>
Message-ID: <53060911.3020105@erlang.org>
On 2014-02-20 14:49, Fred Hebert wrote:
> http://www.erlang.org/development/ looks totally sweet as page to follow
> development, and the graduated page is neat. Any idea when there will be
> content in "What you could do"?
>
No ETA at this time. I will try to keep you all posted.
There are tests missing in a number of places, that is always a good
place to start ;D
If there are specific questions and or suggestions go ahead.
--
/Henrik Nord Erlang/OTP
From jose.valim@REDACTED Thu Feb 20 15:04:35 2014
From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=)
Date: Thu, 20 Feb 2014 15:04:35 +0100
Subject: [erlang-patches] Information Release dates and patching summary
In-Reply-To: <53060611.1080703@erlang.org>
References: <53060611.1080703@erlang.org>
Message-ID:
The development page indeed looks really nice!
I am really excited about the release dates too.
Thanks for all the work and info!
*Jos? Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Lead Developer
On Thu, Feb 20, 2014 at 2:41 PM, Henrik Nord wrote:
> Hello Erlang-patches!
>
> This is a summary email that will be sent out to the erlang-patches list
> from time to time. In this email you will find information regarding
> code-stops, release dates, and useful links to ease your patching.
>
> I will also take this opportunity to describe our way of working and
> testing.
>
> RELEASE DATES
>
> Below you can find the planned release dates, and code stop dates for 17.0.
> Note: We will not accept any NEW feature patches for inclusion in
> Erlang/OTP 17.0 after 2014-02-21.
>
> Preliminary dates for the upcoming release:
> Release: erts, emu,comp |Code stop |Documentation stop
> |Release Date
> 17.0-rc2 2014-02-21 2014-02-21 2014-02-21
> 2014-02-26
> 17.0 2014-03-10 2014-03-17 2014-03-19
> 2014-03-26
>
> We will focus the time between 17.0-rc2 and 17.0 on bug fixes,
> improvements, and testing. Therefore you are most welcome to submit patches
> regarding such issues and we will try our best to include them before 17.0
> is released.
> Especially bugs introduced in 17.0-rcX.
>
> PATCHES:
>
> Make sure to look at our Github wiki page before submitting a patch to
> Erlang/OTP
> https://github.com/erlang/otp/wiki
>
> We also have a page on Erlang.org concerning the status of submitted
> patches
> http://www.erlang.org/development/
>
> There you can find information about patches that are "awaiting_action",
> Waiting for the topic author to correct one thing or another.
> Assigned to a team within Erlang/OTP, to be reviewed and approved/dropped.
> Or scroll through the list of graduated patches since R16B.
>
> We currently have ~25 patches that are "awaiting_action".
> There is a total of 27 patches that are assigned to a developer or a team,
> awaiting their review. And we have 5 patches that are approved but still
> needs to pass our nightly builds and tests.
>
> After a request from the Industrial Erlang User Group, we started using
> Github pull requests for accepting patches into Erlang/OTP. This has
> resulted in over 200 pull requests sent in less than 8 months of accepting
> pull requests.
> We are looking into ways of improving this especially in regards to
> information preservation.
>
>
> BEFORE SUBMITTING A PATCH:
>
> To facilitate a faster review process please make sure that your commit
> message conforms to the rules at the github wiki page.
> https://github.com/erlang/otp/wiki/Writing-good-commit-messages
> Make sure that your code compiles.
> Make sure that all tests for the changed application pass.
>
> If applicable you will be asked to add tests and documentation for your
> patch.
>
> TESTING:
>
> We currently test on ~60 different setups, including but not limited to
> Bsd, linux, solaris, darwin and windows. This includes different hardware
> as well as software. This sums up to about ~850 000 test cases each night.
> We also run dialyzer and cover.
>
> Unfortunately the test coverage is not 100% in all tools and applications.
> Some tools and applications have bad or missing tests. This is something we
> aim to improve and you are all invited to help by submitting patches in
> these areas.
>
> When we are aiming for a new major release, as we currently are, all
> platforms tests the master branch. When we are releasing a minor version,
> we have a reasonable split amongst the test platforms so that we still run
> tests for the master branch and new features.
>
> All builds consists of a mix of internal development branches, and open
> source contributions. This limits the amount of open source branches we are
> willing to test at the same time. We do not wish them to interfere with our
> branches or other open source branches.
> This might be another reason as to why your branch is not tested for a few
> days.
>
>
> Useful links
> https://github.com/erlang/otp/wiki
> http://www.erlang.org/development/
> https://github.com/erlang/otp/wiki/Writing-good-commit-messages
>
> --
> /Henrik Nord Erlang/OTP
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dizzyd@REDACTED Thu Feb 20 15:43:12 2014
From: dizzyd@REDACTED (Dave Smith)
Date: Thu, 20 Feb 2014 07:43:12 -0700
Subject: [erlang-patches] Information Release dates and patching summary
In-Reply-To: <53060611.1080703@erlang.org>
References: <53060611.1080703@erlang.org>
Message-ID:
This is an excellent step in direction of further transparency and
community engagement. I realize it also bears an increased load on the
Erlang/OTP team, so thank you for being willing to do this. :)
D.
On Thu, Feb 20, 2014 at 6:41 AM, Henrik Nord wrote:
> Hello Erlang-patches!
>
> This is a summary email that will be sent out to the erlang-patches list
> from time to time. In this email you will find information regarding
> code-stops, release dates, and useful links to ease your patching.
>
> I will also take this opportunity to describe our way of working and
> testing.
>
> RELEASE DATES
>
> Below you can find the planned release dates, and code stop dates for 17.0.
> Note: We will not accept any NEW feature patches for inclusion in Erlang/OTP
> 17.0 after 2014-02-21.
>
> Preliminary dates for the upcoming release:
> Release: erts, emu,comp |Code stop |Documentation stop
> |Release Date
> 17.0-rc2 2014-02-21 2014-02-21 2014-02-21
> 2014-02-26
> 17.0 2014-03-10 2014-03-17 2014-03-19
> 2014-03-26
>
> We will focus the time between 17.0-rc2 and 17.0 on bug fixes, improvements,
> and testing. Therefore you are most welcome to submit patches regarding such
> issues and we will try our best to include them before 17.0 is released.
> Especially bugs introduced in 17.0-rcX.
>
> PATCHES:
>
> Make sure to look at our Github wiki page before submitting a patch to
> Erlang/OTP
> https://github.com/erlang/otp/wiki
>
> We also have a page on Erlang.org concerning the status of submitted patches
> http://www.erlang.org/development/
>
> There you can find information about patches that are "awaiting_action",
> Waiting for the topic author to correct one thing or another.
> Assigned to a team within Erlang/OTP, to be reviewed and approved/dropped.
> Or scroll through the list of graduated patches since R16B.
>
> We currently have ~25 patches that are "awaiting_action".
> There is a total of 27 patches that are assigned to a developer or a team,
> awaiting their review. And we have 5 patches that are approved but still
> needs to pass our nightly builds and tests.
>
> After a request from the Industrial Erlang User Group, we started using
> Github pull requests for accepting patches into Erlang/OTP. This has
> resulted in over 200 pull requests sent in less than 8 months of accepting
> pull requests.
> We are looking into ways of improving this especially in regards to
> information preservation.
>
>
> BEFORE SUBMITTING A PATCH:
>
> To facilitate a faster review process please make sure that your commit
> message conforms to the rules at the github wiki page.
> https://github.com/erlang/otp/wiki/Writing-good-commit-messages
> Make sure that your code compiles.
> Make sure that all tests for the changed application pass.
>
> If applicable you will be asked to add tests and documentation for your
> patch.
>
> TESTING:
>
> We currently test on ~60 different setups, including but not limited to Bsd,
> linux, solaris, darwin and windows. This includes different hardware as well
> as software. This sums up to about ~850 000 test cases each night. We also
> run dialyzer and cover.
>
> Unfortunately the test coverage is not 100% in all tools and applications.
> Some tools and applications have bad or missing tests. This is something we
> aim to improve and you are all invited to help by submitting patches in
> these areas.
>
> When we are aiming for a new major release, as we currently are, all
> platforms tests the master branch. When we are releasing a minor version, we
> have a reasonable split amongst the test platforms so that we still run
> tests for the master branch and new features.
>
> All builds consists of a mix of internal development branches, and open
> source contributions. This limits the amount of open source branches we are
> willing to test at the same time. We do not wish them to interfere with our
> branches or other open source branches.
> This might be another reason as to why your branch is not tested for a few
> days.
>
>
> Useful links
> https://github.com/erlang/otp/wiki
> http://www.erlang.org/development/
> https://github.com/erlang/otp/wiki/Writing-good-commit-messages
>
> --
> /Henrik Nord Erlang/OTP
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>
From henrik@REDACTED Fri Feb 21 13:04:40 2014
From: henrik@REDACTED (Henrik Nord)
Date: Fri, 21 Feb 2014 13:04:40 +0100
Subject: [erlang-patches] Information Release dates and patching summary
In-Reply-To: <53060611.1080703@erlang.org>
References: <53060611.1080703@erlang.org>
Message-ID: <530740D8.6090900@erlang.org>
>
> We also have a page on Erlang.org concerning the status of submitted
> patches
> http://www.erlang.org/development/
>
> There you can find information about patches that are
> "awaiting_action", Waiting for the topic author to correct one thing
> or another.
> Assigned to a team within Erlang/OTP, to be reviewed and approved/dropped.
> Or scroll through the list of graduated patches since R16B.
>
> We currently have ~25 patches that are "awaiting_action".
> There is a total of 27 patches that are assigned to a developer or a
> team, awaiting their review. And we have 5 patches that are approved
> but still needs to pass our nightly builds and tests.
>
>
Now it is actually displaying this.
--
/Henrik Nord Erlang/OTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From roger@REDACTED Fri Feb 21 17:43:42 2014
From: roger@REDACTED (Roger Lipscombe)
Date: Fri, 21 Feb 2014 16:43:42 +0000
Subject: [erlang-patches] SSL verify_fun documentation is incorrect
Message-ID:
In http://www.erlang.org/doc/man/ssl.html, the spec for Event is
missing the valid and valid_peer options. These are documented (sorta)
further down in the page, but the spec is missing them.
I _believe_ that this is the correct patch:
diff --git a/lib/ssl/doc/src/ssl.xml b/lib/ssl/doc/src/ssl.xml
index 80ef419..4513ecd 100644
--- a/lib/ssl/doc/src/ssl.xml
+++ b/lib/ssl/doc/src/ssl.xml
@@ -233,7 +233,7 @@
fun(OtpCert :: #'OTPCertificate'{}, Event :: {bad_cert, Reason :: atom()} |
- {extension, #'Extension'{}}, InitialUserState :: term()) ->
+ {extension, #'Extension'{}} | valid | valid_peer,
InitialUserState :: term()) ->
{valid, UserState :: term()} | {valid_peer, UserState :: term()} |
{fail, Reason :: term()} | {unknown, UserState :: term()}.
Regards,
Roger.
From henrik@REDACTED Mon Feb 24 07:51:21 2014
From: henrik@REDACTED (Henrik Nord)
Date: Mon, 24 Feb 2014 07:51:21 +0100
Subject: [erlang-patches] SSL verify_fun documentation is incorrect
In-Reply-To:
References:
Message-ID: <530AEBE9.7080003@erlang.org>
Hi!
Thank you for the patch.
Im not sure I can squeeze this into 17.0-rc2, if not it will have to
wait until 17.0 is released in March
On 2014-02-21 17:43, Roger Lipscombe wrote:
> In http://www.erlang.org/doc/man/ssl.html, the spec for Event is
> missing the valid and valid_peer options. These are documented (sorta)
> further down in the page, but the spec is missing them.
>
> I _believe_ that this is the correct patch:
>
> diff --git a/lib/ssl/doc/src/ssl.xml b/lib/ssl/doc/src/ssl.xml
> index 80ef419..4513ecd 100644
> --- a/lib/ssl/doc/src/ssl.xml
> +++ b/lib/ssl/doc/src/ssl.xml
> @@ -233,7 +233,7 @@
>
>
> fun(OtpCert :: #'OTPCertificate'{}, Event :: {bad_cert, Reason :: atom()} |
> - {extension, #'Extension'{}}, InitialUserState :: term()) ->
> + {extension, #'Extension'{}} | valid | valid_peer,
> InitialUserState :: term()) ->
> {valid, UserState :: term()} | {valid_peer, UserState :: term()} |
> {fail, Reason :: term()} | {unknown, UserState :: term()}.
>
>
> Regards,
> Roger.
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
--
/Henrik Nord Erlang/OTP
From daniel.goertzen@REDACTED Tue Feb 25 18:56:32 2014
From: daniel.goertzen@REDACTED (Daniel Goertzen)
Date: Tue, 25 Feb 2014 11:56:32 -0600
Subject: [erlang-patches] snmp agent inform w/AES privacy not working
In-Reply-To:
References:
Message-ID:
The SNMP agent AES initialization vector calculation is definitely wrong.
The IV is composed from the authoritative engine boots, engine time, and a
random locally generated number. The agent is currently always using the
*local* engine to get engine boots and engine time, which happens to be
correct for GET, SET, and TRAP, but is wrong for INFORM.
The attached patch fixes it. When composing a packet for transmission, the
existing code collects the correct engine parameters, so this patch just
uses those for the AES IV instead of going off and getting the wrong local
engine params. The patch looks bigger than it really is because the order
of packet composition had to be changed slightly.
With this patch applied, I am able to send AES encrypted informs. AES
encrypted traps also continued to work.
Cheers,
Dan.
On Mon, Feb 24, 2014 at 4:57 PM, Daniel Goertzen
wrote:
> I am struggling to get SNMP informs with AES privacy working. I have no
> problems with DES privacy on informs.
>
> In snmpa_usm.erl I see that the *local engine* boots and time is passed to
> snmp_usm:aes_encrypt() which forms part of the IV....
>
>
>
> However RFC 3826 states that the *authoritative* engine boots and time
> should be used, and in the case of informs the authoritative engine is the
> inform target engine, not the local engine....
>
> [from RFC 3826]
>
> 3.1.2.1. AES Encryption Key and IV
>
> The first 128 bits of the localized key Kul are used as the AES
> encryption key. The 128-bit IV is obtained as the concatenation of
> the authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP
> engine's 32-bit snmpEngineTime, and a local 64-bit integer. The 64-
> bit integer is initialized to a pseudo-random value at boot time.
>
>
>
> Could this be why AES privacy is not working for informs?
>
> Dan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snmp_agent_aes_bootstime_fix.patch
Type: text/x-patch
Size: 5007 bytes
Desc: not available
URL: