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: