From mc@REDACTED Fri Mar 1 20:15:30 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Fri, 1 Mar 2013 14:15:30 -0500 Subject: [erlang-patches] Implement add_report_sup_handler which calls gen_event:add_sup_handler Message-ID: Hi, This patch adds add_report_sup_handler to the error_logger module To eliminate the need to go around the error_logger api, this patch allows for a report_handler to be added via add_sup_handler. https://github.com/DeadZen/otp/compare/error-logger-sup_handler.patch https://github.com/DeadZen/otp/compare/error-logger-sup_handler git fetch git://github.com/DeadZen/otp.git error-logger-sup_handler -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman From hammingweight@REDACTED Sat Mar 2 06:17:49 2013 From: hammingweight@REDACTED (Carl Meijer) Date: Sat, 2 Mar 2013 07:17:49 +0200 Subject: [erlang-patches] HTTP PUT/POST fail when content-length is zero Message-ID: Hi, The content-length header is removed from PUTs/POSTs when the length is zero. Servers are rejecting PUTs/POSTs without the content length with a 411 response code RFC2616 states that a content length of zero is valid. I have added a test for this bug. I am not sure that I have added it to the correct suite (http_format_SUITE) but it does demonstrate the problem and that the proposed fix solves this problem (no tests in the inets suite break as a result of the change). git fetch git://github.com/hammingweight/otp.git bug-http-content-length-zero https://github.com/hammingweight/otp/compare/bug-http-content-length-zero https://github.com/hammingweight/otp/compare/bug-http-content-length-zero.patch Regards, Carl From essen@REDACTED Sat Mar 2 18:19:11 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Sat, 02 Mar 2013 18:19:11 +0100 Subject: [erlang-patches] Fix the title of hipe_app documentation page Message-ID: <5132348F.9030209@ninenines.eu> Please fetch this tiny tiny patch. git fetch git://github.com/essen/otp.git fix-hipe-doc-title https://github.com/essen/otp/compare/erlang:master...fix-hipe-doc-title https://github.com/essen/otp/compare/erlang:master...fix-hipe-doc-title.patch -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From fredrik@REDACTED Mon Mar 4 10:15:55 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 4 Mar 2013 10:15:55 +0100 Subject: [erlang-patches] Implement add_report_sup_handler which calls gen_event:add_sup_handler In-Reply-To: References: Message-ID: <5134664B.1000201@erlang.org> On 03/01/2013 08:15 PM, Pedram Nimreezi wrote: > Hi, > > This patch adds add_report_sup_handler to the error_logger module > > To eliminate the need to go around the error_logger api, this patch > allows for a report_handler to be added via add_sup_handler. > > https://github.com/DeadZen/otp/compare/error-logger-sup_handler.patch > https://github.com/DeadZen/otp/compare/error-logger-sup_handler > > git fetch git://github.com/DeadZen/otp.git error-logger-sup_handler > Hello Pedram! I have fetched your patch and it is currently cooking the 'pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Mar 4 10:16:38 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 4 Mar 2013 10:16:38 +0100 Subject: [erlang-patches] HTTP PUT/POST fail when content-length is zero In-Reply-To: References: Message-ID: <51346676.8080306@erlang.org> On 03/02/2013 06:17 AM, Carl Meijer wrote: > Hi, > > The content-length header is removed from PUTs/POSTs when the length > is zero. Servers are rejecting PUTs/POSTs without the content length > with a 411 response code > > RFC2616 states that a content length of zero is valid. > > I have added a test for this bug. I am not sure that I have added it > to the correct suite (http_format_SUITE) but it does demonstrate the > problem and that the proposed fix solves this problem (no tests in the > inets suite break as a result of the change). > > git fetch git://github.com/hammingweight/otp.git bug-http-content-length-zero > > https://github.com/hammingweight/otp/compare/bug-http-content-length-zero > > https://github.com/hammingweight/otp/compare/bug-http-content-length-zero.patch > > Regards, > Carl > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Carl, I've fetched your patch and it is currently cooking in the 'pu' branch. May be a duplicate patch on this matter but I'll look into it. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Mar 4 10:17:25 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 4 Mar 2013 10:17:25 +0100 Subject: [erlang-patches] Fix the title of hipe_app documentation page In-Reply-To: <5132348F.9030209@ninenines.eu> References: <5132348F.9030209@ninenines.eu> Message-ID: <513466A5.6030209@erlang.org> On 03/02/2013 06:19 PM, Lo?c Hoguin wrote: > Please fetch this tiny tiny patch. > > git fetch git://github.com/essen/otp.git fix-hipe-doc-title > > https://github.com/essen/otp/compare/erlang:master...fix-hipe-doc-title > > https://github.com/essen/otp/compare/erlang:master...fix-hipe-doc-title.patch > > Hello, I've fetched your patch and it is currently cooking in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From magnus@REDACTED Mon Mar 4 12:04:40 2013 From: magnus@REDACTED (Magnus Henoch) Date: Mon, 04 Mar 2013 11:04:40 +0000 Subject: [erlang-patches] Fix Flymake dependency in erlang-pkg.el In-Reply-To: (Steve Purcell's message of "Sun, 03 Mar 2013 12:08:48 +0000") References: Message-ID: Steve Purcell writes: > Hi Magnus, > >> I just tried installing the Emacs Erlang mode using the package >> definition in erlang-pkg.el, and found that the dependency declaration >> on "flymake-mode" is incorrect - it should be "flymake" instead. I also >> decreased the version requirement, as erlang-flymake.el works well with >> flymake version 0.3 (the one that comes with Emacs). > > I believe this fix is insufficient for Emacs 23. In that version, there > is no bundled `package.el`, and the one which is downloadable does not > recognise Emacs built-in libraries as packages. ie. on Emacs 23, the > "flymake" dependency would be unsatisfied. > > IMO a better solution would be to omit the dependency altogether, since > flymake has been standard since (at least) Emacs 23. > > I'm a maintainer of MELPA (http://melpa.milkbox.net/), which is an Emacs > package repository which automatically builds elisp packages from > upstream source control repositories, so I'm happy that you've addressed > this issue, because the Erlang package has indeed become uninstallable > on all Emacs versions due to the "flymake-mode" dependency you fixed. > > Would you be able to submit a patch replacing the '(flymake-mode "0.3") > with a nil, or should I? Nice catch. Here is the new version of the patch (on top of the maint branch): git fetch git://github.com/legoscia/otp.git fix-emacs-pkg-flymake-dep https://github.com/legoscia/otp/compare/legoscia:fix-emacs-pkg-flymake-dep https://github.com/legoscia/otp/compare/legoscia:fix-emacs-pkg-flymake-dep.patch Regards, Magnus From fredrik@REDACTED Mon Mar 4 12:07:42 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 4 Mar 2013 12:07:42 +0100 Subject: [erlang-patches] Fix Flymake dependency in erlang-pkg.el In-Reply-To: References: Message-ID: <5134807E.10603@erlang.org> On 03/04/2013 12:04 PM, Magnus Henoch wrote: > Steve Purcell writes: > >> Hi Magnus, >> >>> I just tried installing the Emacs Erlang mode using the package >>> definition in erlang-pkg.el, and found that the dependency declaration >>> on "flymake-mode" is incorrect - it should be "flymake" instead. I also >>> decreased the version requirement, as erlang-flymake.el works well with >>> flymake version 0.3 (the one that comes with Emacs). >> I believe this fix is insufficient for Emacs 23. In that version, there >> is no bundled `package.el`, and the one which is downloadable does not >> recognise Emacs built-in libraries as packages. ie. on Emacs 23, the >> "flymake" dependency would be unsatisfied. >> >> IMO a better solution would be to omit the dependency altogether, since >> flymake has been standard since (at least) Emacs 23. >> >> I'm a maintainer of MELPA (http://melpa.milkbox.net/), which is an Emacs >> package repository which automatically builds elisp packages from >> upstream source control repositories, so I'm happy that you've addressed >> this issue, because the Erlang package has indeed become uninstallable >> on all Emacs versions due to the "flymake-mode" dependency you fixed. >> >> Would you be able to submit a patch replacing the '(flymake-mode "0.3") >> with a nil, or should I? > Nice catch. Here is the new version of the patch (on top of the maint > branch): > > git fetch git://github.com/legoscia/otp.git fix-emacs-pkg-flymake-dep > > https://github.com/legoscia/otp/compare/legoscia:fix-emacs-pkg-flymake-dep > https://github.com/legoscia/otp/compare/legoscia:fix-emacs-pkg-flymake-dep.patch > > Regards, > Magnus > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Thanks, Re-fetched and currently in the 'pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team From lukas@REDACTED Tue Mar 5 18:41:12 2013 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 5 Mar 2013 18:41:12 +0100 Subject: [erlang-patches] new veriosn elliptic curve support In-Reply-To: <512F189F.5010704@erlang.org> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <512B989A.7090306@erlang.org> <1821337653.210106.1361811964008.JavaMail.root@tpip.net> <512BA1E5.1020702@erlang.org> <147553970.218032.1361868826091.JavaMail.root@tpip.net> <512C8318.3090102@erix.ericsson.se> <892672285.231026.1361883772253.JavaMail.root@tpip.net> <512CC728.4020803@ericsson.com> <1398393108.279224.1361990005766.JavaMail.root@tpip.net> <512F189F.5010704@erlang.org> Message-ID: <51362E38.2060808@erlang.org> Hello! I just noticed that this patch seems to break the OS X Leopard build. ./otp_build autoconf ./otp_build configure --enable-smp-support --enable-darwin-universal make ... Lots of text ... gcc -c -o ../priv/obj/i386-apple-darwin9.8.0/crypto.o -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -m32 -arch i386 -arch ppc -g -O2 -I/$ERL_TOP/erts/i386-apple-darwin9.8.0 -D_XO PEN_SOURCE -fPIC -fno-common -DHAVE_DYNAMIC_CRYPTO_LIB -I/usr/include -I/$ERL_TOP/erts/emulator/beam -I/$ERL_TOP/erts/include -I/$ERL_TOP/erts/include/i386-apple-darwin9.8.0 -I/$ERL_TOP/erts/include/internal -I/$ERL_TOP/erts/include/internal/i386-apple-darwin9.8.0 -I/$ERL_TOP/erts/emulator/sys/unix crypto.c crypto.c:58:26: error: openssl/ecdh.h: No such file or directory crypto.c:59:27: error: openssl/ecdsa.h: No such file or directory crypto.c:369: error: 'NID_secp112r1' undeclared here (not in a function) crypto.c:370: error: 'NID_secp112r2' undeclared here (not in a function) crypto.c:371: error: 'NID_secp128r1' undeclared here (not in a function) crypto.c:372: error: 'NID_secp128r2' undeclared here (not in a function) crypto.c:373: error: 'NID_secp160k1' undeclared here (not in a function) crypto.c:374: error: 'NID_secp160r1' undeclared here (not in a function) crypto.c:375: error: 'NID_secp160r2' undeclared here (not in a function) crypto.c:378: error: 'NID_secp192k1' undeclared here (not in a function) crypto.c:379: error: 'NID_secp224k1' undeclared here (not in a function) It would seem like OPENSSL_NO_EC is not defined on OS X Leopard, even if the feature is not supported. The feature is supported on Snow Leopard and Lion. I don't really know how this is meant to work, but maybe a configure test for osx leopard could work? As a side note, strangely openssl/ec.h exists, but not ecdh and ecdsa.... maybe that's why it is not defined? Let me know if you need any more info. Lukas On 28/02/13 09:43, Fredrik wrote: > On 02/27/2013 07:33 PM, Andreas Schultz wrote: >> Hi, >> >> I have fixed the ssl_to_openssl_SUITE failure. The test suite tried to >> use an EC cipher on an openssl version that has no support for that >> cipher. >> >> I have also tried to reproduced the failing crypto ec test on Ubuntu >> natty 32bit and 64bit with halfword and m32-build, but it does pass >> the test on all those variants. >> >> Is there anything special or non-standard in your test setup >> (e.g. configuration switches, manually installed libraries, ...)??? >> >> New version with fixed ssl_to_openssl_SUITE here: >> >> git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC >> >> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC >> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch >> >> >> Andreas >> >> ----- Original Message ----- >>> Hi! >>> >>> Andreas Schultz wrote: >>>> ----- Original Message ----- >>>>> Hi! >>>>> >>>>> I took a look at the failing test cases and found that whit openssl >>>>> 0.9.8k, openssl >>>>> >>>>> will crash with errors like the following: >>>>> >>>>> openssl 25966:error:14092073:SSL >>>>> routines:SSL3_GET_SERVER_HELLO:bad packet >>>>> length:s3_clnt.c:879: >>>>> CONNECTED(00000003) >>>>> >>>>> >>>>> **** User 2013-02-25 11:01:47.291 **** >>>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client failed on >>>>> line >>>>> 249 Reason: {test_case_failed,{{expected,{<0.11346.0>,ok}}, >>>>> {got,{'EXIT',#Port<0.11738>,normal}}}} >>>>> >>>>> >>>>> That is why the the test case gets {EXIT',#Port<0.11738>,normal} >>>>> >>>>> for the test cases erlang_server_openssl_client, >>>>> erlang_server_openssl_client_client_cert, >>>>> erlang_server_openssl_client_dsa_cert, >>>>> erlang_server_openssl_client_reuse_session >>>>> >>>>> >>>>> and with openssl openssl 0.9.8k and 0.9.8.o there is a hanshake >>>>> failure >>>>> in the ciphers_rsa_signed_certs test case >>>>> >>>>> >>>> Got that too. Will investigate. >>>> >>>> Yet this still doesn't explain why the i386 build is showing >>>> a failure in the crypto EC tests (this also cause a lot of >>>> the ssl failures later on). >>> Yes it could be good to investigate that first. >>> Looking at the crypto testruns it fails on openssl 0.9.8k. >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> [...] >>> > Hello, > Re-fetched. Let's see how the testing go now! > There should be no special configurations as far as I know.. > From aschultz@REDACTED Tue Mar 5 19:12:48 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Tue, 5 Mar 2013 19:12:48 +0100 (CET) Subject: [erlang-patches] new veriosn elliptic curve support In-Reply-To: <51362E38.2060808@erlang.org> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <147553970.218032.1361868826091.JavaMail.root@tpip.net> <512C8318.3090102@erix.ericsson.se> <892672285.231026.1361883772253.JavaMail.root@tpip.net> <512CC728.4020803@ericsson.com> <1398393108.279224.1361990005766.JavaMail.root@tpip.net> <512F189F.5010704@erlang.org> <51362E38.2060808@erlang.org> Message-ID: <596364204.397408.1362507168069.JavaMail.root@tpip.net> Hi, ----- Original Message ----- > Hello! > > I just noticed that this patch seems to break the OS X Leopard build. > > ./otp_build autoconf > ./otp_build configure --enable-smp-support --enable-darwin-universal > make > ... > Lots of text > ... [...] > It would seem like OPENSSL_NO_EC is not defined on OS X Leopard, even if > the feature is not supported. The feature is supported on Snow Leopard > and Lion. > > I don't really know how this is meant to work, but maybe a configure > test for osx leopard could work? A test for the openssl version possibly combined with a platform check might be sufficient. I checked openssl 0.9.7 and they did support EC and the OPENSSL_NO_EC define. Could you find out what openssl version leopard has? > As a side note, strangely openssl/ec.h exists, but not ecdh and > ecdsa.... maybe that's why it is not defined? Let me know if you need > any more info. I'll extend the check for NO_ECDH and NO_ECDSA, that should take care of such a situation. Andreas > Lukas > > On 28/02/13 09:43, Fredrik wrote: > > On 02/27/2013 07:33 PM, Andreas Schultz wrote: > >> Hi, > >> > >> I have fixed the ssl_to_openssl_SUITE failure. The test suite tried to > >> use an EC cipher on an openssl version that has no support for that > >> cipher. > >> > >> I have also tried to reproduced the failing crypto ec test on Ubuntu > >> natty 32bit and 64bit with halfword and m32-build, but it does pass > >> the test on all those variants. > >> > >> Is there anything special or non-standard in your test setup > >> (e.g. configuration switches, manually installed libraries, ...)??? > >> > >> New version with fixed ssl_to_openssl_SUITE here: > >> > >> git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC > >> > >> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > >> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > >> > >> > >> Andreas > >> > >> ----- Original Message ----- > >>> Hi! > >>> > >>> Andreas Schultz wrote: > >>>> ----- Original Message ----- > >>>>> Hi! > >>>>> > >>>>> I took a look at the failing test cases and found that whit openssl > >>>>> 0.9.8k, openssl > >>>>> > >>>>> will crash with errors like the following: > >>>>> > >>>>> openssl 25966:error:14092073:SSL > >>>>> routines:SSL3_GET_SERVER_HELLO:bad packet > >>>>> length:s3_clnt.c:879: > >>>>> CONNECTED(00000003) > >>>>> > >>>>> > >>>>> **** User 2013-02-25 11:01:47.291 **** > >>>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client failed on > >>>>> line > >>>>> 249 Reason: {test_case_failed,{{expected,{<0.11346.0>,ok}}, > >>>>> {got,{'EXIT',#Port<0.11738>,normal}}}} > >>>>> > >>>>> > >>>>> That is why the the test case gets {EXIT',#Port<0.11738>,normal} > >>>>> > >>>>> for the test cases erlang_server_openssl_client, > >>>>> erlang_server_openssl_client_client_cert, > >>>>> erlang_server_openssl_client_dsa_cert, > >>>>> erlang_server_openssl_client_reuse_session > >>>>> > >>>>> > >>>>> and with openssl openssl 0.9.8k and 0.9.8.o there is a hanshake > >>>>> failure > >>>>> in the ciphers_rsa_signed_certs test case > >>>>> > >>>>> > >>>> Got that too. Will investigate. > >>>> > >>>> Yet this still doesn't explain why the i386 build is showing > >>>> a failure in the crypto EC tests (this also cause a lot of > >>>> the ssl failures later on). > >>> Yes it could be good to investigate that first. > >>> Looking at the crypto testruns it fails on openssl 0.9.8k. > >>> > >>> Regards Ingela Erlang/OTP team - Ericsson AB > >>> > >>> [...] > >>> > > Hello, > > Re-fetched. Let's see how the testing go now! > > There should be no special configurations as far as I know.. > > > > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------ managed broadband access ------------------ Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: HRB21276 Handelsregistergericht Chemnitz Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From lukas@REDACTED Tue Mar 5 19:25:23 2013 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 5 Mar 2013 19:25:23 +0100 Subject: [erlang-patches] new veriosn elliptic curve support In-Reply-To: <596364204.397408.1362507168069.JavaMail.root@tpip.net> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <147553970.218032.1361868826091.JavaMail.root@tpip.net> <512C8318.3090102@erix.ericsson.se> <892672285.231026.1361883772253.JavaMail.root@tpip.net> <512CC728.4020803@ericsson.com> <1398393108.279224.1361990005766.JavaMail.root@tpip.net> <512F189F.5010704@erlang.org> <51362E38.2060808@erlang.org> <596364204.397408.1362507168069.JavaMail.root@tpip.net> Message-ID: <51363893.5030003@erlang.org> hmm, now that you mention it, it's 0.9.7l which is unsupported by us. I'll get back to you if we need to work around this, or if we can just leave it. Lukas On 05/03/13 19:12, Andreas Schultz wrote: > Hi, > > ----- Original Message ----- >> Hello! >> >> I just noticed that this patch seems to break the OS X Leopard build. >> >> ./otp_build autoconf >> ./otp_build configure --enable-smp-support --enable-darwin-universal >> make >> ... >> Lots of text >> ... > [...] > >> It would seem like OPENSSL_NO_EC is not defined on OS X Leopard, even if >> the feature is not supported. The feature is supported on Snow Leopard >> and Lion. >> >> I don't really know how this is meant to work, but maybe a configure >> test for osx leopard could work? > A test for the openssl version possibly combined with a platform check > might be sufficient. I checked openssl 0.9.7 and they did support EC > and the OPENSSL_NO_EC define. Could you find out what openssl version > leopard has? > >> As a side note, strangely openssl/ec.h exists, but not ecdh and >> ecdsa.... maybe that's why it is not defined? Let me know if you need >> any more info. > I'll extend the check for NO_ECDH and NO_ECDSA, that should take care of > such a situation. > > Andreas > >> Lukas >> >> On 28/02/13 09:43, Fredrik wrote: >>> On 02/27/2013 07:33 PM, Andreas Schultz wrote: >>>> Hi, >>>> >>>> I have fixed the ssl_to_openssl_SUITE failure. The test suite tried to >>>> use an EC cipher on an openssl version that has no support for that >>>> cipher. >>>> >>>> I have also tried to reproduced the failing crypto ec test on Ubuntu >>>> natty 32bit and 64bit with halfword and m32-build, but it does pass >>>> the test on all those variants. >>>> >>>> Is there anything special or non-standard in your test setup >>>> (e.g. configuration switches, manually installed libraries, ...)??? >>>> >>>> New version with fixed ssl_to_openssl_SUITE here: >>>> >>>> git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC >>>> >>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC >>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch >>>> >>>> >>>> Andreas >>>> >>>> ----- Original Message ----- >>>>> Hi! >>>>> >>>>> Andreas Schultz wrote: >>>>>> ----- Original Message ----- >>>>>>> Hi! >>>>>>> >>>>>>> I took a look at the failing test cases and found that whit openssl >>>>>>> 0.9.8k, openssl >>>>>>> >>>>>>> will crash with errors like the following: >>>>>>> >>>>>>> openssl 25966:error:14092073:SSL >>>>>>> routines:SSL3_GET_SERVER_HELLO:bad packet >>>>>>> length:s3_clnt.c:879: >>>>>>> CONNECTED(00000003) >>>>>>> >>>>>>> >>>>>>> **** User 2013-02-25 11:01:47.291 **** >>>>>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client failed on >>>>>>> line >>>>>>> 249 Reason: {test_case_failed,{{expected,{<0.11346.0>,ok}}, >>>>>>> {got,{'EXIT',#Port<0.11738>,normal}}}} >>>>>>> >>>>>>> >>>>>>> That is why the the test case gets {EXIT',#Port<0.11738>,normal} >>>>>>> >>>>>>> for the test cases erlang_server_openssl_client, >>>>>>> erlang_server_openssl_client_client_cert, >>>>>>> erlang_server_openssl_client_dsa_cert, >>>>>>> erlang_server_openssl_client_reuse_session >>>>>>> >>>>>>> >>>>>>> and with openssl openssl 0.9.8k and 0.9.8.o there is a hanshake >>>>>>> failure >>>>>>> in the ciphers_rsa_signed_certs test case >>>>>>> >>>>>>> >>>>>> Got that too. Will investigate. >>>>>> >>>>>> Yet this still doesn't explain why the i386 build is showing >>>>>> a failure in the crypto EC tests (this also cause a lot of >>>>>> the ssl failures later on). >>>>> Yes it could be good to investigate that first. >>>>> Looking at the crypto testruns it fails on openssl 0.9.8k. >>>>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>> >>>>> [...] >>>>> >>> Hello, >>> Re-fetched. Let's see how the testing go now! >>> There should be no special configurations as far as I know.. >>> >> From magnus@REDACTED Wed Mar 6 01:41:16 2013 From: magnus@REDACTED (Magnus Henoch) Date: Wed, 06 Mar 2013 00:41:16 +0000 Subject: [erlang-patches] Include function name in "overlapping domain" Dialyzer warning Message-ID: This patch changes the Dialyzer warning from: "Overloaded contract has overlapping domains" to: "Overloaded contract for foo:bar/1 has overlapping domains" I recently debugged contracts generated by a parse transform, where the line number was of no help, but a function name in the warning would have been useful. git fetch git://github.com/legoscia/otp.git dialyzer-overlapping-warning https://github.com/legoscia/otp/compare/legoscia:dialyzer-overlapping-warning https://github.com/legoscia/otp/compare/legoscia:dialyzer-overlapping-warning.patch Regards, Magnus From kostis@REDACTED Wed Mar 6 01:58:04 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 06 Mar 2013 01:58:04 +0100 Subject: [erlang-patches] Include function name in "overlapping domain" Dialyzer warning In-Reply-To: References: Message-ID: <5136949C.1040305@cs.ntua.gr> On 03/06/2013 01:41 AM, Magnus Henoch wrote: > This patch changes the Dialyzer warning from: > > "Overloaded contract has overlapping domains" > > to: > > "Overloaded contract for foo:bar/1 has overlapping domains" > > I recently debugged contracts generated by a parse transform, where the > line number was of no help, but a function name in the warning would > have been useful. > > git fetch git://github.com/legoscia/otp.git dialyzer-overlapping-warning > > https://github.com/legoscia/otp/compare/legoscia:dialyzer-overlapping-warning > https://github.com/legoscia/otp/compare/legoscia:dialyzer-overlapping-warning.patch LGTM. Kostis From lukas@REDACTED Wed Mar 6 10:50:28 2013 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 6 Mar 2013 10:50:28 +0100 Subject: [erlang-patches] new veriosn elliptic curve support In-Reply-To: <51363893.5030003@erlang.org> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <147553970.218032.1361868826091.JavaMail.root@tpip.net> <512C8318.3090102@erix.ericsson.se> <892672285.231026.1361883772253.JavaMail.root@tpip.net> <512CC728.4020803@ericsson.com> <1398393108.279224.1361990005766.JavaMail.root@tpip.net> <512F189F.5010704@erlang.org> <51362E38.2060808@erlang.org> <596364204.397408.1362507168069.JavaMail.root@tpip.net> <51363893.5030003@erlang.org> Message-ID: <51371164.908@erlang.org> Hello again, Since we want Erlang/OTP to be runnable on OS X Leopard we have to make an exception to the OpenSSL supported version and make it work here. So somekind of workaround needs to be done. I'm not sure if this problem is for all 0.9.7, or if it is Apple which have decided to do things a specific way. So maybe the best way would be to check if the header files exist in configure and then ifdef based on that. Alternatively if you can determine that this is the way it works in 0.9.7, then you should just be able to ifdef on the openssl version define. Lukas On 05/03/13 19:25, Lukas Larsson wrote: > hmm, now that you mention it, it's 0.9.7l which is unsupported by us. > I'll get back to you if we need to work around this, or if we can just > leave it. > > Lukas > > On 05/03/13 19:12, Andreas Schultz wrote: >> Hi, >> >> ----- Original Message ----- >>> Hello! >>> >>> I just noticed that this patch seems to break the OS X Leopard build. >>> >>> ./otp_build autoconf >>> ./otp_build configure --enable-smp-support --enable-darwin-universal >>> make >>> ... >>> Lots of text >>> ... >> [...] >> >>> It would seem like OPENSSL_NO_EC is not defined on OS X Leopard, >>> even if >>> the feature is not supported. The feature is supported on Snow Leopard >>> and Lion. >>> >>> I don't really know how this is meant to work, but maybe a configure >>> test for osx leopard could work? >> A test for the openssl version possibly combined with a platform check >> might be sufficient. I checked openssl 0.9.7 and they did support EC >> and the OPENSSL_NO_EC define. Could you find out what openssl version >> leopard has? >> >>> As a side note, strangely openssl/ec.h exists, but not ecdh and >>> ecdsa.... maybe that's why it is not defined? Let me know if you need >>> any more info. >> I'll extend the check for NO_ECDH and NO_ECDSA, that should take care of >> such a situation. >> >> Andreas >> >>> Lukas >>> >>> On 28/02/13 09:43, Fredrik wrote: >>>> On 02/27/2013 07:33 PM, Andreas Schultz wrote: >>>>> Hi, >>>>> >>>>> I have fixed the ssl_to_openssl_SUITE failure. The test suite >>>>> tried to >>>>> use an EC cipher on an openssl version that has no support for that >>>>> cipher. >>>>> >>>>> I have also tried to reproduced the failing crypto ec test on Ubuntu >>>>> natty 32bit and 64bit with halfword and m32-build, but it does pass >>>>> the test on all those variants. >>>>> >>>>> Is there anything special or non-standard in your test setup >>>>> (e.g. configuration switches, manually installed libraries, ...)??? >>>>> >>>>> New version with fixed ssl_to_openssl_SUITE here: >>>>> >>>>> git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC >>>>> >>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC >>>>> >>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch >>>>> >>>>> >>>>> >>>>> Andreas >>>>> >>>>> ----- Original Message ----- >>>>>> Hi! >>>>>> >>>>>> Andreas Schultz wrote: >>>>>>> ----- Original Message ----- >>>>>>>> Hi! >>>>>>>> >>>>>>>> I took a look at the failing test cases and found that whit >>>>>>>> openssl >>>>>>>> 0.9.8k, openssl >>>>>>>> >>>>>>>> will crash with errors like the following: >>>>>>>> >>>>>>>> openssl 25966:error:14092073:SSL >>>>>>>> routines:SSL3_GET_SERVER_HELLO:bad packet >>>>>>>> length:s3_clnt.c:879: >>>>>>>> CONNECTED(00000003) >>>>>>>> >>>>>>>> >>>>>>>> **** User 2013-02-25 11:01:47.291 **** >>>>>>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client failed on >>>>>>>> line >>>>>>>> 249 Reason: {test_case_failed,{{expected,{<0.11346.0>,ok}}, >>>>>>>> {got,{'EXIT',#Port<0.11738>,normal}}}} >>>>>>>> >>>>>>>> >>>>>>>> That is why the the test case gets {EXIT',#Port<0.11738>,normal} >>>>>>>> >>>>>>>> for the test cases erlang_server_openssl_client, >>>>>>>> erlang_server_openssl_client_client_cert, >>>>>>>> erlang_server_openssl_client_dsa_cert, >>>>>>>> erlang_server_openssl_client_reuse_session >>>>>>>> >>>>>>>> >>>>>>>> and with openssl openssl 0.9.8k and 0.9.8.o there is a hanshake >>>>>>>> failure >>>>>>>> in the ciphers_rsa_signed_certs test case >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Got that too. Will investigate. >>>>>>> >>>>>>> Yet this still doesn't explain why the i386 build is showing >>>>>>> a failure in the crypto EC tests (this also cause a lot of >>>>>>> the ssl failures later on). >>>>>> Yes it could be good to investigate that first. >>>>>> Looking at the crypto testruns it fails on openssl 0.9.8k. >>>>>> >>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>> >>>>>> [...] >>>>>> >>>> Hello, >>>> Re-fetched. Let's see how the testing go now! >>>> There should be no special configurations as far as I know.. >>>> >>> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From fredrik@REDACTED Wed Mar 6 10:50:31 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 6 Mar 2013 10:50:31 +0100 Subject: [erlang-patches] Include function name in "overlapping domain" Dialyzer warning In-Reply-To: References: Message-ID: <51371167.2010408@erlang.org> On 03/06/2013 01:41 AM, Magnus Henoch wrote: > This patch changes the Dialyzer warning from: > > "Overloaded contract has overlapping domains" > > to: > > "Overloaded contract for foo:bar/1 has overlapping domains" > > I recently debugged contracts generated by a parse transform, where the > line number was of no help, but a function name in the warning would > have been useful. > > git fetch git://github.com/legoscia/otp.git dialyzer-overlapping-warning > > https://github.com/legoscia/otp/compare/legoscia:dialyzer-overlapping-warning > https://github.com/legoscia/otp/compare/legoscia:dialyzer-overlapping-warning.patch > > Regards, > Magnus > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Fetched, and currently in the 'pu' branch.. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From cao.xu@REDACTED Thu Mar 7 02:30:10 2013 From: cao.xu@REDACTED (cao xu) Date: Thu, 7 Mar 2013 09:30:10 +0800 Subject: [erlang-patches] Fix potential memory/process leaks caused by invalid http headers Message-ID: Hi When issue a httpc request such as httpc:request(get, {"http://www.sina.com.cn", [{"cookie",undefined}]}, [], []), the httpc_handler process who handle the request will crash and the caller will hang forever by waiting for the response. I believe it would be better to return an error here, so I've committed a patch for it. git fetch git://github.com/RYTong/otp.git inets-httpc-patches and the compare view is under: https://github.com/RYTong/otp/compare/maint...inets-httpc-patches https://github.com/RYTong/otp/compare/maint...inets-httpc-patches.patch BR Xu Cao -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Thu Mar 7 09:54:59 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 7 Mar 2013 09:54:59 +0100 Subject: [erlang-patches] Fix potential memory/process leaks caused by invalid http headers In-Reply-To: References: Message-ID: <513855E3.4090107@erlang.org> On 03/07/2013 02:30 AM, cao xu wrote: > Hi > When issue a httpc request such as > httpc:request(get, {"http://www.sina.com.cn > ", [{"cookie",undefined}]}, [], []), the > httpc_handler process who handle the request will crash and the caller > will hang forever by waiting for the response. I believe it would be > better to return an error here, so I've committed a patch for it. > > git fetch git://github.com/RYTong/otp.git inets-httpc-patches > > and the compare view is under: > > https://github.com/RYTong/otp/compare/maint...inets-httpc-patches > > https://github.com/RYTong/otp/compare/maint...inets-httpc-patches.patch > > BR > > Xu Cao > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Fetched and currently in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamt@REDACTED Fri Mar 8 02:45:19 2013 From: yamt@REDACTED (YAMAMOTO Takashi) Date: Fri, 8 Mar 2013 01:45:19 +0000 (UTC) Subject: [erlang-patches] netbsd and pkgsrc fixes Message-ID: <20130308014520.03F2314A3EA@mail.netbsd.org> build/compilation fixes. git fetch git://github.com/yamt/otp.git netbsd https://github.com/yamt/otp/compare/yamt:netbsd https://github.com/yamt/otp/compare/yamt:netbsd.patch From fredrik@REDACTED Fri Mar 8 09:59:31 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 8 Mar 2013 09:59:31 +0100 Subject: [erlang-patches] netbsd and pkgsrc fixes In-Reply-To: <20130308014520.03F2314A3EA@mail.netbsd.org> References: <20130308014520.03F2314A3EA@mail.netbsd.org> Message-ID: <5139A873.6060502@erlang.org> On 03/08/2013 02:45 AM, YAMAMOTO Takashi wrote: > git fetch git://github.com/yamt/otp.git netbsd > > https://github.com/yamt/otp/compare/yamt:netbsd > https://github.com/yamt/otp/compare/yamt:netbsd.patch Fetched and currently in the 'pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team From aschultz@REDACTED Fri Mar 8 14:06:45 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Fri, 8 Mar 2013 14:06:45 +0100 (CET) Subject: [erlang-patches] new version elliptic curve support In-Reply-To: <51371164.908@erlang.org> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <512CC728.4020803@ericsson.com> <1398393108.279224.1361990005766.JavaMail.root@tpip.net> <512F189F.5010704@erlang.org> <51362E38.2060808@erlang.org> <596364204.397408.1362507168069.JavaMail.root@tpip.net> <51363893.5030003@erlang.org> <51371164.908@erlang.org> Message-ID: <29745459.479844.1362748005228.JavaMail.root@tpip.net> Hi, I have tested with various openssl versions and the earliest to pass the crypto test is 0.9.8o. I have adjusted the ifdef's in crypto to take that and then NO_ECDH and NO_ECDSA defines into account. I've also discovered a bug where an EC cipher was chosen when the certificate was actually not compatible with it. Update version is here: git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch In case anybody is interested, I also have an very early version of AES-GCM cipher support (not for -pu inclusion yet): https://github.com/RoadRunnr/otp/compare/tls-psk-srp-suites-ECC-GCM Andreas ----- Original Message ----- > Hello again, > > Since we want Erlang/OTP to be runnable on OS X Leopard we have to make > an exception to the OpenSSL supported version and make it work here. So > somekind of workaround needs to be done. I'm not sure if this problem is > for all 0.9.7, or if it is Apple which have decided to do things a > specific way. So maybe the best way would be to check if the header > files exist in configure and then ifdef based on that. Alternatively if > you can determine that this is the way it works in 0.9.7, then you > should just be able to ifdef on the openssl version define. > > Lukas > > On 05/03/13 19:25, Lukas Larsson wrote: > > hmm, now that you mention it, it's 0.9.7l which is unsupported by us. > > I'll get back to you if we need to work around this, or if we can just > > leave it. > > > > Lukas > > > > On 05/03/13 19:12, Andreas Schultz wrote: > >> Hi, > >> > >> ----- Original Message ----- > >>> Hello! > >>> > >>> I just noticed that this patch seems to break the OS X Leopard build. > >>> > >>> ./otp_build autoconf > >>> ./otp_build configure --enable-smp-support --enable-darwin-universal > >>> make > >>> ... > >>> Lots of text > >>> ... > >> [...] > >> > >>> It would seem like OPENSSL_NO_EC is not defined on OS X Leopard, > >>> even if > >>> the feature is not supported. The feature is supported on Snow Leopard > >>> and Lion. > >>> > >>> I don't really know how this is meant to work, but maybe a configure > >>> test for osx leopard could work? > >> A test for the openssl version possibly combined with a platform check > >> might be sufficient. I checked openssl 0.9.7 and they did support EC > >> and the OPENSSL_NO_EC define. Could you find out what openssl version > >> leopard has? > >> > >>> As a side note, strangely openssl/ec.h exists, but not ecdh and > >>> ecdsa.... maybe that's why it is not defined? Let me know if you need > >>> any more info. > >> I'll extend the check for NO_ECDH and NO_ECDSA, that should take care of > >> such a situation. > >> > >> Andreas > >> > >>> Lukas > >>> > >>> On 28/02/13 09:43, Fredrik wrote: > >>>> On 02/27/2013 07:33 PM, Andreas Schultz wrote: > >>>>> Hi, > >>>>> > >>>>> I have fixed the ssl_to_openssl_SUITE failure. The test suite > >>>>> tried to > >>>>> use an EC cipher on an openssl version that has no support for that > >>>>> cipher. > >>>>> > >>>>> I have also tried to reproduced the failing crypto ec test on Ubuntu > >>>>> natty 32bit and 64bit with halfword and m32-build, but it does pass > >>>>> the test on all those variants. > >>>>> > >>>>> Is there anything special or non-standard in your test setup > >>>>> (e.g. configuration switches, manually installed libraries, ...)??? > >>>>> > >>>>> New version with fixed ssl_to_openssl_SUITE here: > >>>>> > >>>>> git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC > >>>>> > >>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > >>>>> > >>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > >>>>> > >>>>> > >>>>> > >>>>> Andreas > >>>>> > >>>>> ----- Original Message ----- > >>>>>> Hi! > >>>>>> > >>>>>> Andreas Schultz wrote: > >>>>>>> ----- Original Message ----- > >>>>>>>> Hi! > >>>>>>>> > >>>>>>>> I took a look at the failing test cases and found that whit > >>>>>>>> openssl > >>>>>>>> 0.9.8k, openssl > >>>>>>>> > >>>>>>>> will crash with errors like the following: > >>>>>>>> > >>>>>>>> openssl 25966:error:14092073:SSL > >>>>>>>> routines:SSL3_GET_SERVER_HELLO:bad packet > >>>>>>>> length:s3_clnt.c:879: > >>>>>>>> CONNECTED(00000003) > >>>>>>>> > >>>>>>>> > >>>>>>>> **** User 2013-02-25 11:01:47.291 **** > >>>>>>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client failed on > >>>>>>>> line > >>>>>>>> 249 Reason: {test_case_failed,{{expected,{<0.11346.0>,ok}}, > >>>>>>>> {got,{'EXIT',#Port<0.11738>,normal}}}} > >>>>>>>> > >>>>>>>> > >>>>>>>> That is why the the test case gets {EXIT',#Port<0.11738>,normal} > >>>>>>>> > >>>>>>>> for the test cases erlang_server_openssl_client, > >>>>>>>> erlang_server_openssl_client_client_cert, > >>>>>>>> erlang_server_openssl_client_dsa_cert, > >>>>>>>> erlang_server_openssl_client_reuse_session > >>>>>>>> > >>>>>>>> > >>>>>>>> and with openssl openssl 0.9.8k and 0.9.8.o there is a hanshake > >>>>>>>> failure > >>>>>>>> in the ciphers_rsa_signed_certs test case > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Got that too. Will investigate. > >>>>>>> > >>>>>>> Yet this still doesn't explain why the i386 build is showing > >>>>>>> a failure in the crypto EC tests (this also cause a lot of > >>>>>>> the ssl failures later on). > >>>>>> Yes it could be good to investigate that first. > >>>>>> Looking at the crypto testruns it fails on openssl 0.9.8k. > >>>>>> > >>>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >>>>>> > >>>>>> [...] > >>>>>> > >>>> Hello, > >>>> Re-fetched. Let's see how the testing go now! > >>>> There should be no special configurations as far as I know.. > >>>> > >>> > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------ managed broadband access ------------------ Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: HRB21276 Handelsregistergericht Chemnitz Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From kostis@REDACTED Fri Mar 8 15:07:28 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 08 Mar 2013 15:07:28 +0100 Subject: [erlang-patches] Process priority levels Message-ID: <5139F0A0.9030007@cs.ntua.gr> In the specs and the documentation of the spawn_opt family of functions there is the following definition of priority levels: Level = low | normal | high However, the process_flag/1 function in that module reads: process_flag(Flag :: priority, Level) -> OldLevel Types: Level = OldLevel = priority_level() priority_level() = low | normal | high | max This is clearly inconsistent. Change specs to use the priority_level() type declaration instead of re-defining it in various places. ========================================================================= Please include: git fetch git://github.com/kostis/otp.git erlang-spawn_opt-process_level Kostis PS. When included, the erlang.beam file in erts/preloaded/ebin should also be re-generated somehow. It's not so clear to me how one does that. From magnus@REDACTED Fri Mar 8 18:24:49 2013 From: magnus@REDACTED (Magnus Henoch) Date: Fri, 08 Mar 2013 17:24:49 +0000 Subject: [erlang-patches] Delete obsolete note about simple-one-for-one supervisor Message-ID: I'm often confused about the behaviour of simple-one-for-one supervisors at shutdown, and just realised that this is because the documentation contradicts itself. Here is a patch that removes one of the conflicting paragraphs. The paragraph I kept says: Because a simple_one_for_one supervisor could have many children, it shuts them all down at same time. So, order in which they are stopped is not defined. For the same reason, it could have an overhead with regards to the Shutdown strategy. And the one I deleted says: Important note on simple-one-for-one supervisors: The dynamically created child processes of a simple-one-for-one supervisor are not explicitly killed, regardless of shutdown strategy, but are expected to terminate when the supervisor does (that is, when an exit signal from the parent process is received). I believe the latter was kept because of an incorrect merge. git fetch git://github.com/legoscia/otp.git supervisor-doc https://github.com/legoscia/otp/compare/legoscia:supervisor-doc https://github.com/legoscia/otp/compare/legoscia:supervisor-doc.patch Regards, Magnus From kostis@REDACTED Sun Mar 10 19:29:06 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 10 Mar 2013 19:29:06 +0100 Subject: [erlang-patches] Fix native code compiler crash involving bs_match_string Message-ID: <513CD0F2.4040102@cs.ntua.gr> Prior to R16B, the bs_match_string instruction worked only for cases that had a destination variable. As shown by the example below, this is not always the case and the Dst list can be empty. test(<<42, _/bits>> = B) -> B. This fixes a bug reported by Lo?c Hoguin (02/12/2013); the original post used a different code example to illustrate the problem. While revising the code, a clean up of some HiPE files was also performed. ==================================================================== Please include: git fetch git://github.com/kostis/otp.git hipe-cleanup Kostis From fredrik@REDACTED Mon Mar 11 14:55:12 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 11 Mar 2013 14:55:12 +0100 Subject: [erlang-patches] Delete obsolete note about simple-one-for-one supervisor In-Reply-To: References: Message-ID: <513DE240.4010909@erlang.org> On 03/08/2013 06:24 PM, Magnus Henoch wrote: > git fetch git://github.com/legoscia/otp.git supervisor-doc Thanks, Currently building in the 'pu' branch! -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Mar 11 14:57:07 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 11 Mar 2013 14:57:07 +0100 Subject: [erlang-patches] Fix native code compiler crash involving bs_match_string In-Reply-To: <513CD0F2.4040102@cs.ntua.gr> References: <513CD0F2.4040102@cs.ntua.gr> Message-ID: <513DE2B3.1020706@erlang.org> On 03/10/2013 07:29 PM, Kostis Sagonas wrote: > git fetch git://github.com/kostis/otp.git hipe-cleanup Thanks, Fetched and currently building in the 'pu' branch -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Mar 11 15:17:11 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 11 Mar 2013 15:17:11 +0100 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: References: <4FCE3186.3000202@erlang.org> <5034FB10.7090804@erlang.org> <503CC79B.2020009@erlang.org> <50471240.3060005@erlang.org> <504DF309.2040900@erlang.org> <415229C2-452E-45FF-A207-69BD2212E2F5@gmail.com> <50519F42.7000109@erlang.org> <50598C38.8060506@erlang.org> <77306113-0789-4B6F-A45D-8304FFED5C39@gmail.com> Message-ID: <513DE767.90700@erlang.org> On 12/02/2012 11:07 AM, Anthony Ramine wrote: > Hi, > > I've made column numbers a non-optional thing in compile but still an > option in epp; so that tools like edoc which don't need the full > locations can get only the line numbers. > > Please refetch. > > -- > Anthony Ramine > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello, Could you please rebase this patch upon the current 'maint' branch? Thanks. -- BR Fredrik Gustafsson Erlang OTP Team From lukas@REDACTED Mon Mar 11 17:36:13 2013 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 11 Mar 2013 17:36:13 +0100 Subject: [erlang-patches] netbsd and pkgsrc fixes In-Reply-To: <20130308014520.03F2314A3EA@mail.netbsd.org> References: <20130308014520.03F2314A3EA@mail.netbsd.org> Message-ID: <513E07FD.8080908@erlang.org> Hello, Could you please move the #ifdef check for the sys/vmmeter.h to in the same place as FreeBSD and Dragonfly? With that change this patch is ready for inclusion. Lukas On 08/03/13 02:45, YAMAMOTO Takashi wrote: > build/compilation fixes. > > git fetch git://github.com/yamt/otp.git netbsd > > https://github.com/yamt/otp/compare/yamt:netbsd > https://github.com/yamt/otp/compare/yamt:netbsd.patch > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From fredrik@REDACTED Tue Mar 12 15:09:49 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 12 Mar 2013 15:09:49 +0100 Subject: [erlang-patches] Implement add_report_sup_handler which calls gen_event:add_sup_handler In-Reply-To: References: Message-ID: <513F372D.9090106@erlang.org> On 03/01/2013 08:15 PM, Pedram Nimreezi wrote: > Hi, > > This patch adds add_report_sup_handler to the error_logger module > > To eliminate the need to go around the error_logger api, this patch > allows for a report_handler to be added via add_sup_handler. > > https://github.com/DeadZen/otp/compare/error-logger-sup_handler.patch > https://github.com/DeadZen/otp/compare/error-logger-sup_handler > > git fetch git://github.com/DeadZen/otp.git error-logger-sup_handler > Hello again, I've got some feedback on your patch. *The patch needs tests and documentation *The spec for add_report_sup_handler/1 is not sufficient, should it be "any()" really? *Your commit message is to short and needs further explanation. -- BR Fredrik Gustafsson Erlang OTP Team From mc@REDACTED Tue Mar 12 16:03:37 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Tue, 12 Mar 2013 11:03:37 -0400 Subject: [erlang-patches] Implement add_report_sup_handler which calls gen_event:add_sup_handler In-Reply-To: <513F372D.9090106@erlang.org> References: <513F372D.9090106@erlang.org> Message-ID: Thank you for the update, I'll make the proper changes. On Tue, Mar 12, 2013 at 10:09 AM, Fredrik wrote: > On 03/01/2013 08:15 PM, Pedram Nimreezi wrote: >> >> Hi, >> >> This patch adds add_report_sup_handler to the error_logger module >> >> To eliminate the need to go around the error_logger api, this patch >> allows for a report_handler to be added via add_sup_handler. >> >> https://github.com/DeadZen/otp/compare/error-logger-sup_handler.patch >> https://github.com/DeadZen/otp/compare/error-logger-sup_handler >> >> git fetch git://github.com/DeadZen/otp.git error-logger-sup_handler >> > Hello again, > I've got some feedback on your patch. > *The patch needs tests and documentation > *The spec for add_report_sup_handler/1 is not sufficient, should it be > "any()" really? > *Your commit message is to short and needs further explanation. > > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman From fredrik@REDACTED Tue Mar 12 17:21:10 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 12 Mar 2013 17:21:10 +0100 Subject: [erlang-patches] new version elliptic curve support In-Reply-To: <29745459.479844.1362748005228.JavaMail.root@tpip.net> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <512CC728.4020803@ericsson.com> <1398393108.279224.1361990005766.JavaMail.root@tpip.net> <512F189F.5010704@erlang.org> <51362E38.2060808@erlang.org> <596364204.397408.1362507168069.JavaMail.root@tpip.net> <51363893.5030003@erlang.org> <51371164.908@erlang.org> <29745459.479844.1362748005228.JavaMail.root@tpip.net> Message-ID: <513F55F6.8060805@erlang.org> On 03/08/2013 02:06 PM, Andreas Schultz wrote: > Hi, > > I have tested with various openssl versions and the earliest to > pass the crypto test is 0.9.8o. I have adjusted the ifdef's > in crypto to take that and then NO_ECDH and NO_ECDSA defines > into account. I've also discovered a bug where an EC cipher was > chosen when the certificate was actually not compatible with > it. > > Update version is here: > > git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC > > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > > > In case anybody is interested, I also have an very early version of > AES-GCM cipher support (not for -pu inclusion yet): > > https://github.com/RoadRunnr/otp/compare/tls-psk-srp-suites-ECC-GCM > > Andreas > > ----- Original Message ----- >> Hello again, >> >> Since we want Erlang/OTP to be runnable on OS X Leopard we have to make >> an exception to the OpenSSL supported version and make it work here. So >> somekind of workaround needs to be done. I'm not sure if this problem is >> for all 0.9.7, or if it is Apple which have decided to do things a >> specific way. So maybe the best way would be to check if the header >> files exist in configure and then ifdef based on that. Alternatively if >> you can determine that this is the way it works in 0.9.7, then you >> should just be able to ifdef on the openssl version define. >> >> Lukas >> >> On 05/03/13 19:25, Lukas Larsson wrote: >>> hmm, now that you mention it, it's 0.9.7l which is unsupported by us. >>> I'll get back to you if we need to work around this, or if we can just >>> leave it. >>> >>> Lukas >>> >>> On 05/03/13 19:12, Andreas Schultz wrote: >>>> Hi, >>>> >>>> ----- Original Message ----- >>>>> Hello! >>>>> >>>>> I just noticed that this patch seems to break the OS X Leopard build. >>>>> >>>>> ./otp_build autoconf >>>>> ./otp_build configure --enable-smp-support --enable-darwin-universal >>>>> make >>>>> ... >>>>> Lots of text >>>>> ... >>>> [...] >>>> >>>>> It would seem like OPENSSL_NO_EC is not defined on OS X Leopard, >>>>> even if >>>>> the feature is not supported. The feature is supported on Snow Leopard >>>>> and Lion. >>>>> >>>>> I don't really know how this is meant to work, but maybe a configure >>>>> test for osx leopard could work? >>>> A test for the openssl version possibly combined with a platform check >>>> might be sufficient. I checked openssl 0.9.7 and they did support EC >>>> and the OPENSSL_NO_EC define. Could you find out what openssl version >>>> leopard has? >>>> >>>>> As a side note, strangely openssl/ec.h exists, but not ecdh and >>>>> ecdsa.... maybe that's why it is not defined? Let me know if you need >>>>> any more info. >>>> I'll extend the check for NO_ECDH and NO_ECDSA, that should take care of >>>> such a situation. >>>> >>>> Andreas >>>> >>>>> Lukas >>>>> >>>>> On 28/02/13 09:43, Fredrik wrote: >>>>>> On 02/27/2013 07:33 PM, Andreas Schultz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have fixed the ssl_to_openssl_SUITE failure. The test suite >>>>>>> tried to >>>>>>> use an EC cipher on an openssl version that has no support for that >>>>>>> cipher. >>>>>>> >>>>>>> I have also tried to reproduced the failing crypto ec test on Ubuntu >>>>>>> natty 32bit and 64bit with halfword and m32-build, but it does pass >>>>>>> the test on all those variants. >>>>>>> >>>>>>> Is there anything special or non-standard in your test setup >>>>>>> (e.g. configuration switches, manually installed libraries, ...)??? >>>>>>> >>>>>>> New version with fixed ssl_to_openssl_SUITE here: >>>>>>> >>>>>>> git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC >>>>>>> >>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC >>>>>>> >>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> Hi! >>>>>>>> >>>>>>>> Andreas Schultz wrote: >>>>>>>>> ----- Original Message ----- >>>>>>>>>> Hi! >>>>>>>>>> >>>>>>>>>> I took a look at the failing test cases and found that whit >>>>>>>>>> openssl >>>>>>>>>> 0.9.8k, openssl >>>>>>>>>> >>>>>>>>>> will crash with errors like the following: >>>>>>>>>> >>>>>>>>>> openssl 25966:error:14092073:SSL >>>>>>>>>> routines:SSL3_GET_SERVER_HELLO:bad packet >>>>>>>>>> length:s3_clnt.c:879: >>>>>>>>>> CONNECTED(00000003) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> **** User 2013-02-25 11:01:47.291 **** >>>>>>>>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client failed on >>>>>>>>>> line >>>>>>>>>> 249 Reason: {test_case_failed,{{expected,{<0.11346.0>,ok}}, >>>>>>>>>> {got,{'EXIT',#Port<0.11738>,normal}}}} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That is why the the test case gets {EXIT',#Port<0.11738>,normal} >>>>>>>>>> >>>>>>>>>> for the test cases erlang_server_openssl_client, >>>>>>>>>> erlang_server_openssl_client_client_cert, >>>>>>>>>> erlang_server_openssl_client_dsa_cert, >>>>>>>>>> erlang_server_openssl_client_reuse_session >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and with openssl openssl 0.9.8k and 0.9.8.o there is a hanshake >>>>>>>>>> failure >>>>>>>>>> in the ciphers_rsa_signed_certs test case >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Got that too. Will investigate. >>>>>>>>> >>>>>>>>> Yet this still doesn't explain why the i386 build is showing >>>>>>>>> a failure in the crypto EC tests (this also cause a lot of >>>>>>>>> the ssl failures later on). >>>>>>>> Yes it could be good to investigate that first. >>>>>>>> Looking at the crypto testruns it fails on openssl 0.9.8k. >>>>>>>> >>>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>> Hello, >>>>>> Re-fetched. Let's see how the testing go now! >>>>>> There should be no special configurations as far as I know.. >>>>>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >> Hello again, This seems suspicious that these two openssl versions 0.9.8a 0.9.7l is failing some testcases that other versions are not. We are thinking that it could be a bug in openssl but we are not sure. Could you match your tests upon your branch on these openssl versions and see if you can reproduce them. The failing testcases are: ciphers_rsa_signed_certs erlang_server_openssl_client erlang_server_openssl_client_client_cert erlang_server_openssl_client_dsa_cert erlang_server_openssl_client_reuse_session in the ssl_to_openssl_SUITE suite. -- BR Fredrik Gustafsson Erlang OTP Team From kostis@REDACTED Tue Mar 12 20:07:46 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 12 Mar 2013 20:07:46 +0100 Subject: [erlang-patches] [erlang-bugs] Native compilation hangs with rm-reverse-eta-conversion In-Reply-To: References: <50FBAB1E.2070703@cs.ntua.gr> Message-ID: <513F7D02.9040907@cs.ntua.gr> On 01/23/2013 12:49 PM, Anthony Ramine wrote: > Hi, > > The bytecode invariant that I broke is the fact that a function cannot be used as > a closure and as a normal function both at the same time, thus the eta-abstraction > is needed by HiPE. > > Fredrik, for the time being you should probably revert rm-reverse-eta-conversion > because I don't think I'll be able to make HiPE work with the eta-abstraction in > that much time. > > Kostis, could you give me directions on how to make HiPE not need the intermediate > closures when doing fun Name/Arity? Thanks to Anthony repeatedly prompting me to look into this and sending me a minimal example to test and to Bjorn Gustavsson for checking the code of hipe_icode_coordinator, today I adapted the assumptions of the native code compiler and simplified the code that computes escaping functions. The following hipe patch should be included in OTP: git fetch git://github.com/kostis/otp.git hipe-cleanup-escaping After its inclusion, Anthony's patch that removes the automatic eta-abstraction for function references from the BEAM compiler can probably be included without any problems. Kostis From hammingweight@REDACTED Wed Mar 13 10:13:11 2013 From: hammingweight@REDACTED (Carl Meijer) Date: Wed, 13 Mar 2013 11:13:11 +0200 Subject: [erlang-patches] HTTP PUT/POST fail when content-length is zero In-Reply-To: <51346676.8080306@erlang.org> References: <51346676.8080306@erlang.org> Message-ID: On Mon, Mar 4, 2013 at 11:16 AM, Fredrik wrote: > On 03/02/2013 06:17 AM, Carl Meijer wrote: >> >> Hi, >> >> The content-length header is removed from PUTs/POSTs when the length >> is zero. Servers are rejecting PUTs/POSTs without the content length >> with a 411 response code >> >> RFC2616 states that a content length of zero is valid. >> >> I have added a test for this bug. I am not sure that I have added it >> to the correct suite (http_format_SUITE) but it does demonstrate the >> problem and that the proposed fix solves this problem (no tests in the >> inets suite break as a result of the change). >> >> git fetch git://github.com/hammingweight/otp.git >> bug-http-content-length-zero >> >> https://github.com/hammingweight/otp/compare/bug-http-content-length-zero >> >> >> https://github.com/hammingweight/otp/compare/bug-http-content-length-zero.patch >> >> Regards, >> Carl >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > Hello Carl, > I've fetched your patch and it is currently cooking in the 'pu' branch. > May be a duplicate patch on this matter but I'll look into it. Hi, I was wondering whether there was a duplicate patch for this issue? I see there is some other issue with content-length = 0 but that seems to be in the headers of HTTP responses (not in the headers of HTTP requests). BR, Carl From fredrik@REDACTED Wed Mar 13 10:15:06 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 13 Mar 2013 10:15:06 +0100 Subject: [erlang-patches] [erlang-bugs] Native compilation hangs with rm-reverse-eta-conversion In-Reply-To: <513F7D02.9040907@cs.ntua.gr> References: <50FBAB1E.2070703@cs.ntua.gr> <513F7D02.9040907@cs.ntua.gr> Message-ID: <5140439A.2030205@erlang.org> On 03/12/2013 08:07 PM, Kostis Sagonas wrote: > On 01/23/2013 12:49 PM, Anthony Ramine wrote: >> Hi, >> >> The bytecode invariant that I broke is the fact that a function >> cannot be used as >> a closure and as a normal function both at the same time, thus the >> eta-abstraction >> is needed by HiPE. >> >> Fredrik, for the time being you should probably revert >> rm-reverse-eta-conversion >> because I don't think I'll be able to make HiPE work with the >> eta-abstraction in >> that much time. >> >> Kostis, could you give me directions on how to make HiPE not need the >> intermediate >> closures when doing fun Name/Arity? > > Thanks to Anthony repeatedly prompting me to look into this and > sending me a minimal example to test and to Bjorn Gustavsson for > checking the code of hipe_icode_coordinator, today I adapted the > assumptions of the native code compiler and simplified the code that > computes escaping functions. The following hipe patch should be > included in OTP: > > > git fetch git://github.com/kostis/otp.git hipe-cleanup-escaping > > > After its inclusion, Anthony's patch that removes the automatic > eta-abstraction for function references from the BEAM compiler can > probably be included without any problems. > > Kostis > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Fetched. It is now in the 'pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Wed Mar 13 10:16:29 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 13 Mar 2013 10:16:29 +0100 Subject: [erlang-patches] HTTP PUT/POST fail when content-length is zero In-Reply-To: References: <51346676.8080306@erlang.org> Message-ID: <514043ED.4060309@erlang.org> On 03/13/2013 10:13 AM, Carl Meijer wrote: > On Mon, Mar 4, 2013 at 11:16 AM, Fredrik wrote: >> On 03/02/2013 06:17 AM, Carl Meijer wrote: >>> Hi, >>> >>> The content-length header is removed from PUTs/POSTs when the length >>> is zero. Servers are rejecting PUTs/POSTs without the content length >>> with a 411 response code >>> >>> RFC2616 states that a content length of zero is valid. >>> >>> I have added a test for this bug. I am not sure that I have added it >>> to the correct suite (http_format_SUITE) but it does demonstrate the >>> problem and that the proposed fix solves this problem (no tests in the >>> inets suite break as a result of the change). >>> >>> git fetch git://github.com/hammingweight/otp.git >>> bug-http-content-length-zero >>> >>> https://github.com/hammingweight/otp/compare/bug-http-content-length-zero >>> >>> >>> https://github.com/hammingweight/otp/compare/bug-http-content-length-zero.patch >>> >>> Regards, >>> Carl >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> Hello Carl, >> I've fetched your patch and it is currently cooking in the 'pu' branch. >> May be a duplicate patch on this matter but I'll look into it. > Hi, > > I was wondering whether there was a duplicate patch for this issue? > > I see there is some other issue with content-length = 0 but that seems > to be in the headers of HTTP responses (not in the headers of HTTP > requests). > > BR, > Carl Hello, Your patch has been reviewed and is going through further testing and hopefully it will be a part of R16B01. It was not a duplicate. -- BR Fredrik Gustafsson Erlang OTP Team From aschultz@REDACTED Wed Mar 13 19:32:01 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 13 Mar 2013 19:32:01 +0100 (CET) Subject: [erlang-patches] new version elliptic curve support In-Reply-To: <514056A9.4090605@erix.ericsson.se> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <51362E38.2060808@erlang.org> <596364204.397408.1362507168069.JavaMail.root@tpip.net> <51363893.5030003@erlang.org> <51371164.908@erlang.org> <29745459.479844.1362748005228.JavaMail.root@tpip.net> <513F55F6.8060805@erlang.org> <514056A9.4090605@erix.ericsson.se> Message-ID: <480623580.577114.1363199521282.JavaMail.root@tpip.net> Hi, Found the cause, the EC patch adds server hello handshake extensions, but sends them unconditionally when it should only send them if the client requested them. I'll change that, but it'll take a few days as I'm very busy.... Andreas ----- Original Message ----- > Hi! > > Just a small clarification. Test cases erlang_server_openssl_client, > erlang_server_openssl_client_client_cert , > erlang_server_openssl_client_dsa_cert, > erlang_server_open and ssl_client_reuse_session fail for some TLS > versions on some versions of openssl. > > Test case log looks like following when it fails for SSLv3 runs fine on > TLSv1 (v1.1 and 1.2 skipped not supported) OpenSSL 0.9.8k (happens on > two machines with this opensslversion) > > -------------------------- > openssl 8564:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad > packet length:s3_clnt.c:879: > > CONNECTED(00000003) > **** User 2013-03-13 09:58:56.238 **** > ssl_to_openssl_SUITE:basic_erlang_server_openssl_client failed on line > 249 Reason: {test_case_failed,{{expected,{<0.10511.0>,ok}}, > {got,{'EXIT',#Port<0.11293>,normal}}}} > > > > > === Ended at 2013-03-13 09:58:56 > === location [{ssl_to_openssl_SUITE,basic_erlang_server_openssl_client,249 > }, > {test_server,ts_tc,1348}, > {test_server,run_test_case_eval1,965}, > {test_server,run_test_case_eval,914}] > === reason = {test_case_failed,{{expected,{<0.10511.0>,ok}}, > {got,{'EXIT',#Port<0.11293>,normal}}}} > > > > openssl 58039:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad packet > length:s3_clnt.c:743: > > > openssl CONNECTED(00000003) > > ------------------------------------ > > On another machin with OpenSSL 0.9.7l test cases fails both for TLS versions > SSLv3 and TLSv1 (v1.1 and 1.2 skipped not supported) > with a similar fault. > > > ------------------------------------ > **** User 2013-03-12 16:28:24.533 **** > ssl_to_openssl_SUITE:erlang_server_openssl_client_client_cert failed on > line 699 Reason: {test_case_failed,{{expected,{<0.8699.0>,ok}}, > {got,{'EXIT',#Port<0.10224>,normal}}}} > > > > > === Ended at 2013-03-12 16:28:24 > === location > [{ssl_to_openssl_SUITE,erlang_server_openssl_client_client_cert,699 > }, > {test_server,ts_tc,1348}, > {test_server,run_test_case_eval1,965}, > {test_server,run_test_case_eval,914}] > === reason = {test_case_failed,{{expected,{<0.8699.0>,ok}}, > {got,{'EXIT',#Port<0.10224>,normal}}}} > > > > ------------------------------------ > > ciphers_rsa_signed_certs fils on openssl 0.9.8o tescase log: > > ------------------------------------ > openssl Using default temp DH parameters > > > **** User 2013-03-12 04:06:31.877 **** =ERROR REPORT==== > 12-Mar-2013::05:06:31 === SSL: hello: ssl_connection.erl:2313:Fatal > error: handshake failure > > **** User 2013-03-12 04:08:40.869 **** =ERROR REPORT==== > 12-Mar-2013::05:08:40 === Testcase process <0.11587.0> not responding to > timetrap timeout: > {timetrap_timeout,120000,[{ssl_to_openssl_SUITE,ciphers_rsa_signed_certs}]}. > Killing testcase... > > **** User 2013-03-12 04:08:40.869 **** Error detected: > testcase_aborted_or_killed > > ------------------------------------ > > Regards Ingela Erlang/OTP team - Ericsson AB > > Fredrik wrote: > > On 03/08/2013 02:06 PM, Andreas Schultz wrote: > >> Hi, > >> > >> I have tested with various openssl versions and the earliest to > >> pass the crypto test is 0.9.8o. I have adjusted the ifdef's > >> in crypto to take that and then NO_ECDH and NO_ECDSA defines > >> into account. I've also discovered a bug where an EC cipher was > >> chosen when the certificate was actually not compatible with > >> it. > >> > >> Update version is here: > >> > >> git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC > >> > >> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > >> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > >> > >> > >> > >> In case anybody is interested, I also have an very early version of > >> AES-GCM cipher support (not for -pu inclusion yet): > >> > >> https://github.com/RoadRunnr/otp/compare/tls-psk-srp-suites-ECC-GCM > >> > >> Andreas > >> > >> ----- Original Message ----- > >>> Hello again, > >>> > >>> Since we want Erlang/OTP to be runnable on OS X Leopard we have to make > >>> an exception to the OpenSSL supported version and make it work here. So > >>> somekind of workaround needs to be done. I'm not sure if this > >>> problem is > >>> for all 0.9.7, or if it is Apple which have decided to do things a > >>> specific way. So maybe the best way would be to check if the header > >>> files exist in configure and then ifdef based on that. Alternatively if > >>> you can determine that this is the way it works in 0.9.7, then you > >>> should just be able to ifdef on the openssl version define. > >>> > >>> Lukas > >>> > >>> On 05/03/13 19:25, Lukas Larsson wrote: > >>>> hmm, now that you mention it, it's 0.9.7l which is unsupported by us. > >>>> I'll get back to you if we need to work around this, or if we can just > >>>> leave it. > >>>> > >>>> Lukas > >>>> > >>>> On 05/03/13 19:12, Andreas Schultz wrote: > >>>>> Hi, > >>>>> > >>>>> ----- Original Message ----- > >>>>>> Hello! > >>>>>> > >>>>>> I just noticed that this patch seems to break the OS X Leopard > >>>>>> build. > >>>>>> > >>>>>> ./otp_build autoconf > >>>>>> ./otp_build configure --enable-smp-support --enable-darwin-universal > >>>>>> make > >>>>>> ... > >>>>>> Lots of text > >>>>>> ... > >>>>> [...] > >>>>> > >>>>>> It would seem like OPENSSL_NO_EC is not defined on OS X Leopard, > >>>>>> even if > >>>>>> the feature is not supported. The feature is supported on Snow > >>>>>> Leopard > >>>>>> and Lion. > >>>>>> > >>>>>> I don't really know how this is meant to work, but maybe a configure > >>>>>> test for osx leopard could work? > >>>>> A test for the openssl version possibly combined with a platform > >>>>> check > >>>>> might be sufficient. I checked openssl 0.9.7 and they did support EC > >>>>> and the OPENSSL_NO_EC define. Could you find out what openssl version > >>>>> leopard has? > >>>>> > >>>>>> As a side note, strangely openssl/ec.h exists, but not ecdh and > >>>>>> ecdsa.... maybe that's why it is not defined? Let me know if you > >>>>>> need > >>>>>> any more info. > >>>>> I'll extend the check for NO_ECDH and NO_ECDSA, that should take > >>>>> care of > >>>>> such a situation. > >>>>> > >>>>> Andreas > >>>>> > >>>>>> Lukas > >>>>>> > >>>>>> On 28/02/13 09:43, Fredrik wrote: > >>>>>>> On 02/27/2013 07:33 PM, Andreas Schultz wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I have fixed the ssl_to_openssl_SUITE failure. The test suite > >>>>>>>> tried to > >>>>>>>> use an EC cipher on an openssl version that has no support for > >>>>>>>> that > >>>>>>>> cipher. > >>>>>>>> > >>>>>>>> I have also tried to reproduced the failing crypto ec test on > >>>>>>>> Ubuntu > >>>>>>>> natty 32bit and 64bit with halfword and m32-build, but it does > >>>>>>>> pass > >>>>>>>> the test on all those variants. > >>>>>>>> > >>>>>>>> Is there anything special or non-standard in your test setup > >>>>>>>> (e.g. configuration switches, manually installed libraries, > >>>>>>>> ...)??? > >>>>>>>> > >>>>>>>> New version with fixed ssl_to_openssl_SUITE here: > >>>>>>>> > >>>>>>>> git fetch git://github.com/RoadRunnr/otp.git > >>>>>>>> tls-psk-srp-suites-ECC > >>>>>>>> > >>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > >>>>>>>> > >>>>>>>> > >>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Andreas > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>>> Hi! > >>>>>>>>> > >>>>>>>>> Andreas Schultz wrote: > >>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>> Hi! > >>>>>>>>>>> > >>>>>>>>>>> I took a look at the failing test cases and found that whit > >>>>>>>>>>> openssl > >>>>>>>>>>> 0.9.8k, openssl > >>>>>>>>>>> > >>>>>>>>>>> will crash with errors like the following: > >>>>>>>>>>> > >>>>>>>>>>> openssl 25966:error:14092073:SSL > >>>>>>>>>>> routines:SSL3_GET_SERVER_HELLO:bad packet > >>>>>>>>>>> length:s3_clnt.c:879: > >>>>>>>>>>> CONNECTED(00000003) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> **** User 2013-02-25 11:01:47.291 **** > >>>>>>>>>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client > >>>>>>>>>>> failed on > >>>>>>>>>>> line > >>>>>>>>>>> 249 Reason: {test_case_failed,{{expected,{<0.11346.0>,ok}}, > >>>>>>>>>>> {got,{'EXIT',#Port<0.11738>,normal}}}} > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> That is why the the test case gets > >>>>>>>>>>> {EXIT',#Port<0.11738>,normal} > >>>>>>>>>>> > >>>>>>>>>>> for the test cases erlang_server_openssl_client, > >>>>>>>>>>> erlang_server_openssl_client_client_cert, > >>>>>>>>>>> erlang_server_openssl_client_dsa_cert, > >>>>>>>>>>> erlang_server_openssl_client_reuse_session > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> and with openssl openssl 0.9.8k and 0.9.8.o there is a > >>>>>>>>>>> hanshake > >>>>>>>>>>> failure > >>>>>>>>>>> in the ciphers_rsa_signed_certs test case > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> Got that too. Will investigate. > >>>>>>>>>> > >>>>>>>>>> Yet this still doesn't explain why the i386 build is showing > >>>>>>>>>> a failure in the crypto EC tests (this also cause a lot of > >>>>>>>>>> the ssl failures later on). > >>>>>>>>> Yes it could be good to investigate that first. > >>>>>>>>> Looking at the crypto testruns it fails on openssl 0.9.8k. > >>>>>>>>> > >>>>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >>>>>>>>> > >>>>>>>>> [...] > >>>>>>>>> > >>>>>>> Hello, > >>>>>>> Re-fetched. Let's see how the testing go now! > >>>>>>> There should be no special configurations as far as I know.. > >>>>>>> > >>>> _______________________________________________ > >>>> erlang-patches mailing list > >>>> erlang-patches@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-patches > >>>> > >>> > > Hello again, > > This seems suspicious that these two openssl versions > > 0.9.8a > > 0.9.7l > > is failing some testcases that other versions are not. We are thinking > > that it could be a bug in openssl but we are not sure. Could you match > > your tests upon your branch on these openssl versions and see if you > > can reproduce them. > > The failing testcases are: > > > > ciphers_rsa_signed_certs > > erlang_server_openssl_client > > erlang_server_openssl_client_client_cert > > erlang_server_openssl_client_dsa_cert > > erlang_server_openssl_client_reuse_session > > > > in the ssl_to_openssl_SUITE suite. > > > > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------ managed broadband access ------------------ Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: HRB21276 Handelsregistergericht Chemnitz Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From yamt@REDACTED Fri Mar 15 16:11:26 2013 From: yamt@REDACTED (YAMAMOTO Takashi) Date: Fri, 15 Mar 2013 15:11:26 +0000 (UTC) Subject: [erlang-patches] netbsd and pkgsrc fixes In-Reply-To: Your message of "Mon, 11 Mar 2013 17:36:13 +0100" <513E07FD.8080908@erlang.org> References: <513E07FD.8080908@erlang.org> Message-ID: <20130315151126.6F54214A3EB@mail.netbsd.org> > Hello, > > Could you please move the #ifdef check for the sys/vmmeter.h to in the > same place as FreeBSD and Dragonfly? With that change this patch is > ready for inclusion. thanks for your comment. here's a modified version. git fetch git://github.com/yamt/otp.git netbsd2 https://github.com/yamt/otp/compare/yamt:netbsd2 https://github.com/yamt/otp/compare/yamt:netbsd2.patch YAMAMOTO Takashi > > Lukas > > On 08/03/13 02:45, YAMAMOTO Takashi wrote: >> build/compilation fixes. >> >> git fetch git://github.com/yamt/otp.git netbsd >> >> https://github.com/yamt/otp/compare/yamt:netbsd >> https://github.com/yamt/otp/compare/yamt:netbsd.patch >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches From klyr@REDACTED Sun Mar 17 16:09:41 2013 From: klyr@REDACTED (Julien Barbot) Date: Sun, 17 Mar 2013 16:09:41 +0100 Subject: [erlang-patches] Fix SSL Next Protocol Negociation documentation Message-ID: Hi, Here is a small documentation patch about SSL Next Protocol Negociation. git fetch git://github.com/klyr/otp.git fix-ssl-npn-doc https://github.com/klyr/otp/compare/erlang:maint...fix-ssl-npn-doc https://github.com/klyr/otp/compare/erlang:maint...fix-ssl-npn-doc.patch -- Julien Barbot From aschultz@REDACTED Mon Mar 18 11:10:53 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Mon, 18 Mar 2013 11:10:53 +0100 (CET) Subject: [erlang-patches] new version elliptic curve support In-Reply-To: <514190AD.3070900@erix.ericsson.se> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <51363893.5030003@erlang.org> <51371164.908@erlang.org> <29745459.479844.1362748005228.JavaMail.root@tpip.net> <513F55F6.8060805@erlang.org> <514056A9.4090605@erix.ericsson.se> <480623580.577114.1363199521282.JavaMail.root@tpip.net> <514190AD.3070900@erix.ericsson.se> Message-ID: <605129724.604878.1363601453944.JavaMail.root@tpip.net> Hi, New version is ready, this one fixed the Server Hello Extensions and should pass the test suites on the older OpenSSL versions: git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch The AES-GCM Cipher Suites support is also ready for greater exposure. The tls-psk-srp-suites-ECC-GCM branch contains the everything from above and the AES-GCM cipher suites. git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC-GCM https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC-GCM https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC-GCM.patch Andreas ----- Original Message ----- > Hi Andreas! > > Andreas Schultz wrote: > > Hi, > > > > Found the cause, the EC patch adds server hello handshake extensions, but > > sends them unconditionally when it should only send them if the client > > requested them. > > > > I'll change that, but it'll take a few days as I'm very busy.... > > > > > > Great that you found it :) And thank you for all the hard work. We can > absolutely wait a few days, I am still waiting for colleagues to review > the crypto part of the patch. However we are getting close to the patch > getting accepted, > and I want to include it soon before I do some of the upcoming things > that we plan to do. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > Andreas > > > > ----- Original Message ----- > > > >> Hi! > >> > >> Just a small clarification. Test cases erlang_server_openssl_client, > >> erlang_server_openssl_client_client_cert , > >> erlang_server_openssl_client_dsa_cert, > >> erlang_server_open and ssl_client_reuse_session fail for some TLS > >> versions on some versions of openssl. > >> > >> Test case log looks like following when it fails for SSLv3 runs fine on > >> TLSv1 (v1.1 and 1.2 skipped not supported) OpenSSL 0.9.8k (happens on > >> two machines with this opensslversion) > >> > >> -------------------------- > >> openssl 8564:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad > >> packet length:s3_clnt.c:879: > >> > >> CONNECTED(00000003) > >> **** User 2013-03-13 09:58:56.238 **** > >> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client failed on line > >> 249 Reason: {test_case_failed,{{expected,{<0.10511.0>,ok}}, > >> {got,{'EXIT',#Port<0.11293>,normal}}}} > >> > >> > >> > >> > >> === Ended at 2013-03-13 09:58:56 > >> === location [{ssl_to_openssl_SUITE,basic_erlang_server_openssl_client,249 > >> }, > >> {test_server,ts_tc,1348}, > >> {test_server,run_test_case_eval1,965}, > >> {test_server,run_test_case_eval,914}] > >> === reason = {test_case_failed,{{expected,{<0.10511.0>,ok}}, > >> {got,{'EXIT',#Port<0.11293>,normal}}}} > >> > >> > >> > >> openssl 58039:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad packet > >> length:s3_clnt.c:743: > >> > >> > >> openssl CONNECTED(00000003) > >> > >> ------------------------------------ > >> > >> On another machin with OpenSSL 0.9.7l test cases fails both for TLS > >> versions > >> SSLv3 and TLSv1 (v1.1 and 1.2 skipped not supported) > >> with a similar fault. > >> > >> > >> ------------------------------------ > >> **** User 2013-03-12 16:28:24.533 **** > >> ssl_to_openssl_SUITE:erlang_server_openssl_client_client_cert failed on > >> line 699 Reason: {test_case_failed,{{expected,{<0.8699.0>,ok}}, > >> {got,{'EXIT',#Port<0.10224>,normal}}}} > >> > >> > >> > >> > >> === Ended at 2013-03-12 16:28:24 > >> === location > >> [{ssl_to_openssl_SUITE,erlang_server_openssl_client_client_cert,699 > >> }, > >> {test_server,ts_tc,1348}, > >> {test_server,run_test_case_eval1,965}, > >> {test_server,run_test_case_eval,914}] > >> === reason = {test_case_failed,{{expected,{<0.8699.0>,ok}}, > >> {got,{'EXIT',#Port<0.10224>,normal}}}} > >> > >> > >> > >> ------------------------------------ > >> > >> ciphers_rsa_signed_certs fils on openssl 0.9.8o tescase log: > >> > >> ------------------------------------ > >> openssl Using default temp DH parameters > >> > >> > >> **** User 2013-03-12 04:06:31.877 **** =ERROR REPORT==== > >> 12-Mar-2013::05:06:31 === SSL: hello: ssl_connection.erl:2313:Fatal > >> error: handshake failure > >> > >> **** User 2013-03-12 04:08:40.869 **** =ERROR REPORT==== > >> 12-Mar-2013::05:08:40 === Testcase process <0.11587.0> not responding to > >> timetrap timeout: > >> {timetrap_timeout,120000,[{ssl_to_openssl_SUITE,ciphers_rsa_signed_certs}]}. > >> Killing testcase... > >> > >> **** User 2013-03-12 04:08:40.869 **** Error detected: > >> testcase_aborted_or_killed > >> > >> ------------------------------------ > >> > >> Regards Ingela Erlang/OTP team - Ericsson AB > >> > >> Fredrik wrote: > >> > >>> On 03/08/2013 02:06 PM, Andreas Schultz wrote: > >>> > >>>> Hi, > >>>> > >>>> I have tested with various openssl versions and the earliest to > >>>> pass the crypto test is 0.9.8o. I have adjusted the ifdef's > >>>> in crypto to take that and then NO_ECDH and NO_ECDSA defines > >>>> into account. I've also discovered a bug where an EC cipher was > >>>> chosen when the certificate was actually not compatible with > >>>> it. > >>>> > >>>> Update version is here: > >>>> > >>>> git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC > >>>> > >>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > >>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > >>>> > >>>> > >>>> > >>>> In case anybody is interested, I also have an very early version of > >>>> AES-GCM cipher support (not for -pu inclusion yet): > >>>> > >>>> https://github.com/RoadRunnr/otp/compare/tls-psk-srp-suites-ECC-GCM > >>>> > >>>> Andreas > >>>> > >>>> ----- Original Message ----- > >>>> > >>>>> Hello again, > >>>>> > >>>>> Since we want Erlang/OTP to be runnable on OS X Leopard we have to make > >>>>> an exception to the OpenSSL supported version and make it work here. So > >>>>> somekind of workaround needs to be done. I'm not sure if this > >>>>> problem is > >>>>> for all 0.9.7, or if it is Apple which have decided to do things a > >>>>> specific way. So maybe the best way would be to check if the header > >>>>> files exist in configure and then ifdef based on that. Alternatively if > >>>>> you can determine that this is the way it works in 0.9.7, then you > >>>>> should just be able to ifdef on the openssl version define. > >>>>> > >>>>> Lukas > >>>>> > >>>>> On 05/03/13 19:25, Lukas Larsson wrote: > >>>>> > >>>>>> hmm, now that you mention it, it's 0.9.7l which is unsupported by us. > >>>>>> I'll get back to you if we need to work around this, or if we can just > >>>>>> leave it. > >>>>>> > >>>>>> Lukas > >>>>>> > >>>>>> On 05/03/13 19:12, Andreas Schultz wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>> > >>>>>>>> Hello! > >>>>>>>> > >>>>>>>> I just noticed that this patch seems to break the OS X Leopard > >>>>>>>> build. > >>>>>>>> > >>>>>>>> ./otp_build autoconf > >>>>>>>> ./otp_build configure --enable-smp-support --enable-darwin-universal > >>>>>>>> make > >>>>>>>> ... > >>>>>>>> Lots of text > >>>>>>>> ... > >>>>>>>> > >>>>>>> [...] > >>>>>>> > >>>>>>> > >>>>>>>> It would seem like OPENSSL_NO_EC is not defined on OS X Leopard, > >>>>>>>> even if > >>>>>>>> the feature is not supported. The feature is supported on Snow > >>>>>>>> Leopard > >>>>>>>> and Lion. > >>>>>>>> > >>>>>>>> I don't really know how this is meant to work, but maybe a configure > >>>>>>>> test for osx leopard could work? > >>>>>>>> > >>>>>>> A test for the openssl version possibly combined with a platform > >>>>>>> check > >>>>>>> might be sufficient. I checked openssl 0.9.7 and they did support EC > >>>>>>> and the OPENSSL_NO_EC define. Could you find out what openssl version > >>>>>>> leopard has? > >>>>>>> > >>>>>>> > >>>>>>>> As a side note, strangely openssl/ec.h exists, but not ecdh and > >>>>>>>> ecdsa.... maybe that's why it is not defined? Let me know if you > >>>>>>>> need > >>>>>>>> any more info. > >>>>>>>> > >>>>>>> I'll extend the check for NO_ECDH and NO_ECDSA, that should take > >>>>>>> care of > >>>>>>> such a situation. > >>>>>>> > >>>>>>> Andreas > >>>>>>> > >>>>>>> > >>>>>>>> Lukas > >>>>>>>> > >>>>>>>> On 28/02/13 09:43, Fredrik wrote: > >>>>>>>> > >>>>>>>>> On 02/27/2013 07:33 PM, Andreas Schultz wrote: > >>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> I have fixed the ssl_to_openssl_SUITE failure. The test suite > >>>>>>>>>> tried to > >>>>>>>>>> use an EC cipher on an openssl version that has no support for > >>>>>>>>>> that > >>>>>>>>>> cipher. > >>>>>>>>>> > >>>>>>>>>> I have also tried to reproduced the failing crypto ec test on > >>>>>>>>>> Ubuntu > >>>>>>>>>> natty 32bit and 64bit with halfword and m32-build, but it does > >>>>>>>>>> pass > >>>>>>>>>> the test on all those variants. > >>>>>>>>>> > >>>>>>>>>> Is there anything special or non-standard in your test setup > >>>>>>>>>> (e.g. configuration switches, manually installed libraries, > >>>>>>>>>> ...)??? > >>>>>>>>>> > >>>>>>>>>> New version with fixed ssl_to_openssl_SUITE here: > >>>>>>>>>> > >>>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git > >>>>>>>>>> tls-psk-srp-suites-ECC > >>>>>>>>>> > >>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Andreas > >>>>>>>>>> > >>>>>>>>>> ----- Original Message ----- > >>>>>>>>>> > >>>>>>>>>>> Hi! > >>>>>>>>>>> > >>>>>>>>>>> Andreas Schultz wrote: > >>>>>>>>>>> > >>>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi! > >>>>>>>>>>>>> > >>>>>>>>>>>>> I took a look at the failing test cases and found that whit > >>>>>>>>>>>>> openssl > >>>>>>>>>>>>> 0.9.8k, openssl > >>>>>>>>>>>>> > >>>>>>>>>>>>> will crash with errors like the following: > >>>>>>>>>>>>> > >>>>>>>>>>>>> openssl 25966:error:14092073:SSL > >>>>>>>>>>>>> routines:SSL3_GET_SERVER_HELLO:bad packet > >>>>>>>>>>>>> length:s3_clnt.c:879: > >>>>>>>>>>>>> CONNECTED(00000003) > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> **** User 2013-02-25 11:01:47.291 **** > >>>>>>>>>>>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client > >>>>>>>>>>>>> failed on > >>>>>>>>>>>>> line > >>>>>>>>>>>>> 249 Reason: {test_case_failed,{{expected,{<0.11346.0>,ok}}, > >>>>>>>>>>>>> {got,{'EXIT',#Port<0.11738>,normal}}}} > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> That is why the the test case gets > >>>>>>>>>>>>> {EXIT',#Port<0.11738>,normal} > >>>>>>>>>>>>> > >>>>>>>>>>>>> for the test cases erlang_server_openssl_client, > >>>>>>>>>>>>> erlang_server_openssl_client_client_cert, > >>>>>>>>>>>>> erlang_server_openssl_client_dsa_cert, > >>>>>>>>>>>>> erlang_server_openssl_client_reuse_session > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> and with openssl openssl 0.9.8k and 0.9.8.o there is a > >>>>>>>>>>>>> hanshake > >>>>>>>>>>>>> failure > >>>>>>>>>>>>> in the ciphers_rsa_signed_certs test case > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> Got that too. Will investigate. > >>>>>>>>>>>> > >>>>>>>>>>>> Yet this still doesn't explain why the i386 build is showing > >>>>>>>>>>>> a failure in the crypto EC tests (this also cause a lot of > >>>>>>>>>>>> the ssl failures later on). > >>>>>>>>>>>> > >>>>>>>>>>> Yes it could be good to investigate that first. > >>>>>>>>>>> Looking at the crypto testruns it fails on openssl 0.9.8k. > >>>>>>>>>>> > >>>>>>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >>>>>>>>>>> > >>>>>>>>>>> [...] > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> Hello, > >>>>>>>>> Re-fetched. Let's see how the testing go now! > >>>>>>>>> There should be no special configurations as far as I know.. > >>>>>>>>> > >>>>>>>>> > >>>>>> _______________________________________________ > >>>>>> erlang-patches mailing list > >>>>>> erlang-patches@REDACTED > >>>>>> http://erlang.org/mailman/listinfo/erlang-patches > >>>>>> > >>>>>> > >>> Hello again, > >>> This seems suspicious that these two openssl versions > >>> 0.9.8a > >>> 0.9.7l > >>> is failing some testcases that other versions are not. We are thinking > >>> that it could be a bug in openssl but we are not sure. Could you match > >>> your tests upon your branch on these openssl versions and see if you > >>> can reproduce them. > >>> The failing testcases are: > >>> > >>> ciphers_rsa_signed_certs > >>> erlang_server_openssl_client > >>> erlang_server_openssl_client_client_cert > >>> erlang_server_openssl_client_dsa_cert > >>> erlang_server_openssl_client_reuse_session > >>> > >>> in the ssl_to_openssl_SUITE suite. > >>> > >>> > >> > > > > > > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------ managed broadband access ------------------ Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: HRB21276 Handelsregistergericht Chemnitz Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From n.oxyde@REDACTED Mon Mar 18 14:07:07 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 18 Mar 2013 14:07:07 +0100 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: <513DE767.90700@erlang.org> References: <4FCE3186.3000202@erlang.org> <5034FB10.7090804@erlang.org> <503CC79B.2020009@erlang.org> <50471240.3060005@erlang.org> <504DF309.2040900@erlang.org> <415229C2-452E-45FF-A207-69BD2212E2F5@gmail.com> <50519F42.7000109@erlang.org> <50598C38.8060506@erlang.org> <77306113-0789-4B6F-A45D-8304FFED5C39@gmail.com> <513DE767.90700@erlang.org> Message-ID: Hi, Just rebased against latest maint. Please refetch. -- Anthony Ramine Le 11 mars 2013 ? 15:17, Fredrik a ?crit : > On 12/02/2012 11:07 AM, Anthony Ramine wrote: >> Hi, >> >> I've made column numbers a non-optional thing in compile but still an >> option in epp; so that tools like edoc which don't need the full >> locations can get only the line numbers. >> >> Please refetch. >> >> -- >> Anthony Ramine >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > Hello, > Could you please rebase this patch upon the current 'maint' branch? > Thanks. > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From n.oxyde@REDACTED Mon Mar 18 14:08:32 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 18 Mar 2013 14:08:32 +0100 Subject: [erlang-patches] [erlang-bugs] Minor annoyance after 'make clean' In-Reply-To: References: <5114E1C0.10901@cs.ntua.gr> Message-ID: <22ED1658-3AD6-49BD-9D69-83A02726CF90@gmail.com> Ping? -- Anthony Ramine Le 8 f?vr. 2013 ? 12:47, Anthony Ramine a ?crit : > Hi, > > It can, and here is a fix. > > git fetch https://github.com/nox/otp.git fix-ssh-html-doc > > https://github.com/nox/otp/compare/erlang:master...fix-ssh-html-doc > https://github.com/nox/otp/compare/erlang:master...fix-ssh-html-doc.patch > > Regards, > > -- > Anthony Ramine > > Le 8 f?vr. 2013 ? 12:30, Kostis Sagonas a ?crit : > >> Every time I issue a 'make clean' the file >> >> lib/ssh/doc/html/SSH_protocols.png >> >> which apparently is part of the code base of the master branch, gets deleted. Is this intentional? >> >> The problem is that after the 'make clean', a subsequent 'git status' command shows the following: >> >> # On branch master >> # Changed but not updated: >> # (use "git add/rm ..." to update what will be committed) >> # (use "git checkout -- ..." to discard changes in working directory) >> # >> # deleted: lib/ssh/doc/html/SSH_protocols.png >> # >> >> >> Can this be fixed? >> >> Kostis >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From n.oxyde@REDACTED Mon Mar 18 14:08:59 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 18 Mar 2013 14:08:59 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: <510FDAC4.5030505@erlang.org> References: <50F02757.4070304@erlang.org> <12C66F49-EF58-4CB3-B4AE-85071C7D9EA1@gmail.com> <510FDAC4.5030505@erlang.org> Message-ID: <4DC949C6-B617-4E4C-86D5-289CB3430108@gmail.com> Ping? -- Anthony Ramine Le 4 f?vr. 2013 ? 16:59, Fredrik a ?crit : > On 02/04/2013 03:46 PM, Anthony Ramine wrote: >> As there been an answer? Will this be in R16B? >> > Bumped it, > Will give you notice when I know more. > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From n.oxyde@REDACTED Mon Mar 18 14:13:09 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 18 Mar 2013 14:13:09 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <50FE512C.8020905@erlang.org> References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> <8D1C563A-E65D-4544-9635-78F0B7A3596D@gmail.com> <50F52480.9040100@erlang.org> <50F5325B.4010005@erlang.org> <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> <50FE512C.8020905@erlang.org> Message-ID: Hi, I rebased my patch against latest maint. It should be safe to merge it now that Kostis fixed the bug in HiPE. Regards, -- Anthony Ramine Le 22 janv. 2013 ? 09:43, Fredrik a ?crit : > Did you or Kostis find a solution to the problems with this patch and hipe? > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/15/2013 01:17 PM, Anthony Ramine wrote: >> Fixed by not using fun references in the two test cases. >> >> Please refetch. >> > From vkuznet@REDACTED Sat Mar 16 15:43:24 2013 From: vkuznet@REDACTED (Valentin Kuznetsov) Date: Sat, 16 Mar 2013 10:43:24 -0400 Subject: [erlang-patches] Fix ssl connection issue using proxy certificate (certificate chain file) Message-ID: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> Hi, physicists working in CERN experiments relies on usage of proxy certificates, i.e. certificate chain file. Those are obtained via grid-proxy-init, voms-proxy-init and can be stored to proxy server. We found that default ssl module partially parses such files and therefore fails to authenticate clients with servers accepting proxy certificates. Provided patch fixes this issue (thanks to Diego da Silva Gomes ), please include: git fetch git://github.com/vkuznet/otp.git ssl_connection4chain_certificate https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate.patch To verify the change you need to have a server which accepts proxy certificate and configure your client with your proxy certificate as following: %% generate user proxy file by using grid-proxy-init %% produced /tmp/x509up_u proxy file contains user private key, certificate and cacertificate %% configure your client to use proxy file Request={Url, Headers}, ProxyCert = "/tmp/x509up_u502", HTTPOptions = [{ssl, [{keyfile, ProxyCert}, {certfile, ProxyCert}, {cacertfile, ProxyCert}]}] httpc:request(get, Request, HTTPOptions, []) Thanks, Valentin. From fredrik@REDACTED Mon Mar 18 16:54:10 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 18 Mar 2013 16:54:10 +0100 Subject: [erlang-patches] Fix ssl connection issue using proxy certificate (certificate chain file) In-Reply-To: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> References: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> Message-ID: <514738A2.7000806@erlang.org> On 03/16/2013 03:43 PM, Valentin Kuznetsov wrote: > Hi, > physicists working in CERN experiments relies on usage of proxy certificates, i.e. certificate chain file. Those are obtained via grid-proxy-init, voms-proxy-init and can be stored to proxy server. > > We found that default ssl module partially parses such files and therefore fails to authenticate clients with servers accepting proxy certificates. Provided patch fixes this issue (thanks to Diego da Silva Gomes), please include: > > git fetch git://github.com/vkuznet/otp.git ssl_connection4chain_certificate > > https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate > https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate.patch > > To verify the change you need to have a server which accepts proxy certificate and configure your client with your proxy certificate as following: > > %% generate user proxy file by using grid-proxy-init > %% produced /tmp/x509up_u proxy file contains user private key, certificate and cacertificate > %% configure your client to use proxy file > Request={Url, Headers}, > ProxyCert = "/tmp/x509up_u502", > HTTPOptions = [{ssl, [{keyfile, ProxyCert}, {certfile, ProxyCert}, {cacertfile, ProxyCert}]}] > httpc:request(get, Request, HTTPOptions, []) > > Thanks, > Valentin. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Fetched, It is now in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Mar 18 17:04:55 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 18 Mar 2013 17:04:55 +0100 Subject: [erlang-patches] [erlang-bugs] Minor annoyance after 'make clean' In-Reply-To: <22ED1658-3AD6-49BD-9D69-83A02726CF90@gmail.com> References: <5114E1C0.10901@cs.ntua.gr> <22ED1658-3AD6-49BD-9D69-83A02726CF90@gmail.com> Message-ID: <51473B27.5080608@erlang.org> On 03/18/2013 02:08 PM, Anthony Ramine wrote: > Ping? > Fetched, Currently building in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Mar 18 17:10:22 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 18 Mar 2013 17:10:22 +0100 Subject: [erlang-patches] Fix SSL Next Protocol Negociation documentation In-Reply-To: References: Message-ID: <51473C6E.9000606@erlang.org> On 03/17/2013 04:09 PM, Julien Barbot wrote: > git fetch git://github.com/klyr/otp.git fix-ssl-npn-doc Fetched, Currently in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From kostis@REDACTED Mon Mar 18 23:04:13 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 19 Mar 2013 00:04:13 +0200 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> <8D1C563A-E65D-4544-9635-78F0B7A3596D@gmail.com> <50F52480.9040100@erlang.org> <50F5325B.4010005@erlang.org> <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> <50FE512C.8020905@erlang.org> Message-ID: <51478F5D.1000409@cs.ntua.gr> On 03/18/2013 03:13 PM, Anthony Ramine wrote: > Hi, > > I rebased my patch against latest maint. It should be safe to merge it now that > Kostis fixed the bug in HiPE. For the record, in this particular case there was no bug in HiPE. For better or worse, the HiPE compiler relies on certain invariants in the code that the BEAM compiler generates. Whenever these invariants get broken, perhaps for very good reasons as in this case, the HiPE compiler also needs to be adapted to not rely on them anymore. It's a quite natural process in software components that depend on each other that would not classify as a bug. Kostis Wishing there was a magic way for software to be "future compatible"... From hm@REDACTED Tue Mar 19 09:38:18 2013 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Tue, 19 Mar 2013 09:38:18 +0100 Subject: [erlang-patches] Relax reltools requirements on excluded applications Message-ID: When generating cross compiled systems it is rather inconvenient that reltool requires that even excluded applications are part of the configuration. The symptom of this is an error claiming that the application directory is missing. With this patch, a missing a application directory is now classified as warning if the application is explicitly excluded. git fetch git://github.com/hawk/otp.git hawk/reltool_relaxed_exclude or viewed here https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude.patch /H?kan From n.oxyde@REDACTED Tue Mar 19 09:22:36 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 19 Mar 2013 09:22:36 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <51478F5D.1000409@cs.ntua.gr> References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> <8D1C563A-E65D-4544-9635-78F0B7A3596D@gmail.com> <50F52480.9040100@erlang.org> <50F5325B.4010005@erlang.org> <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> <50FE512C.8020905@erlang.org> <51478F5D.1000409@cs.ntua.gr> Message-ID: Of course, I sais bug because I was too lazy to be correct. Do you know of any other unsaid invariants on which behaviour HiPE depends and that might be changed in the future? Wouldn't that be documentation-worthy? Regards, -- Anthony Ramine Le 18 mars 2013 ? 23:04, Kostis Sagonas a ?crit : > On 03/18/2013 03:13 PM, Anthony Ramine wrote: >> Hi, >> >> I rebased my patch against latest maint. It should be safe to merge it now that >> Kostis fixed the bug in HiPE. > > For the record, in this particular case there was no bug in HiPE. > > For better or worse, the HiPE compiler relies on certain invariants in the code that the BEAM compiler generates. Whenever these invariants get broken, perhaps for very good reasons as in this case, the HiPE compiler also needs to be adapted to not rely on them anymore. It's a quite natural process in software components that depend on each other that would not classify as a bug. > > Kostis > > Wishing there was a magic way for software to be "future compatible"... From fredrik@REDACTED Tue Mar 19 11:22:59 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 19 Mar 2013 11:22:59 +0100 Subject: [erlang-patches] Relax reltools requirements on excluded applications In-Reply-To: References: Message-ID: <51483C83.7000105@erlang.org> On 03/19/2013 09:38 AM, H?kan Mattsson wrote: > When generating cross compiled systems it is rather inconvenient that > reltool requires that even excluded applications are part of the > configuration. The symptom of this is an error claiming that the > application directory is missing. > > With this patch, a missing a application directory is now classified > as warning if the application is explicitly excluded. > > git fetch git://github.com/hawk/otp.git hawk/reltool_relaxed_exclude > > or viewed here > > https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude > https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude.patch > > /H?kan > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello, Fetched and currently in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Tue Mar 19 11:41:03 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 19 Mar 2013 11:41:03 +0100 Subject: [erlang-patches] Relax reltools requirements on excluded applications In-Reply-To: References: Message-ID: <514840BF.3070600@erlang.org> On 03/19/2013 09:38 AM, H?kan Mattsson wrote: > When generating cross compiled systems it is rather inconvenient that > reltool requires that even excluded applications are part of the > configuration. The symptom of this is an error claiming that the > application directory is missing. > > With this patch, a missing a application directory is now classified > as warning if the application is explicitly excluded. > > git fetch git://github.com/hawk/otp.git hawk/reltool_relaxed_exclude > > or viewed here > > https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude > https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude.patch > > /H?kan > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello, Your patch seems not to build, reltool_server_SUITE.erl:1352:33: variable 'Config' is unbound -- BR Fredrik Gustafsson Erlang OTP Team From aschultz@REDACTED Tue Mar 19 12:24:52 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Tue, 19 Mar 2013 12:24:52 +0100 (CET) Subject: [erlang-patches] new version elliptic curve support In-Reply-To: <5148440E.2030200@erix.ericsson.se> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <29745459.479844.1362748005228.JavaMail.root@tpip.net> <513F55F6.8060805@erlang.org> <514056A9.4090605@erix.ericsson.se> <480623580.577114.1363199521282.JavaMail.root@tpip.net> <514190AD.3070900@erix.ericsson.se> <605129724.604878.1363601453944.JavaMail.root@tpip.net> <5148440E.2030200@erix.ericsson.se> Message-ID: <1436734734.657657.1363692292221.JavaMail.root@tpip.net> Hi Ingela, ----- Original Message ----- > Hi Andreas, > > The problems earlier discussed are gone but unfortunately there are > some new problems, this time on windows 7 openssl-0.9.8-r > same test cases Could you supply some more information on this openssl version, where did it came from. I have checked several openssl versions and non of the 0.9.8 versions is sending a TLS_INVALID_ECPOINTFORMAT_LIST error. The openssl changelogs list Supported Point Formats Extension as a change for openssl-1.0.0. So this has to be some other and or a patched version. > erlang_server_openssl_client > erlang_server_openssl_client_client_cert > erlang_server_openssl_client_dsa_cert > erlang_server_openssl_client_reuse_session > > Here is the log: > > openssl 1619636256:error:1411809D:SSL > routines:SSL_CHECK_SERVERHELLO_TLSEXT:tls invalid ecpointformat > list:t1_lib.c:1440: > > > openssl 1619636256:error:14092113:SSL > routines:SSL3_GET_SERVER_HELLO:serverhello tlsext:s3_clnt.c:942: > > > openssl CONNECTED(00000003) > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 142 bytes and written 0 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1 > Cipher : 0000 > Session-ID: > FD3C226F55392165F7F11F640CB0DCF7E460F32CFCFB49DBE927B162C0AC5811 > Session-ID-ctx: > Master-Key: > Key-Arg : None > PSK identity: None > PSK identity hint: None > Start Time: 1363670812 > Timeout : 7200 (sec) > Verify return code: 0 (ok) > --- > > > **** User 2013-03-19 06:26:51.990 **** > ssl_to_openssl_SUITE:erlang_server_openssl_client failed on line 322 > Reason: {test_case_failed,{{expected,{<0.11506.0>,ok}}, > {got,{'EXIT',#Port<0.11433>,epipe}}}} > > > > > === Ended at 2013-03-19 06:26:52 > === location [{ssl_to_openssl_SUITE,erlang_server_openssl_client,322 > }, > {test_server,ts_tc,1348}, > {test_server,run_test_case_eval1,965}, > {test_server,run_test_case_eval,914}] > === reason = {test_case_failed,{{expected,{<0.11506.0>,ok}}, > {got,{'EXIT',#Port<0.11433>,epipe}}}} > > > Also the test ciphers_rsa_signed_certs breaks, not on windows 7, but on > windows XP openssl 0.9.8.r (the above test case work here which is > interesting) and solaris > also openssl-0.9.8.r Is this new or did the error occur with previous version of the patch as well? Andreas > > Test case log: > > openssl Using default temp DH parameters > > > **** User 2013-03-19 06:12:59.276 **** =ERROR REPORT==== > 19-Mar-2013::07:12:59 === SSL: hello: ssl_connection.erl:2318:Fatal > error: handshake failure > > **** User 2013-03-19 06:15:08.209 **** =ERROR REPORT==== > 19-Mar-2013::07:15:08 === Testcase process <0.11572.0> not responding to > timetrap timeout: > {timetrap_timeout,120000,[{ssl_to_openssl_SUITE,ciphers_rsa_signed_certs}]}. > Killing testcase... > > **** User 2013-03-19 06:15:08.209 **** Error detected: > testcase_aborted_or_killed > > > > > === Ended at 2013-03-19 06:15:08 > === location unknown > === reason = testcase_aborted_or_killed > > > Regards Ingela Erlang/OTP team - Ericsson AB > > Andreas Schultz wrote: > > Hi, > > > > New version is ready, this one fixed the Server Hello Extensions and should > > pass the test suites on the older OpenSSL versions: > > > > git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC > > > > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > > > > The AES-GCM Cipher Suites support is also ready for greater exposure. The > > tls-psk-srp-suites-ECC-GCM branch contains the everything from above and > > the AES-GCM cipher suites. > > > > git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC-GCM > > > > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC-GCM > > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC-GCM.patch > > > > Andreas > > > > ----- Original Message ----- > > > >> Hi Andreas! > >> > >> Andreas Schultz wrote: > >> > >>> Hi, > >>> > >>> Found the cause, the EC patch adds server hello handshake extensions, but > >>> sends them unconditionally when it should only send them if the client > >>> requested them. > >>> > >>> I'll change that, but it'll take a few days as I'm very busy.... > >>> > >>> > >>> > >> Great that you found it :) And thank you for all the hard work. We can > >> absolutely wait a few days, I am still waiting for colleagues to review > >> the crypto part of the patch. However we are getting close to the patch > >> getting accepted, > >> and I want to include it soon before I do some of the upcoming things > >> that we plan to do. > >> > >> Regards Ingela Erlang/OTP team - Ericsson AB > >> > >> > >>> Andreas > >>> > >>> ----- Original Message ----- > >>> > >>> > >>>> Hi! > >>>> > >>>> Just a small clarification. Test cases erlang_server_openssl_client, > >>>> erlang_server_openssl_client_client_cert , > >>>> erlang_server_openssl_client_dsa_cert, > >>>> erlang_server_open and ssl_client_reuse_session fail for some TLS > >>>> versions on some versions of openssl. > >>>> > >>>> Test case log looks like following when it fails for SSLv3 runs fine on > >>>> TLSv1 (v1.1 and 1.2 skipped not supported) OpenSSL 0.9.8k (happens on > >>>> two machines with this opensslversion) > >>>> > >>>> -------------------------- > >>>> openssl 8564:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad > >>>> packet length:s3_clnt.c:879: > >>>> > >>>> CONNECTED(00000003) > >>>> **** User 2013-03-13 09:58:56.238 **** > >>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client failed on line > >>>> 249 Reason: {test_case_failed,{{expected,{<0.10511.0>,ok}}, > >>>> {got,{'EXIT',#Port<0.11293>,normal}}}} > >>>> > >>>> > >>>> > >>>> > >>>> === Ended at 2013-03-13 09:58:56 > >>>> === location > >>>> [{ssl_to_openssl_SUITE,basic_erlang_server_openssl_client,249 > >>>> }, > >>>> {test_server,ts_tc,1348}, > >>>> {test_server,run_test_case_eval1,965}, > >>>> {test_server,run_test_case_eval,914}] > >>>> === reason = {test_case_failed,{{expected,{<0.10511.0>,ok}}, > >>>> {got,{'EXIT',#Port<0.11293>,normal}}}} > >>>> > >>>> > >>>> > >>>> openssl 58039:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad > >>>> packet > >>>> length:s3_clnt.c:743: > >>>> > >>>> > >>>> openssl CONNECTED(00000003) > >>>> > >>>> ------------------------------------ > >>>> > >>>> On another machin with OpenSSL 0.9.7l test cases fails both for TLS > >>>> versions > >>>> SSLv3 and TLSv1 (v1.1 and 1.2 skipped not supported) > >>>> with a similar fault. > >>>> > >>>> > >>>> ------------------------------------ > >>>> **** User 2013-03-12 16:28:24.533 **** > >>>> ssl_to_openssl_SUITE:erlang_server_openssl_client_client_cert failed on > >>>> line 699 Reason: {test_case_failed,{{expected,{<0.8699.0>,ok}}, > >>>> {got,{'EXIT',#Port<0.10224>,normal}}}} > >>>> > >>>> > >>>> > >>>> > >>>> === Ended at 2013-03-12 16:28:24 > >>>> === location > >>>> [{ssl_to_openssl_SUITE,erlang_server_openssl_client_client_cert,699 > >>>> }, > >>>> {test_server,ts_tc,1348}, > >>>> {test_server,run_test_case_eval1,965}, > >>>> {test_server,run_test_case_eval,914}] > >>>> === reason = {test_case_failed,{{expected,{<0.8699.0>,ok}}, > >>>> {got,{'EXIT',#Port<0.10224>,normal}}}} > >>>> > >>>> > >>>> > >>>> ------------------------------------ > >>>> > >>>> ciphers_rsa_signed_certs fils on openssl 0.9.8o tescase log: > >>>> > >>>> ------------------------------------ > >>>> openssl Using default temp DH parameters > >>>> > >>>> > >>>> **** User 2013-03-12 04:06:31.877 **** =ERROR REPORT==== > >>>> 12-Mar-2013::05:06:31 === SSL: hello: ssl_connection.erl:2313:Fatal > >>>> error: handshake failure > >>>> > >>>> **** User 2013-03-12 04:08:40.869 **** =ERROR REPORT==== > >>>> 12-Mar-2013::05:08:40 === Testcase process <0.11587.0> not responding to > >>>> timetrap timeout: > >>>> {timetrap_timeout,120000,[{ssl_to_openssl_SUITE,ciphers_rsa_signed_certs}]}. > >>>> Killing testcase... > >>>> > >>>> **** User 2013-03-12 04:08:40.869 **** Error detected: > >>>> testcase_aborted_or_killed > >>>> > >>>> ------------------------------------ > >>>> > >>>> Regards Ingela Erlang/OTP team - Ericsson AB > >>>> > >>>> Fredrik wrote: > >>>> > >>>> > >>>>> On 03/08/2013 02:06 PM, Andreas Schultz wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I have tested with various openssl versions and the earliest to > >>>>>> pass the crypto test is 0.9.8o. I have adjusted the ifdef's > >>>>>> in crypto to take that and then NO_ECDH and NO_ECDSA defines > >>>>>> into account. I've also discovered a bug where an EC cipher was > >>>>>> chosen when the certificate was actually not compatible with > >>>>>> it. > >>>>>> > >>>>>> Update version is here: > >>>>>> > >>>>>> git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites-ECC > >>>>>> > >>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > >>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > >>>>>> > >>>>>> > >>>>>> > >>>>>> In case anybody is interested, I also have an very early version of > >>>>>> AES-GCM cipher support (not for -pu inclusion yet): > >>>>>> > >>>>>> https://github.com/RoadRunnr/otp/compare/tls-psk-srp-suites-ECC-GCM > >>>>>> > >>>>>> Andreas > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>> > >>>>>> > >>>>>>> Hello again, > >>>>>>> > >>>>>>> Since we want Erlang/OTP to be runnable on OS X Leopard we have to > >>>>>>> make > >>>>>>> an exception to the OpenSSL supported version and make it work here. > >>>>>>> So > >>>>>>> somekind of workaround needs to be done. I'm not sure if this > >>>>>>> problem is > >>>>>>> for all 0.9.7, or if it is Apple which have decided to do things a > >>>>>>> specific way. So maybe the best way would be to check if the header > >>>>>>> files exist in configure and then ifdef based on that. Alternatively > >>>>>>> if > >>>>>>> you can determine that this is the way it works in 0.9.7, then you > >>>>>>> should just be able to ifdef on the openssl version define. > >>>>>>> > >>>>>>> Lukas > >>>>>>> > >>>>>>> On 05/03/13 19:25, Lukas Larsson wrote: > >>>>>>> > >>>>>>> > >>>>>>>> hmm, now that you mention it, it's 0.9.7l which is unsupported by > >>>>>>>> us. > >>>>>>>> I'll get back to you if we need to work around this, or if we can > >>>>>>>> just > >>>>>>>> leave it. > >>>>>>>> > >>>>>>>> Lukas > >>>>>>>> > >>>>>>>> On 05/03/13 19:12, Andreas Schultz wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> ----- Original Message ----- > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Hello! > >>>>>>>>>> > >>>>>>>>>> I just noticed that this patch seems to break the OS X Leopard > >>>>>>>>>> build. > >>>>>>>>>> > >>>>>>>>>> ./otp_build autoconf > >>>>>>>>>> ./otp_build configure --enable-smp-support > >>>>>>>>>> --enable-darwin-universal > >>>>>>>>>> make > >>>>>>>>>> ... > >>>>>>>>>> Lots of text > >>>>>>>>>> ... > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> [...] > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> It would seem like OPENSSL_NO_EC is not defined on OS X Leopard, > >>>>>>>>>> even if > >>>>>>>>>> the feature is not supported. The feature is supported on Snow > >>>>>>>>>> Leopard > >>>>>>>>>> and Lion. > >>>>>>>>>> > >>>>>>>>>> I don't really know how this is meant to work, but maybe a > >>>>>>>>>> configure > >>>>>>>>>> test for osx leopard could work? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> A test for the openssl version possibly combined with a platform > >>>>>>>>> check > >>>>>>>>> might be sufficient. I checked openssl 0.9.7 and they did support > >>>>>>>>> EC > >>>>>>>>> and the OPENSSL_NO_EC define. Could you find out what openssl > >>>>>>>>> version > >>>>>>>>> leopard has? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> As a side note, strangely openssl/ec.h exists, but not ecdh and > >>>>>>>>>> ecdsa.... maybe that's why it is not defined? Let me know if you > >>>>>>>>>> need > >>>>>>>>>> any more info. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> I'll extend the check for NO_ECDH and NO_ECDSA, that should take > >>>>>>>>> care of > >>>>>>>>> such a situation. > >>>>>>>>> > >>>>>>>>> Andreas > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Lukas > >>>>>>>>>> > >>>>>>>>>> On 28/02/13 09:43, Fredrik wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On 02/27/2013 07:33 PM, Andreas Schultz wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Hi, > >>>>>>>>>>>> > >>>>>>>>>>>> I have fixed the ssl_to_openssl_SUITE failure. The test suite > >>>>>>>>>>>> tried to > >>>>>>>>>>>> use an EC cipher on an openssl version that has no support for > >>>>>>>>>>>> that > >>>>>>>>>>>> cipher. > >>>>>>>>>>>> > >>>>>>>>>>>> I have also tried to reproduced the failing crypto ec test on > >>>>>>>>>>>> Ubuntu > >>>>>>>>>>>> natty 32bit and 64bit with halfword and m32-build, but it does > >>>>>>>>>>>> pass > >>>>>>>>>>>> the test on all those variants. > >>>>>>>>>>>> > >>>>>>>>>>>> Is there anything special or non-standard in your test setup > >>>>>>>>>>>> (e.g. configuration switches, manually installed libraries, > >>>>>>>>>>>> ...)??? > >>>>>>>>>>>> > >>>>>>>>>>>> New version with fixed ssl_to_openssl_SUITE here: > >>>>>>>>>>>> > >>>>>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git > >>>>>>>>>>>> tls-psk-srp-suites-ECC > >>>>>>>>>>>> > >>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites-ECC.patch > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Andreas > >>>>>>>>>>>> > >>>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi! > >>>>>>>>>>>>> > >>>>>>>>>>>>> Andreas Schultz wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi! > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I took a look at the failing test cases and found that whit > >>>>>>>>>>>>>>> openssl > >>>>>>>>>>>>>>> 0.9.8k, openssl > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> will crash with errors like the following: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> openssl 25966:error:14092073:SSL > >>>>>>>>>>>>>>> routines:SSL3_GET_SERVER_HELLO:bad packet > >>>>>>>>>>>>>>> length:s3_clnt.c:879: > >>>>>>>>>>>>>>> CONNECTED(00000003) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> **** User 2013-02-25 11:01:47.291 **** > >>>>>>>>>>>>>>> ssl_to_openssl_SUITE:basic_erlang_server_openssl_client > >>>>>>>>>>>>>>> failed on > >>>>>>>>>>>>>>> line > >>>>>>>>>>>>>>> 249 Reason: {test_case_failed,{{expected,{<0.11346.0>,ok}}, > >>>>>>>>>>>>>>> {got,{'EXIT',#Port<0.11738>,normal}}}} > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> That is why the the test case gets > >>>>>>>>>>>>>>> {EXIT',#Port<0.11738>,normal} > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> for the test cases erlang_server_openssl_client, > >>>>>>>>>>>>>>> erlang_server_openssl_client_client_cert, > >>>>>>>>>>>>>>> erlang_server_openssl_client_dsa_cert, > >>>>>>>>>>>>>>> erlang_server_openssl_client_reuse_session > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> and with openssl openssl 0.9.8k and 0.9.8.o there is a > >>>>>>>>>>>>>>> hanshake > >>>>>>>>>>>>>>> failure > >>>>>>>>>>>>>>> in the ciphers_rsa_signed_certs test case > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> Got that too. Will investigate. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yet this still doesn't explain why the i386 build is showing > >>>>>>>>>>>>>> a failure in the crypto EC tests (this also cause a lot of > >>>>>>>>>>>>>> the ssl failures later on). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> Yes it could be good to investigate that first. > >>>>>>>>>>>>> Looking at the crypto testruns it fails on openssl 0.9.8k. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB > >>>>>>>>>>>>> > >>>>>>>>>>>>> [...] > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> Hello, > >>>>>>>>>>> Re-fetched. Let's see how the testing go now! > >>>>>>>>>>> There should be no special configurations as far as I know.. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> erlang-patches mailing list > >>>>>>>> erlang-patches@REDACTED > >>>>>>>> http://erlang.org/mailman/listinfo/erlang-patches > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> Hello again, > >>>>> This seems suspicious that these two openssl versions > >>>>> 0.9.8a > >>>>> 0.9.7l > >>>>> is failing some testcases that other versions are not. We are thinking > >>>>> that it could be a bug in openssl but we are not sure. Could you match > >>>>> your tests upon your branch on these openssl versions and see if you > >>>>> can reproduce them. > >>>>> The failing testcases are: > >>>>> > >>>>> ciphers_rsa_signed_certs > >>>>> erlang_server_openssl_client > >>>>> erlang_server_openssl_client_client_cert > >>>>> erlang_server_openssl_client_dsa_cert > >>>>> erlang_server_openssl_client_reuse_session > >>>>> > >>>>> in the ssl_to_openssl_SUITE suite. > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > > > > > > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------ managed broadband access ------------------ Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: HRB21276 Handelsregistergericht Chemnitz Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From hm@REDACTED Tue Mar 19 12:48:07 2013 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Tue, 19 Mar 2013 12:48:07 +0100 Subject: [erlang-patches] Relax reltools requirements on excluded applications In-Reply-To: <514840BF.3070600@erlang.org> References: <514840BF.3070600@erlang.org> Message-ID: On Tue, Mar 19, 2013 at 11:41 AM, Fredrik wrote: > On 03/19/2013 09:38 AM, H?kan Mattsson wrote: >> >> When generating cross compiled systems it is rather inconvenient that >> reltool requires that even excluded applications are part of the >> configuration. The symptom of this is an error claiming that the >> application directory is missing. >> >> With this patch, a missing a application directory is now classified >> as warning if the application is explicitly excluded. >> >> git fetch git://github.com/hawk/otp.git hawk/reltool_relaxed_exclude >> >> or viewed here >> >> https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude >> https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude.patch >> >> /H?kan >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > Hello, > Your patch seems not to build, > > reltool_server_SUITE.erl:1352:33: variable 'Config' is unbound Sorry. I did a last minute change in the test program. Please, refetch. /H?kan From fredrik@REDACTED Tue Mar 19 13:57:06 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 19 Mar 2013 13:57:06 +0100 Subject: [erlang-patches] Relax reltools requirements on excluded applications In-Reply-To: References: <514840BF.3070600@erlang.org> Message-ID: <514860A2.9070004@erlang.org> On 03/19/2013 12:48 PM, H?kan Mattsson wrote: > On Tue, Mar 19, 2013 at 11:41 AM, Fredrik wrote: >> On 03/19/2013 09:38 AM, H?kan Mattsson wrote: >>> When generating cross compiled systems it is rather inconvenient that >>> reltool requires that even excluded applications are part of the >>> configuration. The symptom of this is an error claiming that the >>> application directory is missing. >>> >>> With this patch, a missing a application directory is now classified >>> as warning if the application is explicitly excluded. >>> >>> git fetch git://github.com/hawk/otp.git hawk/reltool_relaxed_exclude >>> >>> or viewed here >>> >>> https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude >>> https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude.patch >>> >>> /H?kan >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> Hello, >> Your patch seems not to build, >> >> reltool_server_SUITE.erl:1352:33: variable 'Config' is unbound > Sorry. I did a last minute change in the test program. > Please, refetch. > > /H?kan Thanks, Re-fetched. -- BR Fredrik Gustafsson Erlang OTP Team From olivier.girondel@REDACTED Tue Mar 19 17:09:03 2013 From: olivier.girondel@REDACTED (Olivier Girondel) Date: Tue, 19 Mar 2013 17:09:03 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 Message-ID: Hi, This patch enables one to set the RTLD_GLOBAL flag when loading a driver git fetch git://github.com/oliv3/otp.git erl_ddll_try_load1 https://github.com/oliv3/otp/compare/erlang:maint...erl_ddll_try_load1 https://github.com/oliv3/otp/compare/erlang:maint...erl_ddll_try_load1.patch -- Olivier From n.oxyde@REDACTED Wed Mar 20 09:38:21 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 20 Mar 2013 09:38:21 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: <819C7547-3B43-4F8E-A4E0-91B77C547600@gmail.com> References: <50A4FAA9.1070706@erlang.org> <466D4B3A-8B3C-4AA7-9A2B-B85EA5EA2A90@gmail.com> <819C7547-3B43-4F8E-A4E0-91B77C547600@gmail.com> Message-ID: Will someone ever review this, pretty please with sugar on top? It was postponed for R16A; could you tell me if it can be included in R17? Regards, -- Anthony Ramine Le 5 f?vr. 2013 ? 13:51, Anthony Ramine a ?crit : > Hi, > > Rebased against latest master?which I gather is now for R17. Please refetch. > > Regards, > > -- > Anthony Ramine > > Le 21 nov. 2012 ? 15:36, Anthony Ramine a ?crit : > >> Hi, >> >> I had forgotten to update the abstract format documentation, named_fun is >> now mentioned in absform.xml in the doc commit. >> >> Please refetch, >> >> -- >> Anthony Ramine >> >> Le 15 nov. 2012 ? 15:22, Henrik Nord a ?crit : >> >>> I will add this patch to 'master-pu'. >>> >>> Thank you for your contribution! >>> >>> >>> On 2012-11-14 17:42, Anthony Ramine wrote: >>>> This patch implements EEP37: Funs with names >>>> >>>> This adds optional names to fun expressions. A named fun expression >>>> is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse. >>>> >>>> If a fun expression has a name, it must be present and be the same in >>>> every of its clauses. The function name shadows the environment of the >>>> expression shadowing the environment and it is shadowed by the >>>> environment of the clauses' arguments. An unused function name triggers >>>> a warning unless it is prefixed by _, just as every variable. >>>> Variable _ is allowed as a function name. >>>> >>>> It is not an error to put a named function in a record field default >>>> value. >>>> >>>> When transforming to Core Erlang, the named fun Fun is changed into >>>> the following expression: >>>> >>>> letrec 'Fun'/Arity = >>>> fun (Args) -> >>>> let = 'Fun'/Arity >>>> in Case >>>> in 'Fun'/Arity >>>> >>>> where Args is the list of arguments of 'Fun'/Arity and Case the >>>> Core Erlang expression corresponding to the clauses of Fun. >>>> >>>> This transformation allows us to entirely skip any k_var to k_local >>>> transformation in the fun's clauses bodies. >>>> >>>> https://github.com/nox/otp/compare/erlang:master...eep37 >>>> https://github.com/nox/otp/compare/erlang:master...eep37.patch >>>> >>>> git fetch https://github.com/nox/otp eep37 >>>> >>>> Regards, >>>> >>> >>> -- >>> /Henrik Nord Erlang/OTP >>> >> > From mc@REDACTED Wed Mar 20 09:53:18 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Wed, 20 Mar 2013 04:53:18 -0400 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: <50A4FAA9.1070706@erlang.org> <466D4B3A-8B3C-4AA7-9A2B-B85EA5EA2A90@gmail.com> <819C7547-3B43-4F8E-A4E0-91B77C547600@gmail.com> Message-ID: +1 This is an especially useful console enhancement that allows anonymous function recursion... On Wed, Mar 20, 2013 at 4:38 AM, Anthony Ramine wrote: > Will someone ever review this, pretty please with sugar on top? > > It was postponed for R16A; could you tell me if it can be included in R17? > > Regards, > > -- > Anthony Ramine > > Le 5 f?vr. 2013 ? 13:51, Anthony Ramine a ?crit : > >> Hi, >> >> Rebased against latest master?which I gather is now for R17. Please refetch. >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 21 nov. 2012 ? 15:36, Anthony Ramine a ?crit : >> >>> Hi, >>> >>> I had forgotten to update the abstract format documentation, named_fun is >>> now mentioned in absform.xml in the doc commit. >>> >>> Please refetch, >>> >>> -- >>> Anthony Ramine >>> >>> Le 15 nov. 2012 ? 15:22, Henrik Nord a ?crit : >>> >>>> I will add this patch to 'master-pu'. >>>> >>>> Thank you for your contribution! >>>> >>>> >>>> On 2012-11-14 17:42, Anthony Ramine wrote: >>>>> This patch implements EEP37: Funs with names >>>>> >>>>> This adds optional names to fun expressions. A named fun expression >>>>> is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse. >>>>> >>>>> If a fun expression has a name, it must be present and be the same in >>>>> every of its clauses. The function name shadows the environment of the >>>>> expression shadowing the environment and it is shadowed by the >>>>> environment of the clauses' arguments. An unused function name triggers >>>>> a warning unless it is prefixed by _, just as every variable. >>>>> Variable _ is allowed as a function name. >>>>> >>>>> It is not an error to put a named function in a record field default >>>>> value. >>>>> >>>>> When transforming to Core Erlang, the named fun Fun is changed into >>>>> the following expression: >>>>> >>>>> letrec 'Fun'/Arity = >>>>> fun (Args) -> >>>>> let = 'Fun'/Arity >>>>> in Case >>>>> in 'Fun'/Arity >>>>> >>>>> where Args is the list of arguments of 'Fun'/Arity and Case the >>>>> Core Erlang expression corresponding to the clauses of Fun. >>>>> >>>>> This transformation allows us to entirely skip any k_var to k_local >>>>> transformation in the fun's clauses bodies. >>>>> >>>>> https://github.com/nox/otp/compare/erlang:master...eep37 >>>>> https://github.com/nox/otp/compare/erlang:master...eep37.patch >>>>> >>>>> git fetch https://github.com/nox/otp eep37 >>>>> >>>>> Regards, >>>>> >>>> >>>> -- >>>> /Henrik Nord Erlang/OTP >>>> >>> >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman From fredrik@REDACTED Wed Mar 20 10:18:26 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 20 Mar 2013 10:18:26 +0100 Subject: [erlang-patches] Fix ssl connection issue using proxy certificate (certificate chain file) In-Reply-To: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> References: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> Message-ID: <51497EE2.9090500@erlang.org> On 03/16/2013 03:43 PM, Valentin Kuznetsov wrote: > Hi, > physicists working in CERN experiments relies on usage of proxy certificates, i.e. certificate chain file. Those are obtained via grid-proxy-init, voms-proxy-init and can be stored to proxy server. > > We found that default ssl module partially parses such files and therefore fails to authenticate clients with servers accepting proxy certificates. Provided patch fixes this issue (thanks to Diego da Silva Gomes), please include: > > git fetch git://github.com/vkuznet/otp.git ssl_connection4chain_certificate > > https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate > https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate.patch > > To verify the change you need to have a server which accepts proxy certificate and configure your client with your proxy certificate as following: > > %% generate user proxy file by using grid-proxy-init > %% produced /tmp/x509up_u proxy file contains user private key, certificate and cacertificate > %% configure your client to use proxy file > Request={Url, Headers}, > ProxyCert = "/tmp/x509up_u502", > HTTPOptions = [{ssl, [{keyfile, ProxyCert}, {certfile, ProxyCert}, {cacertfile, ProxyCert}]}] > httpc:request(get, Request, HTTPOptions, []) > > Thanks, > Valentin. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello, could you please rebase this patch upon current maint branch instead? -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Wed Mar 20 10:20:12 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 20 Mar 2013 10:20:12 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: References: Message-ID: <51497F4C.1030106@erlang.org> On 03/19/2013 05:09 PM, Olivier Girondel wrote: > Hi, > > This patch enables one to set the RTLD_GLOBAL flag when loading a driver > > git fetch git://github.com/oliv3/otp.git erl_ddll_try_load1 > > https://github.com/oliv3/otp/compare/erlang:maint...erl_ddll_try_load1 > https://github.com/oliv3/otp/compare/erlang:maint...erl_ddll_try_load1.patch > Hello, Please rebase your patch upon the current 'maint' branch. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Wed Mar 20 10:31:12 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 20 Mar 2013 10:31:12 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: <50A4FAA9.1070706@erlang.org> <466D4B3A-8B3C-4AA7-9A2B-B85EA5EA2A90@gmail.com> <819C7547-3B43-4F8E-A4E0-91B77C547600@gmail.com> Message-ID: <514981E0.9030209@erlang.org> On 03/20/2013 09:53 AM, Pedram Nimreezi wrote: > +1 This is an especially useful console enhancement that allows > anonymous function recursion... > > On Wed, Mar 20, 2013 at 4:38 AM, Anthony Ramine wrote: >> Will someone ever review this, pretty please with sugar on top? >> >> It was postponed for R16A; could you tell me if it can be included in R17? >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 5 f?vr. 2013 ? 13:51, Anthony Ramine a ?crit : >> >>> Hi, >>> >>> Rebased against latest master?which I gather is now for R17. Please refetch. >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> >>> Le 21 nov. 2012 ? 15:36, Anthony Ramine a ?crit : >>> >>>> Hi, >>>> >>>> I had forgotten to update the abstract format documentation, named_fun is >>>> now mentioned in absform.xml in the doc commit. >>>> >>>> Please refetch, >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 15 nov. 2012 ? 15:22, Henrik Nord a ?crit : >>>> >>>>> I will add this patch to 'master-pu'. >>>>> >>>>> Thank you for your contribution! >>>>> >>>>> >>>>> On 2012-11-14 17:42, Anthony Ramine wrote: >>>>>> This patch implements EEP37: Funs with names >>>>>> >>>>>> This adds optional names to fun expressions. A named fun expression >>>>>> is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse. >>>>>> >>>>>> If a fun expression has a name, it must be present and be the same in >>>>>> every of its clauses. The function name shadows the environment of the >>>>>> expression shadowing the environment and it is shadowed by the >>>>>> environment of the clauses' arguments. An unused function name triggers >>>>>> a warning unless it is prefixed by _, just as every variable. >>>>>> Variable _ is allowed as a function name. >>>>>> >>>>>> It is not an error to put a named function in a record field default >>>>>> value. >>>>>> >>>>>> When transforming to Core Erlang, the named fun Fun is changed into >>>>>> the following expression: >>>>>> >>>>>> letrec 'Fun'/Arity = >>>>>> fun (Args) -> >>>>>> let = 'Fun'/Arity >>>>>> in Case >>>>>> in 'Fun'/Arity >>>>>> >>>>>> where Args is the list of arguments of 'Fun'/Arity and Case the >>>>>> Core Erlang expression corresponding to the clauses of Fun. >>>>>> >>>>>> This transformation allows us to entirely skip any k_var to k_local >>>>>> transformation in the fun's clauses bodies. >>>>>> >>>>>> https://github.com/nox/otp/compare/erlang:master...eep37 >>>>>> https://github.com/nox/otp/compare/erlang:master...eep37.patch >>>>>> >>>>>> git fetch https://github.com/nox/otp eep37 >>>>>> >>>>>> Regards, >>>>>> >>>>> -- >>>>> /Henrik Nord Erlang/OTP >>>>> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > Hello, To get the patch going in pu, Could you rebase it upon the current 'maint' branch. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Wed Mar 20 10:59:06 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 20 Mar 2013 10:59:06 +0100 Subject: [erlang-patches] Fix ssl connection issue using proxy certificate (certificate chain file) In-Reply-To: <51497EE2.9090500@erlang.org> References: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> <51497EE2.9090500@erlang.org> Message-ID: <5149886A.4050701@erlang.org> On 03/20/2013 10:18 AM, Fredrik wrote: > On 03/16/2013 03:43 PM, Valentin Kuznetsov wrote: >> Hi, >> physicists working in CERN experiments relies on usage of proxy >> certificates, i.e. certificate chain file. Those are obtained via >> grid-proxy-init, voms-proxy-init and can be stored to proxy server. >> >> We found that default ssl module partially parses such files and >> therefore fails to authenticate clients with servers accepting proxy >> certificates. Provided patch fixes this issue (thanks to Diego da >> Silva Gomes), please include: >> >> git fetch git://github.com/vkuznet/otp.git >> ssl_connection4chain_certificate >> >> https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate >> >> https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate.patch >> >> >> To verify the change you need to have a server which accepts proxy >> certificate and configure your client with your proxy certificate as >> following: >> >> %% generate user proxy file by using grid-proxy-init >> %% produced /tmp/x509up_u proxy file contains user private key, >> certificate and cacertificate >> %% configure your client to use proxy file >> Request={Url, Headers}, >> ProxyCert = "/tmp/x509up_u502", >> HTTPOptions = [{ssl, [{keyfile, ProxyCert}, {certfile, ProxyCert}, >> {cacertfile, ProxyCert}]}] >> httpc:request(get, Request, HTTPOptions, []) >> >> Thanks, >> Valentin. >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > Hello, could you please rebase this patch upon current maint branch > instead? > Except the rebaseing, you could make some changes to your patch. This T variable you are initiating is not used and we think it should be an unbound variable (_) instead. Could you also add a explanation why this is the way to go to handle this. Does this proxy concept guarantee that the first certificate is the 'own certificate' ? -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Wed Mar 20 13:44:28 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 20 Mar 2013 13:44:28 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: <20809.43582.542254.99152@ornendil.otp.ericsson.se> References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> Message-ID: <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> Hi, Replying on list because I think it's important. As I said to someone I don't remember the name, this patch is only a necessary step to what my final goal is: Clang-like diagnostics for Erlang compilation [1]. Is that something the OTP team wouldn't like to see? How is the end location in tokens redundant? I need the end locations of each tokens to be able to compute the location ranges of each node in the AST, see my work-in-progress commit for more informations [2]. That being said, I am interested in having your feedback about the implementation. Regards, [1] http://clang.llvm.org/diagnostics.html [2] https://github.com/nox/otp/commit/2c8038c#diff-1 PS: Sorry Hans for replying twice, I failed the Cc header. -- Anthony Ramine Le 20 mars 2013 ? 13:23, Hans Bolinder a ?crit : > Hi Anthony, > > Sorry for not replying sooner. > > We'll most likely reject you patch. I asked Vlad Dumitrescu about it, > and he agrees with me that the functionality (the end location of > tokens) is redundant. > > Apart from that: when it comes to the implementation there are a few > things I don't approve of, but I need to take a closer look before > saying anything more. You've put in a good effort here, and I intend > to elaborate a little more on the implementation when I find the time > to investigate in more detail. > > Best regards, > > Hans Bolinder, Erlang/OTP team, Ericsson From vladdu55@REDACTED Wed Mar 20 13:49:56 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 20 Mar 2013 13:49:56 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> Message-ID: Hi Anthony, Don't the tokens have a start position and a length? Why do you need an explicit end position? regards, Vlad On Wed, Mar 20, 2013 at 1:44 PM, Anthony Ramine wrote: > Hi, > > Replying on list because I think it's important. > > As I said to someone I don't remember the name, this patch is only a > necessary step to what my final goal is: Clang-like diagnostics for > Erlang compilation [1]. Is that something the OTP team wouldn't like > to see? > > How is the end location in tokens redundant? I need the end locations > of each tokens to be able to compute the location ranges of each node > in the AST, see my work-in-progress commit for more informations [2]. > > That being said, I am interested in having your feedback about the > implementation. > > Regards, > > [1] http://clang.llvm.org/diagnostics.html > [2] https://github.com/nox/otp/commit/2c8038c#diff-1 > > PS: Sorry Hans for replying twice, I failed the Cc header. > > -- > Anthony Ramine > > Le 20 mars 2013 ? 13:23, Hans Bolinder a ?crit : > > > Hi Anthony, > > > > Sorry for not replying sooner. > > > > We'll most likely reject you patch. I asked Vlad Dumitrescu about it, > > and he agrees with me that the functionality (the end location of > > tokens) is redundant. > > > > Apart from that: when it comes to the implementation there are a few > > things I don't approve of, but I need to take a closer look before > > saying anything more. You've put in a good effort here, and I intend > > to elaborate a little more on the implementation when I find the time > > to investigate in more detail. > > > > Best regards, > > > > Hans Bolinder, Erlang/OTP team, Ericsson > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Mar 20 14:00:09 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 20 Mar 2013 14:00:09 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> Message-ID: Hi Vlad, Thanks for the quick reply. The length of the token is defined as its length in characters. That is all fine for most tokens that are on a single line, but things go to hell when you take into account multiline strings, atoms and chars. -- Anthony Ramine Le 20 mars 2013 ? 13:49, Vlad Dumitrescu a ?crit : > Hi Anthony, > > Don't the tokens have a start position and a length? Why do you need an explicit end position? > > regards, > Vlad > > > > On Wed, Mar 20, 2013 at 1:44 PM, Anthony Ramine wrote: > Hi, > > Replying on list because I think it's important. > > As I said to someone I don't remember the name, this patch is only a > necessary step to what my final goal is: Clang-like diagnostics for > Erlang compilation [1]. Is that something the OTP team wouldn't like > to see? > > How is the end location in tokens redundant? I need the end locations > of each tokens to be able to compute the location ranges of each node > in the AST, see my work-in-progress commit for more informations [2]. > > That being said, I am interested in having your feedback about the > implementation. > > Regards, > > [1] http://clang.llvm.org/diagnostics.html > [2] https://github.com/nox/otp/commit/2c8038c#diff-1 > > PS: Sorry Hans for replying twice, I failed the Cc header. > > -- > Anthony Ramine > > Le 20 mars 2013 ? 13:23, Hans Bolinder a ?crit : > > > Hi Anthony, > > > > Sorry for not replying sooner. > > > > We'll most likely reject you patch. I asked Vlad Dumitrescu about it, > > and he agrees with me that the functionality (the end location of > > tokens) is redundant. > > > > Apart from that: when it comes to the implementation there are a few > > things I don't approve of, but I need to take a closer look before > > saying anything more. You've put in a good effort here, and I intend > > to elaborate a little more on the implementation when I find the time > > to investigate in more detail. > > > > Best regards, > > > > Hans Bolinder, Erlang/OTP team, Ericsson > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From vladdu55@REDACTED Wed Mar 20 14:06:07 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 20 Mar 2013 14:06:07 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> Message-ID: Hi, The multiline elements could be handled with the help of an utility that given a string and a (starting) position can compute the end position. I would hope that the implementation already has it in one form or another. regards, Vlad On Wed, Mar 20, 2013 at 2:00 PM, Anthony Ramine wrote: > Hi Vlad, > > Thanks for the quick reply. > > The length of the token is defined as its length in characters. That is all > fine for most tokens that are on a single line, but things go to hell when > you take into account multiline strings, atoms and chars. > > -- > Anthony Ramine > > Le 20 mars 2013 ? 13:49, Vlad Dumitrescu a ?crit : > > > Hi Anthony, > > > > Don't the tokens have a start position and a length? Why do you need an > explicit end position? > > > > regards, > > Vlad > > > > > > > > On Wed, Mar 20, 2013 at 1:44 PM, Anthony Ramine > wrote: > > Hi, > > > > Replying on list because I think it's important. > > > > As I said to someone I don't remember the name, this patch is only a > > necessary step to what my final goal is: Clang-like diagnostics for > > Erlang compilation [1]. Is that something the OTP team wouldn't like > > to see? > > > > How is the end location in tokens redundant? I need the end locations > > of each tokens to be able to compute the location ranges of each node > > in the AST, see my work-in-progress commit for more informations [2]. > > > > That being said, I am interested in having your feedback about the > > implementation. > > > > Regards, > > > > [1] http://clang.llvm.org/diagnostics.html > > [2] https://github.com/nox/otp/commit/2c8038c#diff-1 > > > > PS: Sorry Hans for replying twice, I failed the Cc header. > > > > -- > > Anthony Ramine > > > > Le 20 mars 2013 ? 13:23, Hans Bolinder a ?crit : > > > > > Hi Anthony, > > > > > > Sorry for not replying sooner. > > > > > > We'll most likely reject you patch. I asked Vlad Dumitrescu about it, > > > and he agrees with me that the functionality (the end location of > > > tokens) is redundant. > > > > > > Apart from that: when it comes to the implementation there are a few > > > things I don't approve of, but I need to take a closer look before > > > saying anything more. You've put in a good effort here, and I intend > > > to elaborate a little more on the implementation when I find the time > > > to investigate in more detail. > > > > > > Best regards, > > > > > > Hans Bolinder, Erlang/OTP team, Ericsson > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Mar 20 15:22:45 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 20 Mar 2013 15:22:45 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> Message-ID: It doesn't, as my patch doesn't rely on the 'text' option of erl_scan being set. Currently, when the compiler parses a file, it does not keep in memory the text values of every token. I can understand why you thought it's redundant if you were thinking the start + the length would suffice. But now you are suggesting I keep track of every text value to avoid having both a start and an end. The lexer does not need to do extra work to keep track of end locations, otherwise how would it know the start location of the next token? It already has in memory, at some point, the end location of each token it scans. All this patch does is make it available when it returns. Furthermore, let's put back this patch in the context of diagnostics and thus parse ranges: You are right when you say that {'+',[{line,1},{column,1},{'end',{1,2}}]} and {'+',[{line,1},{column,1},{length,1}]} are equivalent. Just the same, {integer,[{line,1},{column,1},{'end',{1,2}}],1} and {integer,[{line,1},{column,1},{length,1}],1} are also equivalent. But how can I compute the locations range of "1 + 2"? You are suggesting that I try to compute the length of this thing, by substracting the start locations of "2" and "1" and then adding the length of "2". That would give me the whole length of the {op,...,'+',...,...} node. But what about nodes that span more than one line? To cover these cases, you are suggesting I keep track of the text of the tokens. Should I compute the text of the whole node? What about memory usage? That would be a pain in the ass for huge files, like erl_parse.erl. By keeping track of the end location, I introduce nearly no additional overhead in the scanner, and I can keep things simple and constant in memory usage while computing the location ranges of AST nodes in the parser. I don't see how this information can be computed easily (and correctly) by either keeping the length or the text values, but feel free to prove me wrong on this. Also, feel free to tell me if I'm not clear enough, I'm enjoying this conversation a lot and would love to receive constructive feedback again. Regards, -- Anthony Ramine Le 20 mars 2013 ? 14:06, Vlad Dumitrescu a ?crit : > Hi, > > The multiline elements could be handled with the help of an utility that given a string and a (starting) position can compute the end position. I would hope that the implementation already has it in one form or another. > > regards, > Vlad > > > > On Wed, Mar 20, 2013 at 2:00 PM, Anthony Ramine wrote: > Hi Vlad, > > Thanks for the quick reply. > > The length of the token is defined as its length in characters. That is all > fine for most tokens that are on a single line, but things go to hell when > you take into account multiline strings, atoms and chars. > > -- > Anthony Ramine > > Le 20 mars 2013 ? 13:49, Vlad Dumitrescu a ?crit : > > > Hi Anthony, > > > > Don't the tokens have a start position and a length? Why do you need an explicit end position? > > > > regards, > > Vlad > > > > > > > > On Wed, Mar 20, 2013 at 1:44 PM, Anthony Ramine wrote: > > Hi, > > > > Replying on list because I think it's important. > > > > As I said to someone I don't remember the name, this patch is only a > > necessary step to what my final goal is: Clang-like diagnostics for > > Erlang compilation [1]. Is that something the OTP team wouldn't like > > to see? > > > > How is the end location in tokens redundant? I need the end locations > > of each tokens to be able to compute the location ranges of each node > > in the AST, see my work-in-progress commit for more informations [2]. > > > > That being said, I am interested in having your feedback about the > > implementation. > > > > Regards, > > > > [1] http://clang.llvm.org/diagnostics.html > > [2] https://github.com/nox/otp/commit/2c8038c#diff-1 > > > > PS: Sorry Hans for replying twice, I failed the Cc header. > > > > -- > > Anthony Ramine > > > > Le 20 mars 2013 ? 13:23, Hans Bolinder a ?crit : > > > > > Hi Anthony, > > > > > > Sorry for not replying sooner. > > > > > > We'll most likely reject you patch. I asked Vlad Dumitrescu about it, > > > and he agrees with me that the functionality (the end location of > > > tokens) is redundant. > > > > > > Apart from that: when it comes to the implementation there are a few > > > things I don't approve of, but I need to take a closer look before > > > saying anything more. You've put in a good effort here, and I intend > > > to elaborate a little more on the implementation when I find the time > > > to investigate in more detail. > > > > > > Best regards, > > > > > > Hans Bolinder, Erlang/OTP team, Ericsson > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > From n.oxyde@REDACTED Wed Mar 20 15:26:52 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 20 Mar 2013 15:26:52 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> Message-ID: <3CE981B6-9BF9-4B1F-9FA7-837635711676@gmail.com> I forgot an important point: epp sitting between erl_scan and erl_parse complicate things, as the text value of a token may not correspond to what is actually written in the source file. Regards, -- Anthony Ramine Le 20 mars 2013 ? 15:22, Anthony Ramine a ?crit : > It doesn't, as my patch doesn't rely on the 'text' option of > erl_scan being set. > > Currently, when the compiler parses a file, it does not keep > in memory the text values of every token. I can understand > why you thought it's redundant if you were thinking the > start + the length would suffice. But now you are suggesting > I keep track of every text value to avoid having both a start > and an end. > > The lexer does not need to do extra work to keep track of end > locations, otherwise how would it know the start location of > the next token? It already has in memory, at some point, the > end location of each token it scans. All this patch does is > make it available when it returns. > > Furthermore, let's put back this patch in the context of > diagnostics and thus parse ranges: > > You are right when you say that {'+',[{line,1},{column,1},{'end',{1,2}}]} > and {'+',[{line,1},{column,1},{length,1}]} are equivalent. > > Just the same, {integer,[{line,1},{column,1},{'end',{1,2}}],1} and > {integer,[{line,1},{column,1},{length,1}],1} are also equivalent. > > But how can I compute the locations range of "1 + 2"? You are > suggesting that I try to compute the length of this thing, by > substracting the start locations of "2" and "1" and then adding > the length of "2". That would give me the whole length of the > {op,...,'+',...,...} node. But what about nodes that span more > than one line? To cover these cases, you are suggesting I keep > track of the text of the tokens. Should I compute the text of > the whole node? What about memory usage? That would be a pain > in the ass for huge files, like erl_parse.erl. > > By keeping track of the end location, I introduce nearly no > additional overhead in the scanner, and I can keep things simple > and constant in memory usage while computing the location ranges > of AST nodes in the parser. > > I don't see how this information can be computed easily (and > correctly) by either keeping the length or the text values, but > feel free to prove me wrong on this. > > Also, feel free to tell me if I'm not clear enough, I'm enjoying > this conversation a lot and would love to receive constructive > feedback again. > > Regards, > > -- > Anthony Ramine > > Le 20 mars 2013 ? 14:06, Vlad Dumitrescu a ?crit : > >> Hi, >> >> The multiline elements could be handled with the help of an utility that given a string and a (starting) position can compute the end position. I would hope that the implementation already has it in one form or another. >> >> regards, >> Vlad >> >> >> >> On Wed, Mar 20, 2013 at 2:00 PM, Anthony Ramine wrote: >> Hi Vlad, >> >> Thanks for the quick reply. >> >> The length of the token is defined as its length in characters. That is all >> fine for most tokens that are on a single line, but things go to hell when >> you take into account multiline strings, atoms and chars. >> >> -- >> Anthony Ramine >> >> Le 20 mars 2013 ? 13:49, Vlad Dumitrescu a ?crit : >> >>> Hi Anthony, >>> >>> Don't the tokens have a start position and a length? Why do you need an explicit end position? >>> >>> regards, >>> Vlad >>> >>> >>> >>> On Wed, Mar 20, 2013 at 1:44 PM, Anthony Ramine wrote: >>> Hi, >>> >>> Replying on list because I think it's important. >>> >>> As I said to someone I don't remember the name, this patch is only a >>> necessary step to what my final goal is: Clang-like diagnostics for >>> Erlang compilation [1]. Is that something the OTP team wouldn't like >>> to see? >>> >>> How is the end location in tokens redundant? I need the end locations >>> of each tokens to be able to compute the location ranges of each node >>> in the AST, see my work-in-progress commit for more informations [2]. >>> >>> That being said, I am interested in having your feedback about the >>> implementation. >>> >>> Regards, >>> >>> [1] http://clang.llvm.org/diagnostics.html >>> [2] https://github.com/nox/otp/commit/2c8038c#diff-1 >>> >>> PS: Sorry Hans for replying twice, I failed the Cc header. >>> >>> -- >>> Anthony Ramine >>> >>> Le 20 mars 2013 ? 13:23, Hans Bolinder a ?crit : >>> >>>> Hi Anthony, >>>> >>>> Sorry for not replying sooner. >>>> >>>> We'll most likely reject you patch. I asked Vlad Dumitrescu about it, >>>> and he agrees with me that the functionality (the end location of >>>> tokens) is redundant. >>>> >>>> Apart from that: when it comes to the implementation there are a few >>>> things I don't approve of, but I need to take a closer look before >>>> saying anything more. You've put in a good effort here, and I intend >>>> to elaborate a little more on the implementation when I find the time >>>> to investigate in more detail. >>>> >>>> Best regards, >>>> >>>> Hans Bolinder, Erlang/OTP team, Ericsson >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >> >> > From n.oxyde@REDACTED Wed Mar 20 15:30:44 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 20 Mar 2013 15:30:44 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: <514981E0.9030209@erlang.org> References: <50A4FAA9.1070706@erlang.org> <466D4B3A-8B3C-4AA7-9A2B-B85EA5EA2A90@gmail.com> <819C7547-3B43-4F8E-A4E0-91B77C547600@gmail.com> <514981E0.9030209@erlang.org> Message-ID: <806DFCE7-CC09-46F9-8B71-F97CE9E04A39@gmail.com> Rebased! :) Does it mean it may be included before R17? Branch maint is for minor releases, right? -- Anthony Ramine Le 20 mars 2013 ? 10:31, Fredrik a ?crit : > On 03/20/2013 09:53 AM, Pedram Nimreezi wrote: >> +1 This is an especially useful console enhancement that allows >> anonymous function recursion... >> >> On Wed, Mar 20, 2013 at 4:38 AM, Anthony Ramine wrote: >>> Will someone ever review this, pretty please with sugar on top? >>> >>> It was postponed for R16A; could you tell me if it can be included in R17? >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> >>> Le 5 f?vr. 2013 ? 13:51, Anthony Ramine a ?crit : >>> >>>> Hi, >>>> >>>> Rebased against latest master?which I gather is now for R17. Please refetch. >>>> >>>> Regards, >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 21 nov. 2012 ? 15:36, Anthony Ramine a ?crit : >>>> >>>>> Hi, >>>>> >>>>> I had forgotten to update the abstract format documentation, named_fun is >>>>> now mentioned in absform.xml in the doc commit. >>>>> >>>>> Please refetch, >>>>> >>>>> -- >>>>> Anthony Ramine >>>>> >>>>> Le 15 nov. 2012 ? 15:22, Henrik Nord a ?crit : >>>>> >>>>>> I will add this patch to 'master-pu'. >>>>>> >>>>>> Thank you for your contribution! >>>>>> >>>>>> >>>>>> On 2012-11-14 17:42, Anthony Ramine wrote: >>>>>>> This patch implements EEP37: Funs with names >>>>>>> >>>>>>> This adds optional names to fun expressions. A named fun expression >>>>>>> is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse. >>>>>>> >>>>>>> If a fun expression has a name, it must be present and be the same in >>>>>>> every of its clauses. The function name shadows the environment of the >>>>>>> expression shadowing the environment and it is shadowed by the >>>>>>> environment of the clauses' arguments. An unused function name triggers >>>>>>> a warning unless it is prefixed by _, just as every variable. >>>>>>> Variable _ is allowed as a function name. >>>>>>> >>>>>>> It is not an error to put a named function in a record field default >>>>>>> value. >>>>>>> >>>>>>> When transforming to Core Erlang, the named fun Fun is changed into >>>>>>> the following expression: >>>>>>> >>>>>>> letrec 'Fun'/Arity = >>>>>>> fun (Args) -> >>>>>>> let = 'Fun'/Arity >>>>>>> in Case >>>>>>> in 'Fun'/Arity >>>>>>> >>>>>>> where Args is the list of arguments of 'Fun'/Arity and Case the >>>>>>> Core Erlang expression corresponding to the clauses of Fun. >>>>>>> >>>>>>> This transformation allows us to entirely skip any k_var to k_local >>>>>>> transformation in the fun's clauses bodies. >>>>>>> >>>>>>> https://github.com/nox/otp/compare/erlang:master...eep37 >>>>>>> https://github.com/nox/otp/compare/erlang:master...eep37.patch >>>>>>> >>>>>>> git fetch https://github.com/nox/otp eep37 >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>> -- >>>>>> /Henrik Nord Erlang/OTP >>>>>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> >> > Hello, > To get the patch going in pu, > Could you rebase it upon the current 'maint' branch. > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From fredrik@REDACTED Wed Mar 20 15:33:18 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 20 Mar 2013 15:33:18 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: <806DFCE7-CC09-46F9-8B71-F97CE9E04A39@gmail.com> References: <50A4FAA9.1070706@erlang.org> <466D4B3A-8B3C-4AA7-9A2B-B85EA5EA2A90@gmail.com> <819C7547-3B43-4F8E-A4E0-91B77C547600@gmail.com> <514981E0.9030209@erlang.org> <806DFCE7-CC09-46F9-8B71-F97CE9E04A39@gmail.com> Message-ID: <5149C8AE.8030509@erlang.org> On 03/20/2013 03:30 PM, Anthony Ramine wrote: > Rebased! :) > > Does it mean it may be included before R17? Branch maint is for minor > releases, right? > Right now im collecting all the patches active at the moment in pu. That does not mean it will be included in a minor release. :) -- BR Fredrik Gustafsson Erlang OTP Team From vladdu55@REDACTED Wed Mar 20 16:08:41 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 20 Mar 2013 16:08:41 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> Message-ID: Hi, I see your points. I am a little biased by the fact that we are using our own extended scanner in erlide, where we have all this extra information. For a tool that handles source, this is necessary because there are several places where the token's value and its representation aren't the same (for example, based integers). If you use the return_white_space option, then the end location of a token is the one just before the start of the next one. This should be easier to handle than using the token length. On the other hand, you are right that the scanner already has this information available and it's just a matter of making it available, so I wouldn't mind to don't need to do the calculations myself. And even if I have to keep track of the token text anyway, I agree that not everybody should be forced to. I haven't checked your patch in detail, maybe I should :-) regards, Vlad On Wed, Mar 20, 2013 at 3:22 PM, Anthony Ramine wrote: > It doesn't, as my patch doesn't rely on the 'text' option of > erl_scan being set. > > Currently, when the compiler parses a file, it does not keep > in memory the text values of every token. I can understand > why you thought it's redundant if you were thinking the > start + the length would suffice. But now you are suggesting > I keep track of every text value to avoid having both a start > and an end. > > The lexer does not need to do extra work to keep track of end > locations, otherwise how would it know the start location of > the next token? It already has in memory, at some point, the > end location of each token it scans. All this patch does is > make it available when it returns. > > Furthermore, let's put back this patch in the context of > diagnostics and thus parse ranges: > > You are right when you say that {'+',[{line,1},{column,1},{'end',{1,2}}]} > and {'+',[{line,1},{column,1},{length,1}]} are equivalent. > > Just the same, {integer,[{line,1},{column,1},{'end',{1,2}}],1} and > {integer,[{line,1},{column,1},{length,1}],1} are also equivalent. > > But how can I compute the locations range of "1 + 2"? You are > suggesting that I try to compute the length of this thing, by > substracting the start locations of "2" and "1" and then adding > the length of "2". That would give me the whole length of the > {op,...,'+',...,...} node. But what about nodes that span more > than one line? To cover these cases, you are suggesting I keep > track of the text of the tokens. Should I compute the text of > the whole node? What about memory usage? That would be a pain > in the ass for huge files, like erl_parse.erl. > > By keeping track of the end location, I introduce nearly no > additional overhead in the scanner, and I can keep things simple > and constant in memory usage while computing the location ranges > of AST nodes in the parser. > > I don't see how this information can be computed easily (and > correctly) by either keeping the length or the text values, but > feel free to prove me wrong on this. > > Also, feel free to tell me if I'm not clear enough, I'm enjoying > this conversation a lot and would love to receive constructive > feedback again. > > Regards, > > -- > Anthony Ramine > > Le 20 mars 2013 ? 14:06, Vlad Dumitrescu a ?crit : > > > Hi, > > > > The multiline elements could be handled with the help of an utility that > given a string and a (starting) position can compute the end position. I > would hope that the implementation already has it in one form or another. > > > > regards, > > Vlad > > > > > > > > On Wed, Mar 20, 2013 at 2:00 PM, Anthony Ramine > wrote: > > Hi Vlad, > > > > Thanks for the quick reply. > > > > The length of the token is defined as its length in characters. That is > all > > fine for most tokens that are on a single line, but things go to hell > when > > you take into account multiline strings, atoms and chars. > > > > -- > > Anthony Ramine > > > > Le 20 mars 2013 ? 13:49, Vlad Dumitrescu a ?crit : > > > > > Hi Anthony, > > > > > > Don't the tokens have a start position and a length? Why do you need > an explicit end position? > > > > > > regards, > > > Vlad > > > > > > > > > > > > On Wed, Mar 20, 2013 at 1:44 PM, Anthony Ramine > wrote: > > > Hi, > > > > > > Replying on list because I think it's important. > > > > > > As I said to someone I don't remember the name, this patch is only a > > > necessary step to what my final goal is: Clang-like diagnostics for > > > Erlang compilation [1]. Is that something the OTP team wouldn't like > > > to see? > > > > > > How is the end location in tokens redundant? I need the end locations > > > of each tokens to be able to compute the location ranges of each node > > > in the AST, see my work-in-progress commit for more informations [2]. > > > > > > That being said, I am interested in having your feedback about the > > > implementation. > > > > > > Regards, > > > > > > [1] http://clang.llvm.org/diagnostics.html > > > [2] https://github.com/nox/otp/commit/2c8038c#diff-1 > > > > > > PS: Sorry Hans for replying twice, I failed the Cc header. > > > > > > -- > > > Anthony Ramine > > > > > > Le 20 mars 2013 ? 13:23, Hans Bolinder a ?crit : > > > > > > > Hi Anthony, > > > > > > > > Sorry for not replying sooner. > > > > > > > > We'll most likely reject you patch. I asked Vlad Dumitrescu about it, > > > > and he agrees with me that the functionality (the end location of > > > > tokens) is redundant. > > > > > > > > Apart from that: when it comes to the implementation there are a few > > > > things I don't approve of, but I need to take a closer look before > > > > saying anything more. You've put in a good effort here, and I intend > > > > to elaborate a little more on the implementation when I find the time > > > > to investigate in more detail. > > > > > > > > Best regards, > > > > > > > > Hans Bolinder, Erlang/OTP team, Ericsson > > > > > > _______________________________________________ > > > 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 Mar 20 16:09:48 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 20 Mar 2013 16:09:48 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: <3CE981B6-9BF9-4B1F-9FA7-837635711676@gmail.com> References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> <3CE981B6-9BF9-4B1F-9FA7-837635711676@gmail.com> Message-ID: That's another can of worms... I think we should join the movement for liberation from the preprocessor :-) /Vlad On Wed, Mar 20, 2013 at 3:26 PM, Anthony Ramine wrote: > I forgot an important point: epp sitting between erl_scan and > erl_parse complicate things, as the text value of a token may > not correspond to what is actually written in the source file. > > Regards, > > -- > Anthony Ramine > > Le 20 mars 2013 ? 15:22, Anthony Ramine a ?crit : > > > It doesn't, as my patch doesn't rely on the 'text' option of > > erl_scan being set. > > > > Currently, when the compiler parses a file, it does not keep > > in memory the text values of every token. I can understand > > why you thought it's redundant if you were thinking the > > start + the length would suffice. But now you are suggesting > > I keep track of every text value to avoid having both a start > > and an end. > > > > The lexer does not need to do extra work to keep track of end > > locations, otherwise how would it know the start location of > > the next token? It already has in memory, at some point, the > > end location of each token it scans. All this patch does is > > make it available when it returns. > > > > Furthermore, let's put back this patch in the context of > > diagnostics and thus parse ranges: > > > > You are right when you say that {'+',[{line,1},{column,1},{'end',{1,2}}]} > > and {'+',[{line,1},{column,1},{length,1}]} are equivalent. > > > > Just the same, {integer,[{line,1},{column,1},{'end',{1,2}}],1} and > > {integer,[{line,1},{column,1},{length,1}],1} are also equivalent. > > > > But how can I compute the locations range of "1 + 2"? You are > > suggesting that I try to compute the length of this thing, by > > substracting the start locations of "2" and "1" and then adding > > the length of "2". That would give me the whole length of the > > {op,...,'+',...,...} node. But what about nodes that span more > > than one line? To cover these cases, you are suggesting I keep > > track of the text of the tokens. Should I compute the text of > > the whole node? What about memory usage? That would be a pain > > in the ass for huge files, like erl_parse.erl. > > > > By keeping track of the end location, I introduce nearly no > > additional overhead in the scanner, and I can keep things simple > > and constant in memory usage while computing the location ranges > > of AST nodes in the parser. > > > > I don't see how this information can be computed easily (and > > correctly) by either keeping the length or the text values, but > > feel free to prove me wrong on this. > > > > Also, feel free to tell me if I'm not clear enough, I'm enjoying > > this conversation a lot and would love to receive constructive > > feedback again. > > > > Regards, > > > > -- > > Anthony Ramine > > > > Le 20 mars 2013 ? 14:06, Vlad Dumitrescu a ?crit : > > > >> Hi, > >> > >> The multiline elements could be handled with the help of an utility > that given a string and a (starting) position can compute the end position. > I would hope that the implementation already has it in one form or another. > >> > >> regards, > >> Vlad > >> > >> > >> > >> On Wed, Mar 20, 2013 at 2:00 PM, Anthony Ramine > wrote: > >> Hi Vlad, > >> > >> Thanks for the quick reply. > >> > >> The length of the token is defined as its length in characters. That is > all > >> fine for most tokens that are on a single line, but things go to hell > when > >> you take into account multiline strings, atoms and chars. > >> > >> -- > >> Anthony Ramine > >> > >> Le 20 mars 2013 ? 13:49, Vlad Dumitrescu a ?crit : > >> > >>> Hi Anthony, > >>> > >>> Don't the tokens have a start position and a length? Why do you need > an explicit end position? > >>> > >>> regards, > >>> Vlad > >>> > >>> > >>> > >>> On Wed, Mar 20, 2013 at 1:44 PM, Anthony Ramine > wrote: > >>> Hi, > >>> > >>> Replying on list because I think it's important. > >>> > >>> As I said to someone I don't remember the name, this patch is only a > >>> necessary step to what my final goal is: Clang-like diagnostics for > >>> Erlang compilation [1]. Is that something the OTP team wouldn't like > >>> to see? > >>> > >>> How is the end location in tokens redundant? I need the end locations > >>> of each tokens to be able to compute the location ranges of each node > >>> in the AST, see my work-in-progress commit for more informations [2]. > >>> > >>> That being said, I am interested in having your feedback about the > >>> implementation. > >>> > >>> Regards, > >>> > >>> [1] http://clang.llvm.org/diagnostics.html > >>> [2] https://github.com/nox/otp/commit/2c8038c#diff-1 > >>> > >>> PS: Sorry Hans for replying twice, I failed the Cc header. > >>> > >>> -- > >>> Anthony Ramine > >>> > >>> Le 20 mars 2013 ? 13:23, Hans Bolinder a ?crit : > >>> > >>>> Hi Anthony, > >>>> > >>>> Sorry for not replying sooner. > >>>> > >>>> We'll most likely reject you patch. I asked Vlad Dumitrescu about it, > >>>> and he agrees with me that the functionality (the end location of > >>>> tokens) is redundant. > >>>> > >>>> Apart from that: when it comes to the implementation there are a few > >>>> things I don't approve of, but I need to take a closer look before > >>>> saying anything more. You've put in a good effort here, and I intend > >>>> to elaborate a little more on the implementation when I find the time > >>>> to investigate in more detail. > >>>> > >>>> Best regards, > >>>> > >>>> Hans Bolinder, Erlang/OTP team, Ericsson > >>> > >>> _______________________________________________ > >>> erlang-patches mailing list > >>> erlang-patches@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-patches > >>> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.girondel@REDACTED Wed Mar 20 16:44:52 2013 From: olivier.girondel@REDACTED (Olivier Girondel) Date: Wed, 20 Mar 2013 16:44:52 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: <51497F4C.1030106@erlang.org> References: <51497F4C.1030106@erlang.org> Message-ID: On Wed, Mar 20, 2013 at 10:20 AM, Fredrik wrote: > Hello, > Please rebase your patch upon the current 'maint' branch. Hi Fredrik, Rebased and simplified to a new branch git fetch git://github.com/oliv3/otp.git erl_ddll_try_load3 https://github.com/oliv3/otp/compare/erlang:maint...erl_ddll_try_load3 https://github.com/oliv3/otp/compare/erlang:maint...erl_ddll_try_load3.patch -- Olivier From fredrik@REDACTED Wed Mar 20 17:15:29 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 20 Mar 2013 17:15:29 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: References: <51497F4C.1030106@erlang.org> Message-ID: <5149E0A1.7000909@erlang.org> On 03/20/2013 04:44 PM, Olivier Girondel wrote: > git fetch git://github.com/oliv3/otp.git erl_ddll_try_load3 Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Wed Mar 20 18:01:00 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 20 Mar 2013 18:01:00 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: References: <51497F4C.1030106@erlang.org> Message-ID: <5149EB4C.2070608@erlang.org> On 03/20/2013 04:44 PM, Olivier Girondel wrote: > On Wed, Mar 20, 2013 at 10:20 AM, Fredrik wrote: >> Hello, >> Please rebase your patch upon the current 'maint' branch. > Hi Fredrik, > > Rebased and simplified to a new branch > > git fetch git://github.com/oliv3/otp.git erl_ddll_try_load3 > > https://github.com/oliv3/otp/compare/erlang:maint...erl_ddll_try_load3 > https://github.com/oliv3/otp/compare/erlang:maint...erl_ddll_try_load3.patch > Does not seem to build on windows: beam/erl_bif_ddll.c(1534) : error C2065: 'RTLD_GLOBAL' : undeclared identifier -- BR Fredrik Gustafsson Erlang OTP Team From olivier.girondel@REDACTED Wed Mar 20 18:09:04 2013 From: olivier.girondel@REDACTED (Olivier Girondel) Date: Wed, 20 Mar 2013 18:09:04 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: <5149EB4C.2070608@erlang.org> References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> Message-ID: On Wed, Mar 20, 2013 at 6:01 PM, Fredrik wrote: > Does not seem to build on windows: > > beam/erl_bif_ddll.c(1534) : error C2065: 'RTLD_GLOBAL' : undeclared > identifier I just pushed this: commit bdd0017f087a42f328f77debfb658ab0a0b2bc00 Author: Olivier Girondel Date: Wed Mar 20 18:06:13 2013 +0100 Add missing RTLD_GLOBAL definition diff --git a/erts/emulator/beam/erl_bif_ddll.c b/erts/emulator/beam/erl_bif_ddll.c index 91a083c..af8d3be 100644 --- a/erts/emulator/beam/erl_bif_ddll.c +++ b/erts/emulator/beam/erl_bif_ddll.c @@ -53,6 +53,9 @@ #define DDLL_SMP 0 #endif +#ifndef RTLD_GLOBAL +#define RTLD_GLOBAL 0x00100 +#endif Can you please re-fetch ? Thanks, -- Olivier From fredrik@REDACTED Wed Mar 20 18:12:29 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 20 Mar 2013 18:12:29 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> Message-ID: <5149EDFD.8040909@erlang.org> On 03/20/2013 06:09 PM, Olivier Girondel wrote: > On Wed, Mar 20, 2013 at 6:01 PM, Fredrik wrote: >> Does not seem to build on windows: >> >> beam/erl_bif_ddll.c(1534) : error C2065: 'RTLD_GLOBAL' : undeclared >> identifier > I just pushed this: > > commit bdd0017f087a42f328f77debfb658ab0a0b2bc00 > Author: Olivier Girondel > Date: Wed Mar 20 18:06:13 2013 +0100 > > Add missing RTLD_GLOBAL definition > > diff --git a/erts/emulator/beam/erl_bif_ddll.c > b/erts/emulator/beam/erl_bif_ddll.c > index 91a083c..af8d3be 100644 > --- a/erts/emulator/beam/erl_bif_ddll.c > +++ b/erts/emulator/beam/erl_bif_ddll.c > @@ -53,6 +53,9 @@ > #define DDLL_SMP 0 > #endif > > +#ifndef RTLD_GLOBAL > +#define RTLD_GLOBAL 0x00100 > +#endif > > Can you please re-fetch ? > > Thanks, > Re-fetched. Let's see how the building and testing goes. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From lukas@REDACTED Wed Mar 20 18:42:47 2013 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 20 Mar 2013 18:42:47 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: <5149EDFD.8040909@erlang.org> References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> <5149EDFD.8040909@erlang.org> Message-ID: <5149F517.7050508@erlang.org> Hello, It is still failing to build on windows: sys/win32/erl_win32_sys_ddll.c(74) : warning C4047: 'function' : 'int' differs in levels of indirection from 'void **' sys/win32/erl_win32_sys_ddll.c(74) : warning C4024: 'erts_sys_ddll_open_noext' : different types for formal and actual parameter 2 sys/win32/erl_win32_sys_ddll.c(74) : warning C4047: 'function' : 'void **' differs in levels of indirection from 'ErtsSysDdllError *' sys/win32/erl_win32_sys_ddll.c(74) : warning C4022: 'erts_sys_ddll_open_noext' : pointer mismatch for actual parameter 3 sys/win32/erl_win32_sys_ddll.c(74) : error C2198: 'erts_sys_ddll_open_noext' : too few arguments for call sys/win32/erl_win32_sys_ddll.c(77) : warning C4028: formal parameter 2 different from declaration sys/win32/erl_win32_sys_ddll.c(77) : warning C4028: formal parameter 3 different from declaration sys/win32/erl_win32_sys_ddll.c(77) : warning C4029: declared formal parameter list different from definition make[3]: *** [obj/win32/opt/smp/erl_win32_sys_ddll.o] Error 2 Lukas On 20/03/13 18:12, Fredrik wrote: > On 03/20/2013 06:09 PM, Olivier Girondel wrote: >> On Wed, Mar 20, 2013 at 6:01 PM, Fredrik wrote: >>> Does not seem to build on windows: >>> >>> beam/erl_bif_ddll.c(1534) : error C2065: 'RTLD_GLOBAL' : undeclared >>> identifier >> I just pushed this: >> >> commit bdd0017f087a42f328f77debfb658ab0a0b2bc00 >> Author: Olivier Girondel >> Date: Wed Mar 20 18:06:13 2013 +0100 >> >> Add missing RTLD_GLOBAL definition >> >> diff --git a/erts/emulator/beam/erl_bif_ddll.c >> b/erts/emulator/beam/erl_bif_ddll.c >> index 91a083c..af8d3be 100644 >> --- a/erts/emulator/beam/erl_bif_ddll.c >> +++ b/erts/emulator/beam/erl_bif_ddll.c >> @@ -53,6 +53,9 @@ >> #define DDLL_SMP 0 >> #endif >> >> +#ifndef RTLD_GLOBAL >> +#define RTLD_GLOBAL 0x00100 >> +#endif >> >> Can you please re-fetch ? >> >> Thanks, >> > Re-fetched. Let's see how the building and testing goes. > Thanks, > From olivier.girondel@REDACTED Wed Mar 20 18:50:09 2013 From: olivier.girondel@REDACTED (Olivier Girondel) Date: Wed, 20 Mar 2013 18:50:09 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: <5149F517.7050508@erlang.org> References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> <5149EDFD.8040909@erlang.org> <5149F517.7050508@erlang.org> Message-ID: On Wed, Mar 20, 2013 at 6:42 PM, Lukas Larsson wrote: > Hello, > > It is still failing to build on windows: > > sys/win32/erl_win32_sys_ddll.c(74) : warning C4047: 'function' : 'int' > differs in levels of indirection from 'void **' > sys/win32/erl_win32_sys_ddll.c(74) : warning C4024: > 'erts_sys_ddll_open_noext' : different types for formal and actual parameter > 2 > sys/win32/erl_win32_sys_ddll.c(74) : warning C4047: 'function' : 'void **' > differs in levels of indirection from 'ErtsSysDdllError *' > sys/win32/erl_win32_sys_ddll.c(74) : warning C4022: > 'erts_sys_ddll_open_noext' : pointer mismatch for actual parameter 3 > sys/win32/erl_win32_sys_ddll.c(74) : error C2198: 'erts_sys_ddll_open_noext' > : too few arguments for call > sys/win32/erl_win32_sys_ddll.c(77) : warning C4028: formal parameter 2 > different from declaration > sys/win32/erl_win32_sys_ddll.c(77) : warning C4028: formal parameter 3 > different from declaration > sys/win32/erl_win32_sys_ddll.c(77) : warning C4029: declared formal > parameter list different from definition > make[3]: *** [obj/win32/opt/smp/erl_win32_sys_ddll.o] Error 2 Hi, Just pushed 698a3c1eabb79a5427c36e24e856400e6d8799fd on the same branch, please re-fetch Thanks, -- Olivier From vkuznet@REDACTED Thu Mar 21 01:27:55 2013 From: vkuznet@REDACTED (Valentin Kuznetsov) Date: Wed, 20 Mar 2013 20:27:55 -0400 Subject: [erlang-patches] Fix ssl connection issue using proxy certificate (certificate chain file) In-Reply-To: <5149886A.4050701@erlang.org> References: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> <51497EE2.9090500@erlang.org> <5149886A.4050701@erlang.org> Message-ID: Hi Fredrik, yes, you're right, the T variable can be replaced with unbounded one. I did local build and test it, it works fine. Regarding your questions. My understanding that former is related to later. According to the following docs [1,2] the proxy file contains PEM-certificate which is followed by PEM-encoded private key and other certificates. And ssl_certificate:file_to_certificats will incorrectly extract owner certificate. [1] http://dev.globus.org/wiki/Security/ProxyCertTypes [2] http://dev.globus.org/wiki/Security/ProxyFileFormat So, as you requested, I made a patch against current maint branch. Please take git fetch git://github.com/vkuznet/otp.git ssl_connection4chain_certificate2 https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate2 https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate2.patch Regards, Valentin. P.S. I'm new to erlang patch procedure and hopefully I did everything right with patches. On Mar 20, 2013, at ,Mar 20, 5:59 AM, Fredrik wrote: > On 03/20/2013 10:18 AM, Fredrik wrote: >> On 03/16/2013 03:43 PM, Valentin Kuznetsov wrote: >>> Hi, >>> physicists working in CERN experiments relies on usage of proxy certificates, i.e. certificate chain file. Those are obtained via grid-proxy-init, voms-proxy-init and can be stored to proxy server. >>> >>> We found that default ssl module partially parses such files and therefore fails to authenticate clients with servers accepting proxy certificates. Provided patch fixes this issue (thanks to Diego da Silva Gomes), please include: >>> >>> git fetch git://github.com/vkuznet/otp.git ssl_connection4chain_certificate >>> >>> https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate >>> https://github.com/vkuznet/otp/compare/maint...ssl_connection4chain_certificate.patch >>> >>> To verify the change you need to have a server which accepts proxy certificate and configure your client with your proxy certificate as following: >>> >>> %% generate user proxy file by using grid-proxy-init >>> %% produced /tmp/x509up_u proxy file contains user private key, certificate and cacertificate >>> %% configure your client to use proxy file >>> Request={Url, Headers}, >>> ProxyCert = "/tmp/x509up_u502", >>> HTTPOptions = [{ssl, [{keyfile, ProxyCert}, {certfile, ProxyCert}, {cacertfile, ProxyCert}]}] >>> httpc:request(get, Request, HTTPOptions, []) >>> >>> Thanks, >>> Valentin. >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> Hello, could you please rebase this patch upon current maint branch instead? >> > Except the rebaseing, you could make some changes to your patch. This T variable you are initiating is not used and we think it should be an unbound variable (_) instead. Could you also add a explanation why this is the way to go to handle this. Does this proxy concept guarantee that the first certificate is the 'own certificate' ? > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From fredrik@REDACTED Thu Mar 21 09:27:28 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 21 Mar 2013 09:27:28 +0100 Subject: [erlang-patches] Fix ssl connection issue using proxy certificate (certificate chain file) In-Reply-To: References: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> <51497EE2.9090500@erlang.org> <5149886A.4050701@erlang.org> Message-ID: <514AC470.3040304@erlang.org> On 03/21/2013 01:27 AM, Valentin Kuznetsov wrote: > git fetch git://github.com/vkuznet/otp.git ssl_connection4chain_certificate2 Hello again, That's not maint you have rebased against, it's master. :) -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Thu Mar 21 10:33:58 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 21 Mar 2013 10:33:58 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> <3CE981B6-9BF9-4B1F-9FA7-837635711676@gmail.com> Message-ID: <866CF412-87BB-4C0E-BBBE-0F6A7EBDDF0F@gmail.com> Maybe, but still if we want diagnostics we need to properly track macro expansions. Anyway, I rebased against latest maint. -- Anthony Ramine Le 20 mars 2013 ? 16:09, Vlad Dumitrescu a ?crit : > That's another can of worms... I think we should join the movement for liberation from the preprocessor :-) > > /Vlad > > > > On Wed, Mar 20, 2013 at 3:26 PM, Anthony Ramine wrote: > I forgot an important point: epp sitting between erl_scan and > erl_parse complicate things, as the text value of a token may > not correspond to what is actually written in the source file. > > Regards, > > -- > Anthony Ramine > > Le 20 mars 2013 ? 15:22, Anthony Ramine a ?crit : > > > It doesn't, as my patch doesn't rely on the 'text' option of > > erl_scan being set. > > > > Currently, when the compiler parses a file, it does not keep > > in memory the text values of every token. I can understand > > why you thought it's redundant if you were thinking the > > start + the length would suffice. But now you are suggesting > > I keep track of every text value to avoid having both a start > > and an end. > > > > The lexer does not need to do extra work to keep track of end > > locations, otherwise how would it know the start location of > > the next token? It already has in memory, at some point, the > > end location of each token it scans. All this patch does is > > make it available when it returns. > > > > Furthermore, let's put back this patch in the context of > > diagnostics and thus parse ranges: > > > > You are right when you say that {'+',[{line,1},{column,1},{'end',{1,2}}]} > > and {'+',[{line,1},{column,1},{length,1}]} are equivalent. > > > > Just the same, {integer,[{line,1},{column,1},{'end',{1,2}}],1} and > > {integer,[{line,1},{column,1},{length,1}],1} are also equivalent. > > > > But how can I compute the locations range of "1 + 2"? You are > > suggesting that I try to compute the length of this thing, by > > substracting the start locations of "2" and "1" and then adding > > the length of "2". That would give me the whole length of the > > {op,...,'+',...,...} node. But what about nodes that span more > > than one line? To cover these cases, you are suggesting I keep > > track of the text of the tokens. Should I compute the text of > > the whole node? What about memory usage? That would be a pain > > in the ass for huge files, like erl_parse.erl. > > > > By keeping track of the end location, I introduce nearly no > > additional overhead in the scanner, and I can keep things simple > > and constant in memory usage while computing the location ranges > > of AST nodes in the parser. > > > > I don't see how this information can be computed easily (and > > correctly) by either keeping the length or the text values, but > > feel free to prove me wrong on this. > > > > Also, feel free to tell me if I'm not clear enough, I'm enjoying > > this conversation a lot and would love to receive constructive > > feedback again. > > > > Regards, > > > > -- > > Anthony Ramine > > > > Le 20 mars 2013 ? 14:06, Vlad Dumitrescu a ?crit : > > > >> Hi, > >> > >> The multiline elements could be handled with the help of an utility that given a string and a (starting) position can compute the end position. I would hope that the implementation already has it in one form or another. > >> > >> regards, > >> Vlad > >> > >> > >> > >> On Wed, Mar 20, 2013 at 2:00 PM, Anthony Ramine wrote: > >> Hi Vlad, > >> > >> Thanks for the quick reply. > >> > >> The length of the token is defined as its length in characters. That is all > >> fine for most tokens that are on a single line, but things go to hell when > >> you take into account multiline strings, atoms and chars. > >> > >> -- > >> Anthony Ramine > >> > >> Le 20 mars 2013 ? 13:49, Vlad Dumitrescu a ?crit : > >> > >>> Hi Anthony, > >>> > >>> Don't the tokens have a start position and a length? Why do you need an explicit end position? > >>> > >>> regards, > >>> Vlad > >>> > >>> > >>> > >>> On Wed, Mar 20, 2013 at 1:44 PM, Anthony Ramine wrote: > >>> Hi, > >>> > >>> Replying on list because I think it's important. > >>> > >>> As I said to someone I don't remember the name, this patch is only a > >>> necessary step to what my final goal is: Clang-like diagnostics for > >>> Erlang compilation [1]. Is that something the OTP team wouldn't like > >>> to see? > >>> > >>> How is the end location in tokens redundant? I need the end locations > >>> of each tokens to be able to compute the location ranges of each node > >>> in the AST, see my work-in-progress commit for more informations [2]. > >>> > >>> That being said, I am interested in having your feedback about the > >>> implementation. > >>> > >>> Regards, > >>> > >>> [1] http://clang.llvm.org/diagnostics.html > >>> [2] https://github.com/nox/otp/commit/2c8038c#diff-1 > >>> > >>> PS: Sorry Hans for replying twice, I failed the Cc header. > >>> > >>> -- > >>> Anthony Ramine > >>> > >>> Le 20 mars 2013 ? 13:23, Hans Bolinder a ?crit : > >>> > >>>> Hi Anthony, > >>>> > >>>> Sorry for not replying sooner. > >>>> > >>>> We'll most likely reject you patch. I asked Vlad Dumitrescu about it, > >>>> and he agrees with me that the functionality (the end location of > >>>> tokens) is redundant. > >>>> > >>>> Apart from that: when it comes to the implementation there are a few > >>>> things I don't approve of, but I need to take a closer look before > >>>> saying anything more. You've put in a good effort here, and I intend > >>>> to elaborate a little more on the implementation when I find the time > >>>> to investigate in more detail. > >>>> > >>>> Best regards, > >>>> > >>>> Hans Bolinder, Erlang/OTP team, Ericsson > >>> > >>> _______________________________________________ > >>> erlang-patches mailing list > >>> erlang-patches@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-patches > >>> > >> > >> > > > > From aschultz@REDACTED Thu Mar 21 11:42:20 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Thu, 21 Mar 2013 11:42:20 +0100 (CET) Subject: [erlang-patches] new version elliptic curve support In-Reply-To: <514ADDC0.6030407@erix.ericsson.se> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <514056A9.4090605@erix.ericsson.se> <480623580.577114.1363199521282.JavaMail.root@tpip.net> <514190AD.3070900@erix.ericsson.se> <605129724.604878.1363601453944.JavaMail.root@tpip.net> <5148440E.2030200@erix.ericsson.se> <1436734734.657657.1363692292221.JavaMail.root@tpip.net> <514ADDC0.6030407@erix.ericsson.se> Message-ID: <1114260090.733781.1363862540226.JavaMail.root@tpip.net> Hi Ingela, ----- Original Message ----- > Hi Andreas! > > Regarding the ciphers_dsa_signed_cert that fails on windows XP /7, > solaris and powerpc. Old openssl versions 0.9.8-r and 0.9.8-o I have > found the following > statement from openssl: > > "Support for ECC is by default disabled in the stable 0.9.8 release, and > is slated for production use with 0.9.9 " > > So I will disable ECC cipher tests for those openssl versions. I doubt that this will change anything. With the openssl cipher filter in the test suite (https://github.com/RoadRunnr/otp/commit/9ef7c20be988faceb79ec7ecdb1e44f9673a1e5d) only ciphers actually announced by openssl should be tested. 'OpenSSL 0.9.8r 8 Feb 2011' on my system does not announce any EC ciphers, so they should not be negotiated or tested in any case. Also, the way I understand RFC-4492, DSA signed certificates are not compatible with any of the EC cipher suites, only RSA or ECDSA signed certificates are permitted, so the DSA test should not event attempt to use EC. I suspect the problem comes from either the changed certificate filtering permitting a cipher suite that it shouldn't or the test suite attempts to use a EC cipher suite with DSA certificates. However, I don't have an idea why this should only happen on this particular openssl version. The logs from the test suite do not offer much information on why the test was actually aborted. The logged timeout is merely a result of the real problem. So I was thinking about amending the test case with a bit more diagnostic output, like cipher suite currently tested and also the real abort message from the other party. > We are still having some strange problems on a windows 7 machine, > handshakes are working but data from openssls s_client and s_server > never arrives, it seems likely it > is some kind of environmental problem and I will continue looking into that. I could try to reproduce that, is there anything to this particular system that differs from the instructions on: http://www.erlang.org/doc/installation_guide/INSTALL-WIN32.html Andreas > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > > > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------ managed broadband access ------------------ Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: HRB21276 Handelsregistergericht Chemnitz Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From vladdu55@REDACTED Thu Mar 21 12:20:32 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 21 Mar 2013 12:20:32 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: <866CF412-87BB-4C0E-BBBE-0F6A7EBDDF0F@gmail.com> References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> <3CE981B6-9BF9-4B1F-9FA7-837635711676@gmail.com> <866CF412-87BB-4C0E-BBBE-0F6A7EBDDF0F@gmail.com> Message-ID: On Thu, Mar 21, 2013 at 10:33 AM, Anthony Ramine wrote: > Maybe, but still if we want diagnostics we need to properly track > macro expansions. > See, it actually helps checking the code :-) Why didn't you mention that there is a new token attribute, "file"? Suddenly all makes more sense :-) But there is something missing (or maybe it is in the pipeline) -- the really useful part would be if the tokens produced by expanding a macro would point to the file defining it, right? On the other hand, I would sometimes want to have the tokens for the non-preprocessed source (for use by the editor) and it would be extra nice if these could be produced by a single scanning. Maybe we could have special tokens for that, that are treated by other tools as whitespace? In this case, the 'end' position is crucial to have because the special macro tokens will overlap with their expansion. Maybe this is a discussion better taken in a separate thread, on erlang-questions? regards, /Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Mar 21 12:42:16 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 21 Mar 2013 12:42:16 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> <3CE981B6-9BF9-4B1F-9FA7-837635711676@gmail.com> <866CF412-87BB-4C0E-BBBE-0F6A7EBDDF0F@gmail.com> Message-ID: <3A8F832A-4B38-4270-9481-370F706D332A@gmail.com> I created the 'file' attribute because erl_lint and its friends used to zip the file and line number together in a tuple, breaking the assumption that if the location is a tuple, it is a pair of line and column numbers, that also doest not respect the AST documentation from absform.xml. The two first commits are also in the compile-column-numbers branch (the 'file' thing and a bugfix). I should have made it clear in the initial mail, but I did write that in my commit messages :) Regarding diagnostics and macro tracking more generally, this should be done in step: first, a token/AST node range (its begin and end locations) coming from a macro expansion should reflect what is written in the source file. For example, if I write in foo.erl ?MODULE at line 1 and column 10, I want the resulting atom 'foo' to begin at line 1 and column 10 and end at line 1 and column 17, not column 13; second, for non-builtin macros (e.g. not ?MODULE), a new attribute 'from' should be created, of type {'from',[{File::string(),Start::location(),End::location()}]}. We don't actually need special tokens. In the end, that is not related to the topic at hand, which is to teach erl_scan to return end locations. The one thing we should discuss right now is whether this patch should be included separately right now, or should I come back when I've finished teaching erl_parse to return locations range, epp to track macro expansions and compile to actually use all these informations to spit out related source code in the shell when compilation fails. Regards, -- Anthony Ramine Le 21 mars 2013 ? 12:20, Vlad Dumitrescu a ?crit : > > On Thu, Mar 21, 2013 at 10:33 AM, Anthony Ramine wrote: > Maybe, but still if we want diagnostics we need to properly track > macro expansions. > > See, it actually helps checking the code :-) Why didn't you mention that there is a new token attribute, "file"? Suddenly all makes more sense :-) > > But there is something missing (or maybe it is in the pipeline) -- the really useful part would be if the tokens produced by expanding a macro would point to the file defining it, right? > > On the other hand, I would sometimes want to have the tokens for the non-preprocessed source (for use by the editor) and it would be extra nice if these could be produced by a single scanning. Maybe we could have special tokens for that, that are treated by other tools as whitespace? In this case, the 'end' position is crucial to have because the special macro tokens will overlap with their expansion. > > Maybe this is a discussion better taken in a separate thread, on erlang-questions? > > regards, > /Vlad From vladdu55@REDACTED Thu Mar 21 13:06:47 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 21 Mar 2013 13:06:47 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: <3A8F832A-4B38-4270-9481-370F706D332A@gmail.com> References: <20809.43582.542254.99152@ornendil.otp.ericsson.se> <233AEBF7-3344-4C1B-BA9E-2DFBCD7FAB16@gmail.com> <3CE981B6-9BF9-4B1F-9FA7-837635711676@gmail.com> <866CF412-87BB-4C0E-BBBE-0F6A7EBDDF0F@gmail.com> <3A8F832A-4B38-4270-9481-370F706D332A@gmail.com> Message-ID: My opinion is that if the patch is independent, it could be just as well be included now (if accepted) -- the longer it is in pu, the more chances are to catch problems with it. Regarding the other issue, > For example, if I write in foo.erl ?MODULE at line > 1 and column 10, I want the resulting atom 'foo' to begin at line 1 and > column 10 and end at line 1 and column 17, not column 13; second, > for non-builtin macros (e.g. not ?MODULE), a new attribute 'from' should > be created, of type {'from',[{File::string(),Start::location(),End:: location()}]}. How would you handle macros with arguments that expand to complex expressions? It's not as easy to fake the ending or use 'from'. regards, Vlad On Thu, Mar 21, 2013 at 12:42 PM, Anthony Ramine wrote: > I created the 'file' attribute because erl_lint and its friends > used to zip the file and line number together in a tuple, breaking > the assumption that if the location is a tuple, it is a pair of > line and column numbers, that also doest not respect the AST > documentation from absform.xml. The two first commits are also > in the compile-column-numbers branch (the 'file' thing and a > bugfix). > > I should have made it clear in the initial mail, but I did write > that in my commit messages :) > > Regarding diagnostics and macro tracking more generally, this should > be done in step: first, a token/AST node range (its begin and end > locations) coming from a macro expansion should reflect what is written > in the source file. For example, if I write in foo.erl ?MODULE at line > 1 and column 10, I want the resulting atom 'foo' to begin at line 1 and > column 10 and end at line 1 and column 17, not column 13; second, > for non-builtin macros (e.g. not ?MODULE), a new attribute 'from' should > be created, of type > {'from',[{File::string(),Start::location(),End::location()}]}. > We don't actually need special tokens. > > In the end, that is not related to the topic at hand, which is > to teach erl_scan to return end locations. > > The one thing we should discuss right now is whether this patch should > be included separately right now, or should I come back when I've > finished teaching erl_parse to return locations range, epp to track macro > expansions and compile to actually use all these informations to spit > out related source code in the shell when compilation fails. > > Regards, > > -- > Anthony Ramine > > Le 21 mars 2013 ? 12:20, Vlad Dumitrescu a ?crit : > > > > > On Thu, Mar 21, 2013 at 10:33 AM, Anthony Ramine > wrote: > > Maybe, but still if we want diagnostics we need to properly track > > macro expansions. > > > > See, it actually helps checking the code :-) Why didn't you mention that > there is a new token attribute, "file"? Suddenly all makes more sense :-) > > > > But there is something missing (or maybe it is in the pipeline) -- the > really useful part would be if the tokens produced by expanding a macro > would point to the file defining it, right? > > > > On the other hand, I would sometimes want to have the tokens for the > non-preprocessed source (for use by the editor) and it would be extra nice > if these could be produced by a single scanning. Maybe we could have > special tokens for that, that are treated by other tools as whitespace? In > this case, the 'end' position is crucial to have because the special macro > tokens will overlap with their expansion. > > > > Maybe this is a discussion better taken in a separate thread, on > erlang-questions? > > > > regards, > > /Vlad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vkuznet@REDACTED Thu Mar 21 13:58:29 2013 From: vkuznet@REDACTED (Valentin Kuznetsov) Date: Thu, 21 Mar 2013 08:58:29 -0400 Subject: [erlang-patches] Fix ssl connection issue using proxy certificate (certificate chain file) In-Reply-To: <514AC470.3040304@erlang.org> References: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> <51497EE2.9090500@erlang.org> <5149886A.4050701@erlang.org> <514AC470.3040304@erlang.org> Message-ID: <62ACA786-E976-4840-81E9-F3AC5FFF0257@gmail.com> Hi, sorry about that, please take git fetch git://github.com/vkuznet/otp.git fix_ssl_connection https://github.com/vkuznet/otp/compare/maint...fix_ssl_connection https://github.com/vkuznet/otp/compare/maint...fix_ssl_connection.patch Valentin. On Mar 21, 2013, at ,Mar 21, 4:27 AM, Fredrik wrote: > On 03/21/2013 01:27 AM, Valentin Kuznetsov wrote: >> git fetch git://github.com/vkuznet/otp.git ssl_connection4chain_certificate2 > Hello again, > That's not maint you have rebased against, it's master. :) > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From fredrik@REDACTED Thu Mar 21 14:11:55 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 21 Mar 2013 14:11:55 +0100 Subject: [erlang-patches] Fix ssl connection issue using proxy certificate (certificate chain file) In-Reply-To: <62ACA786-E976-4840-81E9-F3AC5FFF0257@gmail.com> References: <4E003237-AF19-43DB-B1C0-F570C12F364C@gmail.com> <51497EE2.9090500@erlang.org> <5149886A.4050701@erlang.org> <514AC470.3040304@erlang.org> <62ACA786-E976-4840-81E9-F3AC5FFF0257@gmail.com> Message-ID: <514B071B.6090101@erlang.org> On 03/21/2013 01:58 PM, Valentin Kuznetsov wrote: > git fetch git://github.com/vkuznet/otp.git fix_ssl_connection Re-fetched. Thanks -- BR Fredrik Gustafsson Erlang OTP Team From aschultz@REDACTED Thu Mar 21 18:17:17 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Thu, 21 Mar 2013 18:17:17 +0100 (CET) Subject: [erlang-patches] new version elliptic curve support In-Reply-To: <514AEB57.8090103@erix.ericsson.se> References: <1039035650.125721.1361450903354.JavaMail.root@tpip.net> <514190AD.3070900@erix.ericsson.se> <605129724.604878.1363601453944.JavaMail.root@tpip.net> <5148440E.2030200@erix.ericsson.se> <1436734734.657657.1363692292221.JavaMail.root@tpip.net> <514ADDC0.6030407@erix.ericsson.se> <1114260090.733781.1363862540226.JavaMail.root@tpip.net> <514AEB57.8090103@erix.ericsson.se> Message-ID: <350926041.752900.1363886237129.JavaMail.root@tpip.net> Hi, ----- Original Message ----- > Hi! > > Andreas Schultz wrote: > > Hi Ingela, > > > > ----- Original Message ----- > > > >> Hi Andreas! > >> > >> Regarding the ciphers_dsa_signed_cert that fails on windows XP /7, > >> solaris and powerpc. Old openssl versions 0.9.8-r and 0.9.8-o I have > >> found the following > >> statement from openssl: > >> > >> "Support for ECC is by default disabled in the stable 0.9.8 release, and > >> is slated for production use with 0.9.9 " > >> > >> So I will disable ECC cipher tests for those openssl versions. > >> > > > > I doubt that this will change anything. > > > > With the openssl cipher filter in the test suite > > (https://github.com/RoadRunnr/otp/commit/9ef7c20be988faceb79ec7ecdb1e44f9673a1e5d) > > only ciphers actually announced by openssl should be tested. > > 'OpenSSL 0.9.8r 8 Feb 2011' on my system does not announce any EC ciphers, > > so they should not be negotiated or tested in any case. > > > > > The test case will offer only one cipher suite at the time and it is the > suite {ecdhe_rsa,aes_256_cbc,sha} that > causes the failiur, see also below. > > > Also, the way I understand RFC-4492, DSA signed certificates are not > > compatible > > with any of the EC cipher suites, only RSA or ECDSA signed certificates > > are permitted, so the DSA test should not event attempt to use EC. > > > only the ciphers_rsa_signed is failing on other machins than the windows > 7 machine. > > > The logs from the test suite do not offer much information on why the > > test was actually aborted. The logged timeout is merely a result of the > > real problem. So I was thinking about amending the test case with a bit > > more diagnostic output, like cipher suite currently tested and also the > > real abort message from the other party. > > > > > Yes I changed ct:print to ct:log now the log says: > > **** User 2013-03-21 08:38:57.494 **** Testing CipherSuite > {ecdhe_rsa,aes_256_cbc,sha} uhm, OpenSSL 0.9.8-r should not support ECDHE, the openssl cipher filter from https://github.com/RoadRunnr/otp/commit/9ef7c20be988faceb79ec7ecdb1e44f9673a1e5d should have prevented this cipher suite being tried in the test. could you check 'openssl ciphers' on the systems where this test is failing? A default 0.9.8r should have: # ./openssl ciphers DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:IDEA-CBC-SHA:IDEA-CBC-MD5:RC2-CBC-MD5:RC4-SHA:RC4-MD5:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC4-MD5 Andreas -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------ managed broadband access ------------------ Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: HRB21276 Handelsregistergericht Chemnitz Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From fredrik@REDACTED Fri Mar 22 09:46:28 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 22 Mar 2013 09:46:28 +0100 Subject: [erlang-patches] Relax reltools requirements on excluded applications In-Reply-To: References: <514840BF.3070600@erlang.org> Message-ID: <514C1A64.906@erlang.org> On 03/19/2013 12:48 PM, H?kan Mattsson wrote: > On Tue, Mar 19, 2013 at 11:41 AM, Fredrik wrote: >> On 03/19/2013 09:38 AM, H?kan Mattsson wrote: >>> When generating cross compiled systems it is rather inconvenient that >>> reltool requires that even excluded applications are part of the >>> configuration. The symptom of this is an error claiming that the >>> application directory is missing. >>> >>> With this patch, a missing a application directory is now classified >>> as warning if the application is explicitly excluded. >>> >>> git fetch git://github.com/hawk/otp.git hawk/reltool_relaxed_exclude >>> >>> or viewed here >>> >>> https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude >>> https://github.com/hawk/otp/compare/hawk/reltool_relaxed_exclude.patch >>> >>> /H?kan >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> Hello, >> Your patch seems not to build, >> >> reltool_server_SUITE.erl:1352:33: variable 'Config' is unbound > Sorry. I did a last minute change in the test program. > Please, refetch. > > /H?kan Hello again, Your patch seems to fail a testcase: reltool_server_SUITE, exclude_non_existing_app with reason: reltool_server_SUITE.erl(1371): SPEC: {error, "Illegal library \"*DIRECTORY*": no such file or directory"} reltool_server_SUITE.erl(1372): Not matching actual result was: {error,"Illegal library \"*DIRECTORY*": no such file or directory"} Expected: {ok,["foobar: Missing application directory."]} -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Fri Mar 22 11:09:11 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 22 Mar 2013 11:09:11 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> <5149EDFD.8040909@erlang.org> <5149F517.7050508@erlang.org> Message-ID: <514C2DC7.40208@erlang.org> On 03/20/2013 06:50 PM, Olivier Girondel wrote: > On Wed, Mar 20, 2013 at 6:42 PM, Lukas Larsson wrote: >> Hello, >> >> It is still failing to build on windows: >> >> sys/win32/erl_win32_sys_ddll.c(74) : warning C4047: 'function' : 'int' >> differs in levels of indirection from 'void **' >> sys/win32/erl_win32_sys_ddll.c(74) : warning C4024: >> 'erts_sys_ddll_open_noext' : different types for formal and actual parameter >> 2 >> sys/win32/erl_win32_sys_ddll.c(74) : warning C4047: 'function' : 'void **' >> differs in levels of indirection from 'ErtsSysDdllError *' >> sys/win32/erl_win32_sys_ddll.c(74) : warning C4022: >> 'erts_sys_ddll_open_noext' : pointer mismatch for actual parameter 3 >> sys/win32/erl_win32_sys_ddll.c(74) : error C2198: 'erts_sys_ddll_open_noext' >> : too few arguments for call >> sys/win32/erl_win32_sys_ddll.c(77) : warning C4028: formal parameter 2 >> different from declaration >> sys/win32/erl_win32_sys_ddll.c(77) : warning C4028: formal parameter 3 >> different from declaration >> sys/win32/erl_win32_sys_ddll.c(77) : warning C4029: declared formal >> parameter list different from definition >> make[3]: *** [obj/win32/opt/smp/erl_win32_sys_ddll.o] Error 2 > Hi, > > Just pushed 698a3c1eabb79a5427c36e24e856400e6d8799fd > on the same branch, please re-fetch > > Thanks, > Hello, Your patch seems not to build on Arch: x86, OS: darwin 9.8.0 beam/beam_debug.c: In function 'erts_debug_breakpoint_2': beam/beam_debug.c:81: error: two or more data types in declaration specifiers beam/beam_debug.c:81: error: syntax error before '=' token beam/beam_debug.c:89: error: syntax error before '_Bool' beam/beam_debug.c:126: error: syntax error before '_Bool' beam/beam_debug.c:93: error: label 'error' used but not defined beam/beam_debug.c:86: warning: unused variable 'res' beam/beam_debug.c: At top level: beam/beam_debug.c:130: error: syntax error before 'else' beam/beam_debug.c:132: warning: type defaults to 'int' in declaration of 'erts_commit_staged_bp' beam/beam_debug.c:132: warning: function declaration isn't a prototype beam/beam_debug.c:132: error: conflicting types for 'erts_commit_staged_bp' beam/beam_bp.h:116: error: previous declaration of 'erts_commit_staged_bp' was here beam/beam_debug.c:132: warning: data definition has no type or storage class beam/beam_debug.c:133: error: syntax error before '&' token beam/beam_debug.c:133: warning: type defaults to 'int' in declaration of 'erts_uninstall_breakpoints' beam/beam_debug.c:133: warning: function declaration isn't a prototype beam/beam_debug.c:133: error: conflicting types for 'erts_uninstall_breakpoints' beam/beam_bp.h:126: error: previous declaration of 'erts_uninstall_breakpoints' was here beam/beam_debug.c:133: warning: data definition has no type or storage class beam/beam_debug.c:135: error: syntax error before '&' token beam/beam_debug.c:135: warning: type defaults to 'int' in declaration of 'erts_consolidate_bp_data' beam/beam_debug.c:135: warning: function declaration isn't a prototype beam/beam_debug.c:135: error: conflicting types for 'erts_consolidate_bp_data' beam/beam_bp.h:127: error: previous declaration of 'erts_consolidate_bp_data' was here beam/beam_debug.c:135: warning: data definition has no type or storage class beam/beam_debug.c:136: warning: type defaults to 'int' in declaration of 'res' beam/beam_debug.c:136: error: 'f' undeclared here (not in a function) beam/beam_debug.c:136: warning: data definition has no type or storage class beam/beam_debug.c:137: error: syntax error before '&' token beam/beam_debug.c:137: warning: type defaults to 'int' in declaration of 'erts_bp_free_matched_functions' beam/beam_debug.c:137: warning: function declaration isn't a prototype beam/beam_debug.c:137: error: conflicting types for 'erts_bp_free_matched_functions' beam/beam_bp.h:123: error: previous declaration of 'erts_bp_free_matched_functions' was here beam/beam_debug.c:137: warning: data definition has no type or storage class beam/beam_debug.c:139: warning: type defaults to 'int' in declaration of 'erts_thr_progress_unblock' beam/beam_debug.c:139: warning: function declaration isn't a prototype beam/beam_debug.c:132: warning: type defaults to 'int' in declaration of 'erts_commit_staged_bp' beam/beam_debug.c:132: warning: function declaration isn't a prototype beam/beam_debug.c:132: error: conflicting types for 'erts_commit_staged_bp' beam/beam_bp.h:116: error: previous declaration of 'erts_commit_staged_bp' was here beam/beam_debug.c:132: warning: data definition has no type or storage class beam/beam_debug.c:133: error: syntax error before '&' token beam/beam_debug.c:133: warning: type defaults to 'int' in declaration of 'erts_uninstall_breakpoints' beam/beam_debug.c:133: warning: function declaration isn't a prototype beam/beam_debug.c:141: warning: data definition has no type or storage class beam/beam_debug.c:142: error: syntax error before 'return' beam/beam_debug.c: In function 'erts_debug_breakpoint_2': beam/beam_debug.c:81: error: two or more data types in declaration specifiers beam/beam_debug.c:81: error: syntax error before '=' token beam/beam_debug.c:89: error: syntax error before '_Bool' beam/beam_debug.c:126: error: syntax error before '_Bool' beam/beam_debug.c:93: error: label 'error' used but not defined beam/beam_debug.c:86: warning: unused variable 'res' beam/beam_debug.c: At top level: beam/beam_debug.c:130: error: syntax error before 'else' beam/beam_debug.c:132: warning: type defaults to 'int' in declaration of 'erts_commit_staged_bp' beam/beam_debug.c:132: warning: function declaration isn't a prototype beam/beam_debug.c:132: error: conflicting types for 'erts_commit_staged_bp' beam/beam_bp.h:116: error: previous declaration of 'erts_commit_staged_bp' was here beam/beam_debug.c:132: warning: data definition has no type or storage class beam/beam_debug.c:133: error: syntax error before '&' token beam/beam_debug.c:133: warning: type defaults to 'int' in declaration of 'erts_uninstall_breakpoints' beam/beam_debug.c:133: warning: function declaration isn't a prototype beam/beam_debug.c:133: error: conflicting types for 'erts_uninstall_breakpoints' beam/beam_bp.h:126: error: previous declaration of 'erts_uninstall_breakpoints' was here beam/beam_debug.c:133: warning: data definition has no type or storage class beam/beam_debug.c:135: error: syntax error before '&' token beam/beam_debug.c:135: warning: type defaults to 'int' in declaration of 'erts_consolidate_bp_data' beam/beam_debug.c:135: warning: function declaration isn't a prototype beam/beam_debug.c:135: error: conflicting types for 'erts_consolidate_bp_data' beam/beam_bp.h:127: error: previous declaration of 'erts_consolidate_bp_data' was here beam/beam_debug.c:135: warning: data definition has no type or storage class beam/beam_debug.c:136: warning: type defaults to 'int' in declaration of 'res' beam/beam_debug.c:136: error: 'f' undeclared here (not in a function) beam/beam_debug.c:136: warning: data definition has no type or storage class beam/beam_debug.c:137: error: syntax error before '&' token beam/beam_debug.c:137: warning: type defaults to 'int' in declaration of 'erts_bp_free_matched_functions' beam/beam_debug.c:137: warning: function declaration isn't a prototype beam/beam_debug.c:137: error: conflicting types for 'erts_bp_free_matched_functions' beam/beam_bp.h:123: error: previous declaration of 'erts_bp_free_matched_functions' was here beam/beam_debug.c:137: warning: data definition has no type or storage class beam/beam_debug.c:139: warning: type defaults to 'int' in declaration of 'erts_thr_progress_unblock' beam/beam_debug.c:139: warning: function declaration isn't a prototype beam/beam_debug.c:139: error: conflicting types for 'erts_thr_progress_unblock' beam/erl_thr_progress.h:48: error: previous declaration of 'erts_thr_progress_unblock' was here beam/beam_debug.c:139: warning: data definition has no type or storage class beam/beam_debug.c:140: error: syntax error before '(' token beam/beam_debug.c:141: warning: type defaults to 'int' in declaration of 'erts_release_code_write_permission' beam/beam_debug.c:141: warning: function declaration isn't a prototype beam/beam_debug.c:141: error: conflicting types for 'erts_release_code_write_permission' beam/code_ix.h:95: error: previous declaration of 'erts_release_code_write_permission' was here beam/beam_debug.c:141: warning: data definition has no type or storage class beam/beam_debug.c:142: error: syntax error before 'return' lipo: can't figure out the architecture type of: /var/tmp//ccpYKJDY.out make[3]: *** [obj/i386-apple-darwin9.8.0/opt/smp/beam_debug.o] Error 1 make[2]: *** [opt] Error 2 make[1]: *** [smp] Error 2 make: *** [emulator] Error 2 -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Fri Mar 22 17:11:01 2013 From: lukas@REDACTED (Lukas Larsson) Date: Fri, 22 Mar 2013 17:11:01 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> <5149EDFD.8040909@erlang.org> <5149F517.7050508@erlang.org> <514C2DC7.40208@erlang.org> Message-ID: <514C8295.80506@erlang.org> Hello, The problem was OS X. In /usr/include/dlfcn.h (actually it was stdbool.h which was included through dlfcn.h) there is this nice bit of code: #define bool _Bool #if __STDC_VERSION__ < 199901L && __GNUC__ < 3 typedef int _Bool; #endif which effectively renamed the variable called bool in beam_debug.c to _Bool and then defined it as a type.... oh the wonders of single macro namespacing! This problem did not show up before as dlfcn.h was only included in sys_dll.c. We have renamed the variables to something else and now it seems to compile. Lukas On 22/03/13 15:57, Olivier Girondel wrote: > On Fri, Mar 22, 2013 at 11:09 AM, Fredrik wrote: >> Hello, >> Your patch seems not to build on Arch: x86, OS: darwin 9.8.0 >> >> beam/beam_debug.c: In function 'erts_debug_breakpoint_2': >> beam/beam_debug.c:81: error: two or more data types in declaration >> specifiers >> beam/beam_debug.c:81: error: syntax error before '=' token >> beam/beam_debug.c:89: error: syntax error before '_Bool' >> beam/beam_debug.c:126: error: syntax error before '_Bool' > Hi Fredrik & Lukas, > > This is kind of strange, given I have not modified those files and they are > not generated > > For example, I can't figure out why > > https://github.com/erlang/otp/blob/pu/erts/emulator/beam/beam_debug.c#L81 > > would fail, and alas I don't have a Darwin handy, so I can't help now... > >> beam/beam_debug.c:93: error: label 'error' used but not defined >> beam/beam_debug.c:86: warning: unused variable 'res' >> beam/beam_debug.c: At top level: >> beam/beam_debug.c:130: error: syntax error before 'else' >> beam/beam_debug.c:132: warning: type defaults to 'int' in declaration of >> 'erts_commit_staged_bp' >> beam/beam_debug.c:132: warning: function declaration isn't a prototype >> beam/beam_debug.c:132: error: conflicting types for 'erts_commit_staged_bp' >> beam/beam_bp.h:116: error: previous declaration of 'erts_commit_staged_bp' >> was here >> beam/beam_debug.c:132: warning: data definition has no type or storage class >> beam/beam_debug.c:133: error: syntax error before '&' token >> beam/beam_debug.c:133: warning: type defaults to 'int' in declaration of >> 'erts_uninstall_breakpoints' >> beam/beam_debug.c:133: warning: function declaration isn't a prototype >> beam/beam_debug.c:133: error: conflicting types for >> 'erts_uninstall_breakpoints' >> beam/beam_bp.h:126: error: previous declaration of >> 'erts_uninstall_breakpoints' was here >> beam/beam_debug.c:133: warning: data definition has no type or storage class >> beam/beam_debug.c:135: error: syntax error before '&' token >> beam/beam_debug.c:135: warning: type defaults to 'int' in declaration of >> 'erts_consolidate_bp_data' >> beam/beam_debug.c:135: warning: function declaration isn't a prototype >> beam/beam_debug.c:135: error: conflicting types for >> 'erts_consolidate_bp_data' >> beam/beam_bp.h:127: error: previous declaration of >> 'erts_consolidate_bp_data' was here >> beam/beam_debug.c:135: warning: data definition has no type or storage class >> beam/beam_debug.c:136: warning: type defaults to 'int' in declaration of >> 'res' >> beam/beam_debug.c:136: error: 'f' undeclared here (not in a function) >> beam/beam_debug.c:136: warning: data definition has no type or storage class >> beam/beam_debug.c:137: error: syntax error before '&' token >> beam/beam_debug.c:137: warning: type defaults to 'int' in declaration of >> 'erts_bp_free_matched_functions' >> beam/beam_debug.c:137: warning: function declaration isn't a prototype >> beam/beam_debug.c:137: error: conflicting types for >> 'erts_bp_free_matched_functions' >> beam/beam_bp.h:123: error: previous declaration of >> 'erts_bp_free_matched_functions' was here >> beam/beam_debug.c:137: warning: data definition has no type or storage class >> beam/beam_debug.c:139: warning: type defaults to 'int' in declaration of >> 'erts_thr_progress_unblock' >> beam/beam_debug.c:139: warning: function declaration isn't a prototype >> beam/beam_debug.c:132: warning: type defaults to 'int' in declaration of >> 'erts_commit_staged_bp' >> beam/beam_debug.c:132: warning: function declaration isn't a prototype >> beam/beam_debug.c:132: error: conflicting types for 'erts_commit_staged_bp' >> beam/beam_bp.h:116: error: previous declaration of 'erts_commit_staged_bp' >> was here >> beam/beam_debug.c:132: warning: data definition has no type or storage class >> beam/beam_debug.c:133: error: syntax error before '&' token >> beam/beam_debug.c:133: warning: type defaults to 'int' in declaration of >> 'erts_uninstall_breakpoints' >> beam/beam_debug.c:133: warning: function declaration isn't a prototype >> beam/beam_debug.c:141: warning: data definition has no type or storage class >> beam/beam_debug.c:142: error: syntax error before 'return' >> beam/beam_debug.c: In function 'erts_debug_breakpoint_2': >> beam/beam_debug.c:81: error: two or more data types in declaration >> specifiers >> beam/beam_debug.c:81: error: syntax error before '=' token >> beam/beam_debug.c:89: error: syntax error before '_Bool' >> beam/beam_debug.c:126: error: syntax error before '_Bool' >> beam/beam_debug.c:93: error: label 'error' used but not defined >> beam/beam_debug.c:86: warning: unused variable 'res' >> beam/beam_debug.c: At top level: >> beam/beam_debug.c:130: error: syntax error before 'else' >> beam/beam_debug.c:132: warning: type defaults to 'int' in declaration of >> 'erts_commit_staged_bp' >> beam/beam_debug.c:132: warning: function declaration isn't a prototype >> beam/beam_debug.c:132: error: conflicting types for 'erts_commit_staged_bp' >> beam/beam_bp.h:116: error: previous declaration of 'erts_commit_staged_bp' >> was here >> beam/beam_debug.c:132: warning: data definition has no type or storage class >> beam/beam_debug.c:133: error: syntax error before '&' token >> beam/beam_debug.c:133: warning: type defaults to 'int' in declaration of >> 'erts_uninstall_breakpoints' >> beam/beam_debug.c:133: warning: function declaration isn't a prototype >> beam/beam_debug.c:133: error: conflicting types for >> 'erts_uninstall_breakpoints' >> beam/beam_bp.h:126: error: previous declaration of >> 'erts_uninstall_breakpoints' was here >> beam/beam_debug.c:133: warning: data definition has no type or storage class >> beam/beam_debug.c:135: error: syntax error before '&' token >> beam/beam_debug.c:135: warning: type defaults to 'int' in declaration of >> 'erts_consolidate_bp_data' >> beam/beam_debug.c:135: warning: function declaration isn't a prototype >> beam/beam_debug.c:135: error: conflicting types for >> 'erts_consolidate_bp_data' >> beam/beam_bp.h:127: error: previous declaration of >> 'erts_consolidate_bp_data' was here >> beam/beam_debug.c:135: warning: data definition has no type or storage class >> beam/beam_debug.c:136: warning: type defaults to 'int' in declaration of >> 'res' >> beam/beam_debug.c:136: error: 'f' undeclared here (not in a function) >> beam/beam_debug.c:136: warning: data definition has no type or storage class >> beam/beam_debug.c:137: error: syntax error before '&' token >> beam/beam_debug.c:137: warning: type defaults to 'int' in declaration of >> 'erts_bp_free_matched_functions' >> beam/beam_debug.c:137: warning: function declaration isn't a prototype >> beam/beam_debug.c:137: error: conflicting types for >> 'erts_bp_free_matched_functions' >> beam/beam_bp.h:123: error: previous declaration of >> 'erts_bp_free_matched_functions' was here >> beam/beam_debug.c:137: warning: data definition has no type or storage class >> beam/beam_debug.c:139: warning: type defaults to 'int' in declaration of >> 'erts_thr_progress_unblock' >> beam/beam_debug.c:139: warning: function declaration isn't a prototype >> beam/beam_debug.c:139: error: conflicting types for >> 'erts_thr_progress_unblock' >> beam/erl_thr_progress.h:48: error: previous declaration of >> 'erts_thr_progress_unblock' was here > [in 'pu']: > beam/beam_debug.c:139: > erts_smp_thr_progress_unblock(); > > and > beam/erl_thr_progress.h:48: > void erts_thr_progress_unblock(void); > >> beam/beam_debug.c:139: warning: data definition has no type or storage class >> beam/beam_debug.c:140: error: syntax error before '(' token >> beam/beam_debug.c:141: warning: type defaults to 'int' in declaration of >> 'erts_release_code_write_permission' >> beam/beam_debug.c:141: warning: function declaration isn't a prototype >> beam/beam_debug.c:141: error: conflicting types for >> 'erts_release_code_write_permission' >> beam/code_ix.h:95: error: previous declaration of >> 'erts_release_code_write_permission' was here >> beam/beam_debug.c:141: warning: data definition has no type or storage class >> beam/beam_debug.c:142: error: syntax error before 'return' >> lipo: can't figure out the architecture type of: /var/tmp//ccpYKJDY.out >> make[3]: *** [obj/i386-apple-darwin9.8.0/opt/smp/beam_debug.o] Error 1 >> make[2]: *** [opt] Error 2 >> make[1]: *** [smp] Error 2 >> make: *** [emulator] Error 2 > Furthermore, looking at all these errors, I don't have a clue... > > Maybe it's simply a merge/patch/git-thing that got broken ? > From magnus@REDACTED Fri Mar 22 20:25:24 2013 From: magnus@REDACTED (Magnus Henoch) Date: Fri, 22 Mar 2013 19:25:24 +0000 Subject: [erlang-patches] Fix filename extension association when using erlang-mode as Emacs package Message-ID: I just tried installing the Emacs erlang-mode from MELPA: http://melpa.milkbox.net/ (it's being automatically built from the default branch of erlang/otp on Github, i.e. maint.) It is installable, but it doesn't automatically switch the buffer into Erlang mode when opening a *.erl file, since the definitions for that are not automatically evaluated on startup. Here is a patch that lets Emacs' package manager understand what to do. This change shouldn't affect the traditional way of installing and loading erlang-mode - the additions are magic comments that are only used during package installation. git fetch git://github.com/legoscia/otp.git emacs-package https://github.com/legoscia/otp/compare/legoscia:emacs-package https://github.com/legoscia/otp/compare/legoscia:emacs-package.patch Regards, Magnus From n.oxyde@REDACTED Sun Mar 24 18:50:51 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 24 Mar 2013 18:50:51 +0100 Subject: [erlang-patches] Fix a bug in some binary comprehensions Message-ID: <93249178-4D54-4D52-BEE9-057E13326244@gmail.com> Hi, Peer noticed a crash when compiling some binary comprehensions, I tracked it and it is related to the optimization done to use the bs_init_writable primop, more specifically the generated code used to compute the size given to it could sometimes use a variable which is bind by a generator, later in a different scope. An example of such binary comprehension is `<< <<0:S>> || S <- Slist >>`. Such bogus Core Erlang code would be detected by core_lint, but unfortunately the linting pass enabled through the +clint option is executed after the destructive setelement/3 optimization, which is the pass that crash in presence of an unbound variable. My branch fixes the initial bug and introduces a new compile option +clint0, which does the same as +clint but just before the dsetel optimization pass. git fetch https://github.com/nox/otp.git fix-bc-optim https://github.com/nox/otp/compare/erlang:maint...fix-bc-optim https://github.com/nox/otp/compare/erlang:maint...fix-bc-optim.patch Regards, -- Anthony Ramine From norton@REDACTED Mon Mar 25 06:01:17 2013 From: norton@REDACTED (=?utf-8?B?44OO44O844OI44OzIOOCuOODp+ODvOOCu+ODlSDjgqbjgqfjgqQg?= =?utf-8?B?44Oz?=) Date: Mon, 25 Mar 2013 14:01:17 +0900 Subject: [erlang-patches] Directly use the pmod_transform application as a dependency via the rebar tool Message-ID: Hello. It is helpful to directly use the pmod_transform application as a dependency via the rebar tool. This patch makes this possible. $ git fetch https://github.com/ubf/pmod_transform.git master commit eb4842e0079803187572e3dc6682f950bba183f4 Author: Joseph Wayne Norton Date: Wed Feb 20 12:27:31 2013 +0900 Add src/pmod_transform.app.src for rebar support The following repository contains instructions that demonstrate how this patch has been used for this purpose. https://github.com/ubf/ubf#quick-start-recipe Best regards, Joe N. From fredrik@REDACTED Mon Mar 25 10:06:03 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 25 Mar 2013 10:06:03 +0100 Subject: [erlang-patches] Fix filename extension association when using erlang-mode as Emacs package In-Reply-To: References: Message-ID: <5150137B.7070606@erlang.org> On 03/22/2013 08:25 PM, Magnus Henoch wrote: > I just tried installing the Emacs erlang-mode from MELPA: > > http://melpa.milkbox.net/ > > (it's being automatically built from the default branch of erlang/otp on > Github, i.e. maint.) > > It is installable, but it doesn't automatically switch the buffer into > Erlang mode when opening a *.erl file, since the definitions for that > are not automatically evaluated on startup. Here is a patch that lets > Emacs' package manager understand what to do. > > This change shouldn't affect the traditional way of installing and > loading erlang-mode - the additions are magic comments that are only > used during package installation. > > git fetch git://github.com/legoscia/otp.git emacs-package > > https://github.com/legoscia/otp/compare/legoscia:emacs-package > https://github.com/legoscia/otp/compare/legoscia:emacs-package.patch > > Regards, > Magnus > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Fetched, currently in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Mar 25 10:08:14 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 25 Mar 2013 10:08:14 +0100 Subject: [erlang-patches] Fix a bug in some binary comprehensions In-Reply-To: <93249178-4D54-4D52-BEE9-057E13326244@gmail.com> References: <93249178-4D54-4D52-BEE9-057E13326244@gmail.com> Message-ID: <515013FE.70903@erlang.org> On 03/24/2013 06:50 PM, Anthony Ramine wrote: > git fetchhttps://github.com/nox/otp.git fix-bc-optim Fetched and currently in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Mar 25 10:52:58 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 25 Mar 2013 10:52:58 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: <514C8295.80506@erlang.org> References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> <5149EDFD.8040909@erlang.org> <5149F517.7050508@erlang.org> <514C2DC7.40208@erlang.org> <514C8295.80506@erlang.org> Message-ID: <51501E7A.4070000@erlang.org> On 03/22/2013 05:11 PM, Lukas Larsson wrote: > Hello, > > The problem was OS X. In /usr/include/dlfcn.h (actually it was > stdbool.h which was included through dlfcn.h) there is this nice bit > of code: > > #define bool _Bool > #if __STDC_VERSION__ < 199901L && __GNUC__ < 3 > typedef int _Bool; > #endif > > which effectively renamed the variable called bool in beam_debug.c to > _Bool and then defined it as a type.... oh the wonders of single macro > namespacing! This problem did not show up before as dlfcn.h was only > included in sys_dll.c. > > We have renamed the variables to something else and now it seems to > compile. > > Lukas > > On 22/03/13 15:57, Olivier Girondel wrote: >> On Fri, Mar 22, 2013 at 11:09 AM, Fredrik wrote: >>> Hello, >>> Your patch seems not to build on Arch: x86, OS: darwin 9.8.0 >>> >>> beam/beam_debug.c: In function 'erts_debug_breakpoint_2': >>> beam/beam_debug.c:81: error: two or more data types in declaration >>> specifiers >>> beam/beam_debug.c:81: error: syntax error before '=' token >>> beam/beam_debug.c:89: error: syntax error before '_Bool' >>> beam/beam_debug.c:126: error: syntax error before '_Bool' >> Hi Fredrik & Lukas, >> >> This is kind of strange, given I have not modified those files and >> they are >> not generated >> >> For example, I can't figure out why >> >> https://github.com/erlang/otp/blob/pu/erts/emulator/beam/beam_debug.c#L81 >> >> >> would fail, and alas I don't have a Darwin handy, so I can't help now... >> >>> beam/beam_debug.c:93: error: label 'error' used but not defined >>> beam/beam_debug.c:86: warning: unused variable 'res' >>> beam/beam_debug.c: At top level: >>> beam/beam_debug.c:130: error: syntax error before 'else' >>> beam/beam_debug.c:132: warning: type defaults to 'int' in >>> declaration of >>> 'erts_commit_staged_bp' >>> beam/beam_debug.c:132: warning: function declaration isn't a prototype >>> beam/beam_debug.c:132: error: conflicting types for >>> 'erts_commit_staged_bp' >>> beam/beam_bp.h:116: error: previous declaration of >>> 'erts_commit_staged_bp' >>> was here >>> beam/beam_debug.c:132: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:133: error: syntax error before '&' token >>> beam/beam_debug.c:133: warning: type defaults to 'int' in >>> declaration of >>> 'erts_uninstall_breakpoints' >>> beam/beam_debug.c:133: warning: function declaration isn't a prototype >>> beam/beam_debug.c:133: error: conflicting types for >>> 'erts_uninstall_breakpoints' >>> beam/beam_bp.h:126: error: previous declaration of >>> 'erts_uninstall_breakpoints' was here >>> beam/beam_debug.c:133: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:135: error: syntax error before '&' token >>> beam/beam_debug.c:135: warning: type defaults to 'int' in >>> declaration of >>> 'erts_consolidate_bp_data' >>> beam/beam_debug.c:135: warning: function declaration isn't a prototype >>> beam/beam_debug.c:135: error: conflicting types for >>> 'erts_consolidate_bp_data' >>> beam/beam_bp.h:127: error: previous declaration of >>> 'erts_consolidate_bp_data' was here >>> beam/beam_debug.c:135: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:136: warning: type defaults to 'int' in >>> declaration of >>> 'res' >>> beam/beam_debug.c:136: error: 'f' undeclared here (not in a function) >>> beam/beam_debug.c:136: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:137: error: syntax error before '&' token >>> beam/beam_debug.c:137: warning: type defaults to 'int' in >>> declaration of >>> 'erts_bp_free_matched_functions' >>> beam/beam_debug.c:137: warning: function declaration isn't a prototype >>> beam/beam_debug.c:137: error: conflicting types for >>> 'erts_bp_free_matched_functions' >>> beam/beam_bp.h:123: error: previous declaration of >>> 'erts_bp_free_matched_functions' was here >>> beam/beam_debug.c:137: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:139: warning: type defaults to 'int' in >>> declaration of >>> 'erts_thr_progress_unblock' >>> beam/beam_debug.c:139: warning: function declaration isn't a prototype >>> beam/beam_debug.c:132: warning: type defaults to 'int' in >>> declaration of >>> 'erts_commit_staged_bp' >>> beam/beam_debug.c:132: warning: function declaration isn't a prototype >>> beam/beam_debug.c:132: error: conflicting types for >>> 'erts_commit_staged_bp' >>> beam/beam_bp.h:116: error: previous declaration of >>> 'erts_commit_staged_bp' >>> was here >>> beam/beam_debug.c:132: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:133: error: syntax error before '&' token >>> beam/beam_debug.c:133: warning: type defaults to 'int' in >>> declaration of >>> 'erts_uninstall_breakpoints' >>> beam/beam_debug.c:133: warning: function declaration isn't a prototype >>> beam/beam_debug.c:141: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:142: error: syntax error before 'return' >>> beam/beam_debug.c: In function 'erts_debug_breakpoint_2': >>> beam/beam_debug.c:81: error: two or more data types in declaration >>> specifiers >>> beam/beam_debug.c:81: error: syntax error before '=' token >>> beam/beam_debug.c:89: error: syntax error before '_Bool' >>> beam/beam_debug.c:126: error: syntax error before '_Bool' >>> beam/beam_debug.c:93: error: label 'error' used but not defined >>> beam/beam_debug.c:86: warning: unused variable 'res' >>> beam/beam_debug.c: At top level: >>> beam/beam_debug.c:130: error: syntax error before 'else' >>> beam/beam_debug.c:132: warning: type defaults to 'int' in >>> declaration of >>> 'erts_commit_staged_bp' >>> beam/beam_debug.c:132: warning: function declaration isn't a prototype >>> beam/beam_debug.c:132: error: conflicting types for >>> 'erts_commit_staged_bp' >>> beam/beam_bp.h:116: error: previous declaration of >>> 'erts_commit_staged_bp' >>> was here >>> beam/beam_debug.c:132: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:133: error: syntax error before '&' token >>> beam/beam_debug.c:133: warning: type defaults to 'int' in >>> declaration of >>> 'erts_uninstall_breakpoints' >>> beam/beam_debug.c:133: warning: function declaration isn't a prototype >>> beam/beam_debug.c:133: error: conflicting types for >>> 'erts_uninstall_breakpoints' >>> beam/beam_bp.h:126: error: previous declaration of >>> 'erts_uninstall_breakpoints' was here >>> beam/beam_debug.c:133: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:135: error: syntax error before '&' token >>> beam/beam_debug.c:135: warning: type defaults to 'int' in >>> declaration of >>> 'erts_consolidate_bp_data' >>> beam/beam_debug.c:135: warning: function declaration isn't a prototype >>> beam/beam_debug.c:135: error: conflicting types for >>> 'erts_consolidate_bp_data' >>> beam/beam_bp.h:127: error: previous declaration of >>> 'erts_consolidate_bp_data' was here >>> beam/beam_debug.c:135: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:136: warning: type defaults to 'int' in >>> declaration of >>> 'res' >>> beam/beam_debug.c:136: error: 'f' undeclared here (not in a function) >>> beam/beam_debug.c:136: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:137: error: syntax error before '&' token >>> beam/beam_debug.c:137: warning: type defaults to 'int' in >>> declaration of >>> 'erts_bp_free_matched_functions' >>> beam/beam_debug.c:137: warning: function declaration isn't a prototype >>> beam/beam_debug.c:137: error: conflicting types for >>> 'erts_bp_free_matched_functions' >>> beam/beam_bp.h:123: error: previous declaration of >>> 'erts_bp_free_matched_functions' was here >>> beam/beam_debug.c:137: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:139: warning: type defaults to 'int' in >>> declaration of >>> 'erts_thr_progress_unblock' >>> beam/beam_debug.c:139: warning: function declaration isn't a prototype >>> beam/beam_debug.c:139: error: conflicting types for >>> 'erts_thr_progress_unblock' >>> beam/erl_thr_progress.h:48: error: previous declaration of >>> 'erts_thr_progress_unblock' was here >> [in 'pu']: >> beam/beam_debug.c:139: >> erts_smp_thr_progress_unblock(); >> >> and >> beam/erl_thr_progress.h:48: >> void erts_thr_progress_unblock(void); >> >>> beam/beam_debug.c:139: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:140: error: syntax error before '(' token >>> beam/beam_debug.c:141: warning: type defaults to 'int' in >>> declaration of >>> 'erts_release_code_write_permission' >>> beam/beam_debug.c:141: warning: function declaration isn't a prototype >>> beam/beam_debug.c:141: error: conflicting types for >>> 'erts_release_code_write_permission' >>> beam/code_ix.h:95: error: previous declaration of >>> 'erts_release_code_write_permission' was here >>> beam/beam_debug.c:141: warning: data definition has no type or >>> storage class >>> beam/beam_debug.c:142: error: syntax error before 'return' >>> lipo: can't figure out the architecture type of: /var/tmp//ccpYKJDY.out >>> make[3]: *** [obj/i386-apple-darwin9.8.0/opt/smp/beam_debug.o] Error 1 >>> make[2]: *** [opt] Error 2 >>> make[1]: *** [smp] Error 2 >>> make: *** [emulator] Error 2 >> Furthermore, looking at all these errors, I don't have a clue... >> >> Maybe it's simply a merge/patch/git-thing that got broken ? >> This seems to break more stuff though on darwin, This few lines cannot be in erl_driver.h +#ifdef HAVE_DLFCN_H +#include +#endif It seems like you have to include them local, to the files where you need them. -- BR Fredrik Gustafsson Erlang OTP Team From bgustavsson@REDACTED Mon Mar 25 14:05:53 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 25 Mar 2013 14:05:53 +0100 Subject: [erlang-patches] Directly use the pmod_transform application as a dependency via the rebar tool In-Reply-To: References: Message-ID: Thanks for the patch. I found some issues with the changes to the .gitignore file: By deleting the "*.beam" line the *.beam files in the tests/ directory will no longer be ignored. The new "ebin/" line should start with a slash to anchor it to the top of repository (this is a nit pick and is unlikely to cause any problems in practice). Therefore, I suggest that the .gitignore file should look like: *.beam .eunit/ .qc/ /ebin/ On Mon, Mar 25, 2013 at 6:01 AM, ???? ????? ??? ? wrote: > > Hello. > > It is helpful to directly use the pmod_transform application as a > dependency via the rebar tool. This patch makes this possible. > > > $ git fetch https://github.com/ubf/pmod_transform.git master > > commit eb4842e0079803187572e3dc6682f950bba183f4 > Author: Joseph Wayne Norton > Date: Wed Feb 20 12:27:31 2013 +0900 > > Add src/pmod_transform.app.src for rebar support > > > The following repository contains instructions that demonstrate how this > patch has been used for this purpose. > > https://github.com/ubf/ubf#quick-start-recipe > > Best regards, > > Joe N. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From norton@REDACTED Mon Mar 25 14:22:34 2013 From: norton@REDACTED (=?utf-8?B?44OO44O844OI44OzIOOCuOODp+ODvOOCu+ODlSDjgqbjgqfjgqQg?= =?utf-8?B?44Oz?=) Date: Mon, 25 Mar 2013 22:22:34 +0900 Subject: [erlang-patches] Directly use the pmod_transform application as a dependency via the rebar tool In-Reply-To: References: Message-ID: Bj?rn - Thanks for your review. I applied your suggestion and pushed a new version to GitHub. thanks. Joe N. On Mar 25, 2013, at 22:05 , Bj?rn Gustavsson wrote: > Therefore, I suggest that the .gitignore file should look > like: > > *.beam > .eunit/ > .qc/ > /ebin/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.girondel@REDACTED Mon Mar 25 16:25:54 2013 From: olivier.girondel@REDACTED (Olivier Girondel) Date: Mon, 25 Mar 2013 16:25:54 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: <51501E7A.4070000@erlang.org> References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> <5149EDFD.8040909@erlang.org> <5149F517.7050508@erlang.org> <514C2DC7.40208@erlang.org> <514C8295.80506@erlang.org> <51501E7A.4070000@erlang.org> Message-ID: On Mon, Mar 25, 2013 at 10:52 AM, Fredrik wrote: > This seems to break more stuff though on darwin, > This few lines cannot be in erl_driver.h > +#ifdef HAVE_DLFCN_H > +#include > +#endif > It seems like you have to include them local, to the files where you need > them. Hi Fredrik, I pushed those changes to a new branch: git fetch git://github.com/oliv3/otp.git erl_ddll_try_load4 Best regards, -- Olivier From fredrik@REDACTED Mon Mar 25 16:42:33 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 25 Mar 2013 16:42:33 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> <5149EDFD.8040909@erlang.org> <5149F517.7050508@erlang.org> <514C2DC7.40208@erlang.org> <514C8295.80506@erlang.org> <51501E7A.4070000@erlang.org> Message-ID: <51507069.5090505@erlang.org> On 03/25/2013 04:25 PM, Olivier Girondel wrote: > On Mon, Mar 25, 2013 at 10:52 AM, Fredrik wrote: >> This seems to break more stuff though on darwin, >> This few lines cannot be in erl_driver.h >> +#ifdef HAVE_DLFCN_H >> +#include >> +#endif >> It seems like you have to include them local, to the files where you need >> them. > Hi Fredrik, > > I pushed those changes to a new branch: > > git fetch git://github.com/oliv3/otp.git erl_ddll_try_load4 > > Best regards, > Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From alisdairsullivan@REDACTED Mon Mar 25 17:22:36 2013 From: alisdairsullivan@REDACTED (alisdair) Date: Mon, 25 Mar 2013 09:22:36 -0700 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications Message-ID: erl_interface and jinterface lack .app and .appup files. this causes problems with some tools; reltool in particular. this patch fixes that git fetch git://github.com/talentdeficit/otp.git (http://github.com/talentdeficit/otp.git) appfiles_for_all_apps https://github.com/talentdeficit/otp/compare/appfiles_for_all_apps https://github.com/talentdeficit/otp/compare/appfiles_for_all_apps.patch -- alisdair -------------- next part -------------- An HTML attachment was scrubbed... URL: From alisdairsullivan@REDACTED Tue Mar 26 02:41:39 2013 From: alisdairsullivan@REDACTED (alisdair) Date: Mon, 25 Mar 2013 18:41:39 -0700 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) Message-ID: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> the previous submission has bad history, apologies. this is the correct version erl_interface and jinterface lack .app and .appup files. this causes problems with some tools; reltool in particular. this patch fixes that git fetch git://github.com/talentdeficit/otp.git (http://github.com/talentdeficit/otp.git) otpify_interface_apps https://github.com/talentdeficit/otp/compare/otpify_interface_apps https://github.com/talentdeficit/otp/compare/otpify_interface_apps (https://github.com/talentdeficit/otp/compare/appfiles_for_all_apps.patch).patch -- alisdair -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Tue Mar 26 10:01:22 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 26 Mar 2013 10:01:22 +0100 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> Message-ID: <515163E2.4080908@erlang.org> On 03/26/2013 02:41 AM, alisdair wrote: > the previous submission has bad history, apologies. this is the > correct version > > erl_interface and jinterface lack .app and .appup files. this causes problems with some tools; reltool in particular. this patch fixes that > git fetch git://github.com/talentdeficit/otp.git otpify_interface_apps > https://github.com/talentdeficit/otp/compare/otpify_interface_apps > https://github.com/talentdeficit/otp/compare/otpify_interface_apps .patch > > -- > alisdair > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello, I've included this in the 'pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Tue Mar 26 10:33:15 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 26 Mar 2013 10:33:15 +0100 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> Message-ID: <51516B5B.7070004@erlang.org> On 03/26/2013 02:41 AM, alisdair wrote: > the previous submission has bad history, apologies. this is the > correct version > > erl_interface and jinterface lack .app and .appup files. this causes problems with some tools; reltool in particular. this patch fixes that > git fetch git://github.com/talentdeficit/otp.git otpify_interface_apps > https://github.com/talentdeficit/otp/compare/otpify_interface_apps > https://github.com/talentdeficit/otp/compare/otpify_interface_apps .patch > > -- > alisdair > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Your patch seems not to build: make -w --jobserver-fds=3,13 -j RELEASE_PATH="/*****/release/x86_64-unknown-linux-gnu" \ release_docs_spec make[4]: Entering directory `/*********/lib/jinterface/src' make[4]: *** No rule to make target `release_docs_spec'. Stop. make[4]: Leaving directory `/***********/lib/jinterface/src' make[3]: *** [release_docs] Error 2 make[3]: Leaving directory `/***********/lib/jinterface/src' make[2]: *** [release_docs] Error 2 make[2]: Leaving directory `/*********/lib/jinterface' make[1]: *** [release_docs] Error 2 make[1]: Leaving directory `/********/lib' make: *** [release_docs] Error 2 Please verify that your patch build before replying! Thanks. -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Tue Mar 26 11:13:17 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 26 Mar 2013 11:13:17 +0100 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: <51516B5B.7070004@erlang.org> References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> <51516B5B.7070004@erlang.org> Message-ID: <515174BD.2070406@erlang.org> On 03/26/2013 10:33 AM, Fredrik wrote: > On 03/26/2013 02:41 AM, alisdair wrote: >> the previous submission has bad history, apologies. this is the >> correct version >> >> erl_interface and jinterface lack .app and .appup files. this causes problems with some tools; reltool in particular. this patch fixes that >> git fetch git://github.com/talentdeficit/otp.git otpify_interface_apps >> https://github.com/talentdeficit/otp/compare/otpify_interface_apps >> https://github.com/talentdeficit/otp/compare/otpify_interface_apps .patch >> >> -- >> alisdair >> >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > Your patch seems not to build: > make -w --jobserver-fds=3,13 -j RELEASE_PATH="/*****/release/x86_64-unknown-linux-gnu" \ > release_docs_spec > make[4]: Entering directory `/*********/lib/jinterface/src' > make[4]: *** No rule to make target `release_docs_spec'. Stop. > make[4]: Leaving directory `/***********/lib/jinterface/src' > make[3]: *** [release_docs] Error 2 > make[3]: Leaving directory `/***********/lib/jinterface/src' > make[2]: *** [release_docs] Error 2 > make[2]: Leaving directory `/*********/lib/jinterface' > make[1]: *** [release_docs] Error 2 > make[1]: Leaving directory `/********/lib' > make: *** [release_docs] Error 2 > > Please verify that your patch build before replying! > Thanks. > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Since we are on the subject, We have a ticket about this but we were planning to solve this matter in reltool, i.e without adding the .app file in the applications that are missing them. You write, " this causes problems with some tools; reltool in particular " What are these other tools, except reltool that it causes problems for? This is very interesting for us. -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Tue Mar 26 11:39:06 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 26 Mar 2013 11:39:06 +0100 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: <515174BD.2070406@erlang.org> References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> <51516B5B.7070004@erlang.org> <515174BD.2070406@erlang.org> Message-ID: On Tue, Mar 26, 2013 at 11:13 AM, Fredrik wrote: > Since we are on the subject, > We have a ticket about this but we were planning to solve this > matter in reltool, i.e without adding the .app file in the > applications that are missing them. How exactly? Do you plan for reltool to derive app name and version from the directory name and the modules from ebin/*.beam? Can that cover scenarios like an application requiring mnesia? What about application environment variables? Does anyone have a good guess why projects skip writing/generating the .app file? > You write, > " > > this causes problems with some tools; reltool in particular > > " > What are these other tools, except reltool that it causes problems > for? This is very interesting for us. From n.oxyde@REDACTED Tue Mar 26 11:45:24 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 26 Mar 2013 11:45:24 +0100 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: <515174BD.2070406@erlang.org> References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> <51516B5B.7070004@erlang.org> <515174BD.2070406@erlang.org> Message-ID: <520A8D1E-51F7-4F85-B4D0-4CF425E09098@gmail.com> I would rather correctly create the .app files, not make them optional. -- Anthony Ramine Le 26 mars 2013 ? 11:13, Fredrik a ?crit : > We have a ticket about this but we were planning to solve this matter in reltool, i.e without adding the .app file in the applications that are missing them. From magnus@REDACTED Tue Mar 26 13:58:42 2013 From: magnus@REDACTED (Magnus Henoch) Date: Tue, 26 Mar 2013 12:58:42 +0000 Subject: [erlang-patches] Improve Dialyzer scan error messages Message-ID: Here is a patch that improves the output from Dialyzer when it fails to scan a file. In my experience this usually happens because of a missing parse transform, but the same applies to Erlang files with syntax errors. This is the output from running "dialyzer --src" on an empty file without this patch: dialyzer: Analysis failed with error: Could not scan the following file(s): [{"/tmp/foo.erl", ["/tmp/foo.erl:1: no module definition\n"]}] And with the patch: dialyzer: Analysis failed with error: Could not scan the following file(s): /tmp/foo.erl:1: no module definition git fetch git://github.com/legoscia/otp.git dialyzer-scan-error https://github.com/legoscia/otp/compare/legoscia:dialyzer-scan-error https://github.com/legoscia/otp/compare/legoscia:dialyzer-scan-error.patch Regards, Magnus From kostis@REDACTED Tue Mar 26 14:29:37 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 26 Mar 2013 14:29:37 +0100 Subject: [erlang-patches] Improve Dialyzer scan error messages In-Reply-To: References: Message-ID: <5151A2C1.1070504@cs.ntua.gr> On 03/26/2013 01:58 PM, Magnus Henoch wrote: > Here is a patch that improves the output from Dialyzer when it fails to > scan a file. In my experience this usually happens because of a missing > parse transform, but the same applies to Erlang files with syntax > errors. > > This is the output from running "dialyzer --src" on an empty file > without this patch: > > dialyzer: Analysis failed with error: > Could not scan the following file(s): [{"/tmp/foo.erl", > ["/tmp/foo.erl:1: no module definition\n"]}] > > And with the patch: > > dialyzer: Analysis failed with error: > Could not scan the following file(s): > /tmp/foo.erl:1: no module definition Some comments: A more convincing example, perhaps with more than one "failing" file, would help (me at least) appreciate the great improvement that this patch provides. Also, one should check how this change affects the Erlang interface of dialyzer (that of dialyzer:run). Finally, I am not sure I like the extra new line, but that's perhaps a minor point. Kostis From magnus@REDACTED Tue Mar 26 15:23:56 2013 From: magnus@REDACTED (Magnus Henoch) Date: Tue, 26 Mar 2013 14:23:56 +0000 Subject: [erlang-patches] Improve Dialyzer scan error messages In-Reply-To: <5151A2C1.1070504@cs.ntua.gr> (Kostis Sagonas's message of "Tue, 26 Mar 2013 14:29:37 +0100") References: <5151A2C1.1070504@cs.ntua.gr> Message-ID: Kostis Sagonas writes: > Some comments: > > A more convincing example, perhaps with more than one "failing" file, > would help (me at least) appreciate the great improvement that this > patch provides. Also, one should check how this change affects the > Erlang interface of dialyzer (that of dialyzer:run). Finally, I am > not sure I like the extra new line, but that's perhaps a minor point. You are right about the newline - it shouldn't be there. I've updated the patch. A recent checkout of basho_bench can serve as an example: git clone git://github.com/basho/basho_bench.git cd basho_bench/src git checkout 1276ee6d368a266617d5c22db71f0561d4f46d24 dialyzer --src *.erl The basho_bench code uses header files from its dependencies, so running dialyzer without getting the dependencies will fail. Without the patch, this is the output: dialyzer: Analysis failed with error: Could not scan the following file(s): [{"/private/tmp/basho_bench/src/uuid.erl", ["/private/tmp/basho_bench/src/uuid.erl:33: bad import declaration\n"]}, {"/private/tmp/basho_bench/src/basho_bench_driver_cassandra_cql.erl", ["/private/tmp/basho_bench/src/basho_bench_driver_cassandra_cql.erl:28: can't find include lib \"erlcassa/include/erlcassa.hrl\"\n"]}, {"/private/tmp/basho_bench/src/basho_bench_driver_cassandra.erl", ["/private/tmp/basho_bench/src/basho_bench_driver_cassandra.erl:28: can't find include lib \"casbench/include/cassandra_thrift.hrl\"\n", "/private/tmp/basho_bench/src/basho_bench_driver_cassandra.erl:54: record columnPath undefined\n"]}] Last messages in the log cache: Reading files and computing callgraph... With the patch, the output is: dialyzer: Analysis failed with error: Could not scan the following file(s): /private/tmp/basho_bench/src/uuid.erl:33: bad import declaration /private/tmp/basho_bench/src/basho_bench_driver_cassandra_cql.erl:28: can't find include lib "erlcassa/include/erlcassa.hrl" /private/tmp/basho_bench/src/basho_bench_driver_cassandra.erl:28: can't find include lib "casbench/include/cassandra_thrift.hrl" /private/tmp/basho_bench/src/basho_bench_driver_cassandra.erl:54: record columnPath undefined Last messages in the log cache: Reading files and computing callgraph... The former output has lines wider than my screen, while the latter doesn't, so readability is increased. The behaviour when using dialyzer:run is mostly unchanged: in both cases, it throws {dialyzer_error, iolist()} with an iolist starting with "Analysis failed with error:\nCould not scan the following file(s):". Subsequent output is changed, but the format of this exception is not documented, so I hope nothing is relying on that. Regards, Magnus From erlangsiri@REDACTED Tue Mar 26 15:37:12 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 26 Mar 2013 15:37:12 +0100 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> <51516B5B.7070004@erlang.org> <515174BD.2070406@erlang.org> Message-ID: Hi 2013/3/26 Tuncer Ayaz > On Tue, Mar 26, 2013 at 11:13 AM, Fredrik wrote: > > > Since we are on the subject, > > We have a ticket about this but we were planning to solve this > > matter in reltool, i.e without adding the .app file in the > > applications that are missing them. > > Just to be clear, this ticket is about allowing reltool to include non-erlang applications, like erl_interface and jinterface. I assumed that Alisdair's patch was about this - if not, please let me know. > How exactly? Well, this isn't really decided yet, but a fair guess should be to allow directories in lib_dirs, that do not contain a sub-directory named ebin, to be seen as application directories. Possibly with the aid of some configuration option to reltool. > Do you plan for reltool to derive app name and version > from the directory name and the modules from ebin/*.beam? That is already the case when no .app file is found. However, the cases I talk about here are mainly when there are no beam files - i.e. non-erlang applications. > Can that > cover scenarios like an application requiring mnesia? Not sure if I understand what you mean... If you need to specify dependencies like the 'applications' entry in the .app file you still need to provide the .app file. > What about > application environment variables? > Only needed if you write an erlang application, and then you should still add your .app file. > Does anyone have a good guess why projects skip writing/generating the > .app file? > Not in general, but for the cases of erl_interface and jinterface it is because these are non-erlang applications so the .app file would never be used. > Regards /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Tue Mar 26 15:53:36 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 26 Mar 2013 15:53:36 +0100 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: <520A8D1E-51F7-4F85-B4D0-4CF425E09098@gmail.com> References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> <51516B5B.7070004@erlang.org> <515174BD.2070406@erlang.org> <520A8D1E-51F7-4F85-B4D0-4CF425E09098@gmail.com> Message-ID: <5151B670.50204@erlang.org> On 2013-03-26 11:45, Anthony Ramine wrote: > I would rather correctly create the .app files, not make them optional. > erl_interface and jinterface shouldn't be considered erlang applications and shouldn't need .app or .appup files. They are more build requirements for certain c/java programs or requirements for drivers. Like any other c-dev lib. That is at least my position on the matter. In a manifest file I would list them under requirements not dependencies. Please consider another solution. // Bj?rn-Egil From tuncer.ayaz@REDACTED Tue Mar 26 18:58:20 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 26 Mar 2013 18:58:20 +0100 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> <51516B5B.7070004@erlang.org> <515174BD.2070406@erlang.org> Message-ID: On Tue, 26 Mar 2013 15:37:12 +0100, Siri Hansen wrote: > Hi Thanks for the quick response. > 2013/3/26 Tuncer Ayaz > >> On Tue, Mar 26, 2013 at 11:13 AM, Fredrik wrote: >> >> > Since we are on the subject, >> > We have a ticket about this but we were planning to solve this >> > matter in reltool, i.e without adding the .app file in the >> > applications that are missing them. >> >> > Just to be clear, this ticket is about allowing reltool to include > non-erlang applications, like erl_interface and jinterface. I > assumed that Alisdair's patch was about this - if not, please let me > know. Sorry for the misunderstanding, looks like I did interpret Fredrik's mail the wrong way. With that said my questions are irrelevant. >> How exactly? > > > Well, this isn't really decided yet, but a fair guess should be to > allow directories in lib_dirs, that do not contain a sub-directory > named ebin, to be seen as application directories. Possibly with the > aid of some configuration option to reltool. I wouldn't make it fully automatic but require specifying that for example jinterface is of type 'non_erlang' in the reltool spec. >> Do you plan for reltool to derive app name and version from the >> directory name > > and the modules from ebin/*.beam? > > > That is already the case when no .app file is found. However, the > cases I talk about here are mainly when there are no beam files - > i.e. non-erlang applications. > > >> Can that cover scenarios like an application requiring mnesia? > > > Not sure if I understand what you mean... If you need to specify > dependencies like the 'applications' entry in the .app file you > still need to provide the .app file. Exactly. >> What about application environment variables? >> > > Only needed if you write an erlang application, and then you should > still add your .app file. > >> Does anyone have a good guess why projects skip writing/generating >> the .app file? > > Not in general, but for the cases of erl_interface and jinterface it > is because these are non-erlang applications so the .app file would > never be used. This sounds reasonable for non-Erlang projects. From olivier.girondel@REDACTED Tue Mar 26 21:30:00 2013 From: olivier.girondel@REDACTED (Olivier Girondel) Date: Tue, 26 Mar 2013 21:30:00 +0100 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: <515073B9.8020101@erlang.org> References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> <5149EDFD.8040909@erlang.org> <5149F517.7050508@erlang.org> <514C2DC7.40208@erlang.org> <514C8295.80506@erlang.org> <51501E7A.4070000@erlang.org> <515073B9.8020101@erlang.org> Message-ID: Forgot to CC the list On Mon, Mar 25, 2013 at 4:56 PM, Fredrik wrote: > Could you please base it upon 'maint' branch ? Hi, Rebased to a new branch erl_ddll_try_load6 BR, -- Olivier From alisdairsullivan@REDACTED Wed Mar 27 00:41:03 2013 From: alisdairsullivan@REDACTED (alisdair) Date: Tue, 26 Mar 2013 16:41:03 -0700 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: <5151B670.50204@erlang.org> References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> <51516B5B.7070004@erlang.org> <515174BD.2070406@erlang.org> <520A8D1E-51F7-4F85-B4D0-4CF425E09098@gmail.com> <5151B670.50204@erlang.org> Message-ID: <096ABA5CF37E48758F2C2096E74B107B@yahoo.ca> I don't see any reason header only applications should not be considered erlang applications and treated as them when possible. As it stands erl_interface and jinterface are the only two things in the lib dir that are not erlang applications and need special treatment but header only projects that do not generate .beam code directly are entirely possible. Of note is the fact that these projects may register processes and have app dependencies of their own necessitating .app/.appup files. Making a distinction between apps in this category and 'erlang applications' just makes tool support more difficult. Would a solution that loosens the restrictions on what is considered an application so that erl_interface and jinterface qualify (rather than adding admittedly unneeded erlang application requirements to erl_interface and jinterface) receive full tool support be considered? -- alisdair On Tuesday, 26 March, 2013 at 7:53 AM, Bj?rn-Egil Dahlberg wrote: > On 2013-03-26 11:45, Anthony Ramine wrote: > > I would rather correctly create the .app files, not make them optional. > > erl_interface and jinterface shouldn't be considered erlang applications > and shouldn't need .app or .appup files. > > They are more build requirements for certain c/java programs or > requirements for drivers. Like any other c-dev lib. That is at least my > position on the matter. > > In a manifest file I would list them under requirements not dependencies. > > Please consider another solution. > > // Bj?rn-Egil > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alisdairsullivan@REDACTED Wed Mar 27 00:41:48 2013 From: alisdairsullivan@REDACTED (alisdair) Date: Tue, 26 Mar 2013 16:41:48 -0700 Subject: [erlang-patches] .app and .appup files for erl_interface and jinterface applications (amended) In-Reply-To: <51516B5B.7070004@erlang.org> References: <7EB4C88D60DA4688806FE193476715F0@yahoo.ca> <51516B5B.7070004@erlang.org> Message-ID: <01768828BD46464D8259A66D363CEDB4@yahoo.ca> Updated, please repull. I have one failing test case in erl_interface and two skipped tests in jinterface but I get the same failures when running tests from the unmodified `maint' branch and as far as I can tell the failure/skips are unrelated to my changes -- alisdair On Tuesday, 26 March, 2013 at 2:33 AM, Fredrik wrote: > On 03/26/2013 02:41 AM, alisdair wrote: > > the previous submission has bad history, apologies. this is the correct version > > > > erl_interface and jinterface lack .app and .appup files. this causes problems with some tools; reltool in particular. this patch fixes that > > git fetch git://github.com/talentdeficit/otp.git (http://github.com/talentdeficit/otp.git) otpify_interface_apps > > https://github.com/talentdeficit/otp/compare/otpify_interface_apps > > https://github.com/talentdeficit/otp/compare/otpify_interface_apps (https://github.com/talentdeficit/otp/compare/appfiles_for_all_apps.patch).patch > > > > > > > > -- > > alisdair > > > > > > > > _______________________________________________ erlang-patches mailing list erlang-patches@REDACTED (mailto:erlang-patches@REDACTED) http://erlang.org/mailman/listinfo/erlang-patches Your patch seems not to build: > make -w --jobserver-fds=3,13 -j RELEASE_PATH="/*****/release/x86_64-unknown-linux-gnu" \ release_docs_spec make[4]: Entering directory `/*********/lib/jinterface/src' make[4]: *** No rule to make target `release_docs_spec'. Stop. make[4]: Leaving directory `/***********/lib/jinterface/src' make[3]: *** [release_docs] Error 2 make[3]: Leaving directory `/***********/lib/jinterface/src' make[2]: *** [release_docs] Error 2 make[2]: Leaving directory `/*********/lib/jinterface' make[1]: *** [release_docs] Error 2 make[1]: Leaving directory `/********/lib' make: *** [release_docs] Error 2 > Please verify that your patch build before replying! > Thanks. > -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Mar 27 10:09:41 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 27 Mar 2013 10:09:41 +0100 Subject: [erlang-patches] Fix a bug in some binary comprehensions In-Reply-To: <515013FE.70903@erlang.org> References: <93249178-4D54-4D52-BEE9-057E13326244@gmail.com> <515013FE.70903@erlang.org> Message-ID: <02ACE89B-1AF0-4A46-8B31-E1497838C71F@gmail.com> Hello, I amended my second commit and to make +clint0 run the Core Erlang linting pass just before any optimisation pass. Please refetch. Regards, -- Anthony Ramine Le 25 mars 2013 ? 10:08, Fredrik a ?crit : > On 03/24/2013 06:50 PM, Anthony Ramine wrote: >> git fetch https://github.com/nox/otp.git fix-bc-optim > Fetched and currently in the 'pu' branch. > Thanks, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From bgustavsson@REDACTED Wed Mar 27 11:37:57 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 27 Mar 2013 11:37:57 +0100 Subject: [erlang-patches] Directly use the pmod_transform application as a dependency via the rebar tool In-Reply-To: References: Message-ID: Thanks! I have pulled your amended commit. /Bjorn On Mon, Mar 25, 2013 at 2:22 PM, ???? ????? ??? ? wrote: > > Bj?rn - > > Thanks for your review. I applied your suggestion and pushed a new > version to GitHub. > > thanks. > > Joe N. > > > On Mar 25, 2013, at 22:05 , Bj?rn Gustavsson > wrote: > > Therefore, I suggest that the .gitignore file should look > like: > > *.beam > .eunit/ > .qc/ > /ebin/ > > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Wed Mar 27 15:43:22 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 27 Mar 2013 15:43:22 +0100 Subject: [erlang-patches] Fix a bug in some binary comprehensions In-Reply-To: <02ACE89B-1AF0-4A46-8B31-E1497838C71F@gmail.com> References: <93249178-4D54-4D52-BEE9-057E13326244@gmail.com> <515013FE.70903@erlang.org> <02ACE89B-1AF0-4A46-8B31-E1497838C71F@gmail.com> Message-ID: Thanks for the patch! I have reviewed your patch and have a few comments: The following line: Vs = [V||{_,#c_var{name=V}}<-Vars0] should be written with spaces around || and <-: Vs = [V || {_,#c_var{name=V}} <- Vars0] to match the style in the rest of the compiler. The following is a matter of taste, but I would prefer to avoid giving mul_pairs() an extra argument just so that it can build it into the return tuple (and otherwise unused). Thus, I would prefer bc_elem_size() to end like this: {E,Pre,St} = bc_mul_pairs(F, #c_literal{val=Bits}, [], St0), {E,Pre,Vs,St}. to avoid making bc_mul_pairs() harder to read. There are no test cases. Could you please add a test case (making sure that both of the new throw(impossible) in bc_verify_non_filtering/1 are covered)? bc_bincomp_SUITE.erl should be a good place. (Remember, new test cases should not have any ?line macros addes.) /Bjorn On Wed, Mar 27, 2013 at 10:09 AM, Anthony Ramine wrote: > Hello, > > I amended my second commit and to make +clint0 run the Core Erlang linting > pass just before any optimisation pass. > > Please refetch. > > Regards, > > -- > Anthony Ramine > > Le 25 mars 2013 ? 10:08, Fredrik a ?crit : > > > On 03/24/2013 06:50 PM, Anthony Ramine wrote: > >> git fetch https://github.com/nox/otp.git fix-bc-optim > > Fetched and currently in the 'pu' branch. > > Thanks, > > > > -- > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Mar 28 11:36:22 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 28 Mar 2013 11:36:22 +0100 Subject: [erlang-patches] Fix a bug in some binary comprehensions In-Reply-To: References: <93249178-4D54-4D52-BEE9-057E13326244@gmail.com> <515013FE.70903@erlang.org> <02ACE89B-1AF0-4A46-8B31-E1497838C71F@gmail.com> Message-ID: Hello Bj?rn, I amended my patch with the modifications you suggested; please refetch. Regards, -- Anthony Ramine Le 27 mars 2013 ? 15:43, Bj?rn Gustavsson a ?crit : > Thanks for the patch! > > I have reviewed your patch and have a few comments: > > The following line: > > Vs = [V||{_,#c_var{name=V}}<-Vars0] > > should be written with spaces around || and <-: > > Vs = [V || {_,#c_var{name=V}} <- Vars0] > > to match the style in the rest of the compiler. > > > The following is a matter of taste, but I would > prefer to avoid giving mul_pairs() an extra argument > just so that it can build it into the return tuple > (and otherwise unused). > > Thus, I would prefer bc_elem_size() to end like this: > > {E,Pre,St} = bc_mul_pairs(F, #c_literal{val=Bits}, [], St0), > {E,Pre,Vs,St}. > > to avoid making bc_mul_pairs() harder to read. > > > There are no test cases. Could you please add > a test case (making sure that both of the new throw(impossible) > in bc_verify_non_filtering/1 are covered)? > > bc_bincomp_SUITE.erl should be a good place. > (Remember, new test cases should not have any ?line > macros addes.) > > /Bjorn > > > > > On Wed, Mar 27, 2013 at 10:09 AM, Anthony Ramine wrote: > Hello, > > I amended my second commit and to make +clint0 run the Core Erlang linting pass just before any optimisation pass. > > Please refetch. > > Regards, > > -- > Anthony Ramine > > Le 25 mars 2013 ? 10:08, Fredrik a ?crit : > > > On 03/24/2013 06:50 PM, Anthony Ramine wrote: > >> git fetch https://github.com/nox/otp.git fix-bc-optim > > Fetched and currently in the 'pu' branch. > > Thanks, > > > > -- > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From fredrik@REDACTED Thu Mar 28 14:19:11 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 28 Mar 2013 14:19:11 +0100 Subject: [erlang-patches] Improve Dialyzer scan error messages In-Reply-To: <5151A2C1.1070504@cs.ntua.gr> References: <5151A2C1.1070504@cs.ntua.gr> Message-ID: <5154434F.6010501@erlang.org> On 03/26/2013 02:29 PM, Kostis Sagonas wrote: > On 03/26/2013 01:58 PM, Magnus Henoch wrote: >> Here is a patch that improves the output from Dialyzer when it fails to >> scan a file. In my experience this usually happens because of a missing >> parse transform, but the same applies to Erlang files with syntax >> errors. >> >> This is the output from running "dialyzer --src" on an empty file >> without this patch: >> >> dialyzer: Analysis failed with error: >> Could not scan the following file(s): [{"/tmp/foo.erl", >> ["/tmp/foo.erl:1: no module >> definition\n"]}] >> >> And with the patch: >> >> dialyzer: Analysis failed with error: >> Could not scan the following file(s): >> /tmp/foo.erl:1: no module definition > > Some comments: > > A more convincing example, perhaps with more than one "failing" file, > would help (me at least) appreciate the great improvement that this > patch provides. Also, one should check how this change affects the > Erlang interface of dialyzer (that of dialyzer:run). Finally, I am > not sure I like the extra new line, but that's perhaps a minor point. > > Kostis > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Fetched, Thanks! -- BR Fredrik Gustafsson Erlang OTP Team From bryan.hunter@REDACTED Fri Mar 29 07:23:01 2013 From: bryan.hunter@REDACTED (Bryan Hunter) Date: Fri, 29 Mar 2013 01:23:01 -0500 Subject: [erlang-patches] Corrected typo in erlsrv usage Message-ID: Hi. This is my first Erlang patch! It's a simple typo correction in the usage message for erlsrv.exe git fetch git://github.com/bryanhunter/otp.git fix-erlsrv-usage-typo https://github.com/bryanhunter/otp/compare/fix-erlsrv-usage-typo https://github.com/bryanhunter/otp/compare/fix-erlsrv-usage-typo.patch -Bryan -- Bryan Hunter Partner & Senior Software Engineer o: (615) 469-2236 ext.204 m: (615) 500-1855 Firefly Logic | @fireflylogic | @bryan_hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Mar 31 12:19:39 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 31 Mar 2013 12:19:39 +0200 Subject: [erlang-patches] Fix SNMP gitignore files Message-ID: <07AECAA8-43F6-4B64-ABBD-B1BB54B6CEFF@gmail.com> Hello, When compiling, some files generated by SNMP are not ignored anymore. This patch fix this. git fetch https://github.com/nox/otp.git fix-snmp-gitignore https://github.com/nox/otp/compare/erlang:maint...fix-snmp-gitignore https://github.com/nox/otp/compare/erlang:maint...fix-snmp-gitignore.patch Regards, -- Anthony Ramine From tuncer.ayaz@REDACTED Sun Mar 31 13:34:12 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 31 Mar 2013 13:34:12 +0200 Subject: [erlang-patches] ct_run: delete unused function Message-ID: git fetch git://github.com/tuncer/otp.git ct_run-unused-fun https://github.com/tuncer/otp/compare/erlang:maint...ct_run-unused-fun https://github.com/tuncer/otp/compare/erlang:maint...ct_run-unused-fun.patch From n.oxyde@REDACTED Sun Mar 31 16:22:37 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 31 Mar 2013 16:22:37 +0200 Subject: [erlang-patches] Bit string generators, unsized binaries, modules and the REPL Message-ID: <649B6ECF-85AD-40BB-9CB1-C04DC348C499@gmail.com> Hello, People on IRC noticed a difference between compiled modules and the REPL in how some binary generators are handled. Compare: $ cat unsized_bin_gen_pat.erl -module(unsized_bin_gen_pat). -export([t/0]). t() -> << <> || <> <= <<1,2,3>> >>. $ erlc unsized_bin_gen_pat.erl $ erl 1> % compiled 1> unsized_bin_gen_pat:t(). <<1,2,3,2,3,3>> 2> % evaluated 2> << <> || <> <= <<1,2,3>> >>. <<1,2,3>> I don't think the compiler should be changed to behave like the REPL, nor I think the REPL should be changed to behave like the compiler. Instead, I think an unsized binary tail in the pattern of a binary generator does not make sense, and this should happen: $ erlc unsized_bin_gen_pat.erl unsized_bin_gen_pat.erl:3: binary fields without size are not allowed in patterns of bit string generators This patch implements this new error and simplifies how v3_core works with forbidden unsized tail segments in patterns of bit string generators. git fetch https://github.com/nox/otp illegal-bitstring-gen-pattern https://github.com/nox/otp/compare/erlang:maint...illegal-bitstring-gen-pattern https://github.com/nox/otp/compare/erlang:maint...illegal-bitstring-gen-pattern.patch Looking at the commit 5daa001 by Bj?rn Gustavsson "Don't generate multiple tail segments in binary matching", this patch will probably by rejected as it seems the compiler behaves as wanted by the OTP team. If this is indeed the case, erl_eval should be fixed. Regards, -- Anthony Ramine