From n.oxyde@REDACTED Sun Sep 2 20:26:24 2012 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 2 Sep 2012 20:26:24 +0200 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: <503CC79B.2020009@erlang.org> References: <610BC6F9-18BF-46A2-B487-492A9B41E42A@gmail.com> <4FCE3186.3000202@erlang.org> <5034FB10.7090804@erlang.org> <503CC79B.2020009@erlang.org> Message-ID: Hi, Again, see responses inlined; please refetch. Regards. -- Anthony Ramine Le 28 ao?t 2012 ? 15:28, Lukas Larsson a ?crit : > Hello, > > See responses inlined. > > Lukas > > On 24/08/12 12:22, Anthony Ramine wrote: >> Most OTP (at least erl_lint, erl_parse and syntax_tools) already knows that locations can be a line or a line and a column; furthermore it is said in erl_parse itself that one should always use get_line/1 and set_line/3 instead of depending on having an integer there. > It does indeed say so inside the code of erl_parse. But all of the visible documentation (here[1] and here[2]) say that it is an integer. So if you have only read the documentation (which I assume most people only have) you would assume that it is an integer. That documentation has to be updated so that LINE can be either an integer() or a tuple(integer(),integer()), and a reference to use erl_parse:set/get_attribute to manipulate it safely. > > The compiler should also be updated to use these API's, this includes the convention that a line number of -1 is used to say that something is compiler generated. To make sure that all uses of the non-api is eliminated, it might be a good idea to declare erl_scan:line as -opaque and let dialyzer search through the otp code for errors. > > [1]: http://www.erlang.org/doc/apps/erts/absform.html > [2]: http://www.erlang.org/doc/man/erl_scan.html#type-line I replaced LINE by LOC in the first documentation you point to and I've patched various type specs in erl_scan and erl_parse so they both use location(). With regard to negative line numbers, it should be noted that user-supplied -file attributes have their line numbers negated whereas as you said in other modules like erl_lint and v3_core, compile-generated nodes are the ones which lines are negated. Shouldn't the opposite be done in epp's -file attributes handling? >> If it is really that heavy of a change, why do we have erl_scan:set_attribute/3 and erl_scan:attributes_info/{1,2}? They obviously were coded to mitigate these issues. > We have indeed been working on getting this to work before, but the effort was left as you see it now because there were a number of issues which needed solving and more important things got in the way. The reason why I say it is a heavy change is that we want to feel that a good effort has been made to make sure that all error and warning column numbers point to the correct position. I've already added a 'file' item to these functions to improve the code populating every node with the file from the -file attributes of the module declaration in erl_lint; maybe another 'generated' item should be added to replace the multiple neg_line and abs_line functions there are in some compile-related modules? >> Any parse transform that break because of this change will break because it does AST manipulation wrong and their users will just have to not use the "column" option for it to continue to work. > Strictly speaking parse transform is also an experimental/undocumented feature of Erlang/OTP. But unfortunately a lot of people seem to use them, so we have to take some backwards compatibility into consideration. The closest thing to a documentation is the example found here lib/stdlib/example/erl_id_trans.erl, and that does not deal with line numbers at all. > > We really really have to be sure that the fun2ms and qlc parse transforms work. I've read through the code of various parse transforms this week and they don't seem to make anything related to the transformed nodes' locations. Most OTP-provided parse transforms are covered in the test suites I patched. From stefan.zegenhagen@REDACTED Mon Sep 3 16:26:45 2012 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Mon, 03 Sep 2012 16:26:45 +0200 Subject: [erlang-patches] Bugfix to snmpTargetAddrExtTable Message-ID: <1346682405.2982.10.camel@ax-sze> Dear all, snmpTargetAddrExtTable instrumentation in snmp_community_mib.erl can pass error return values with invalid column numbers to the SNMP engine in response to set requests. The problem arises as follows: * snmpTargetAddrExtTable columns are stored in the appropriate row of snmpTargetAddrTable starting at column 11 * snmpTargetAddrExtTable instrumentation does some basic checks of the column data in set requests, adds 10 to each column number (maps to the corresponding columns in snmpTargetAddrTable storage) and passes the data to the generic SNMP table handler, changing the table name to snmpTargetAddrTable * errors from the generic SNMP table handler are returned as-is, including column numbers+10 * the SNMP engine detects invalid column numbers returned from snmpTargetAddrExtTable instrumentation and emits a genErr error report The resulting genErr obscures the real problem behind the set-request. The patch attached to this e-mail solves the problem by inspecting the result from the generic SNMP table handler and by converting the column numbers back to the allowed range in case of error responses. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-SNMP-fix-invalid-return-values-from-snmpTargetAddrEx.patch Type: text/x-patch Size: 2229 bytes Desc: not available URL: From stefan.zegenhagen@REDACTED Mon Sep 3 16:29:41 2012 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Mon, 03 Sep 2012 16:29:41 +0200 Subject: [erlang-patches] SNMP: fix wrong error code for invalid get requests Message-ID: <1346682581.2982.13.camel@ax-sze> Dear all, when an SNMP get request references an existing scalar variable without instance OID (e.g. sysName instead of sysName.0), the erlang SNMP agent returns a noSuchObject error instead of the correct noSuchInstance error. Some SNMP test suites flag this as error. The patch attached to this e-mail solves the problem by letting the OID lookup routine return the correct noSuchInstance error. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-SNMP-fix-error-code-for-invalid-get-requests.patch Type: text/x-patch Size: 1241 bytes Desc: not available URL: From matthew@REDACTED Tue Sep 4 20:58:49 2012 From: matthew@REDACTED (Matthew Dempsky) Date: Tue, 4 Sep 2012 11:58:49 -0700 Subject: [erlang-patches] Erlang build issue on OpenBSD -current Message-ID: On OpenBSD, shared objects should be linked with "cc -shared", not "ld -shared". This is particularly important now that OpenBSD's C compiler emits code that depends on crtbeginS.o/crtendS.o much more frequently than before, and those object files are not linked in by default when "ld -shared". Diff below tested on OpenBSD 5.2-current. Excuse the sloppy copy/paste whitespace, but it's a trivial patch and I think it needs to be applied to erts/configure.in instead of erts/configure anyway. Cheers! --- erts/configure.orig Tue Sep 4 11:35:01 2012 +++ erts/configure Tue Sep 4 11:35:01 2012 @@ -35122,6 +35122,10 @@ case $host_os in DED_LDFLAGS="-m32 $DED_LDFLAGS" fi ;; + openbsd*) + DED_LD="$CC" + DED_LDFLAGS="-shared" + ;; osf*) # NOTE! Whitespace after -rpath is important. DED_LD_FLAG_RUNTIME_LIBRARY_PATH="-rpath " From stefan.zegenhagen@REDACTED Wed Sep 5 09:38:46 2012 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Wed, 05 Sep 2012 09:38:46 +0200 Subject: [erlang-patches] SNMP: bugfix to vacmAccessTable Message-ID: <1346830726.2982.15.camel@ax-sze> Dear all, there's a typo in lib/snmp/src/agent/snmp_view_based_acm_mib.erl that prevents table row deletions from working as expected. The patch appended to this e-mail solves the issue. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-SNMP-bugfix-to-vacmAccessTable.patch Type: text/x-patch Size: 1109 bytes Desc: not available URL: From stefan.zegenhagen@REDACTED Wed Sep 5 09:42:24 2012 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Wed, 05 Sep 2012 09:42:24 +0200 Subject: [erlang-patches] SNMP: Bugfix to usmUserStorageType semantics Message-ID: <1346830944.2982.18.camel@ax-sze> Dear all, the SNMP-USER-BASED-SM MIB dictates that the storage type of a user entry in usmUserTable must not be readOnly if authentication or privacy are enabled for the user, because the user must be able to change his/her password. The patch attached to this e-mail implements the necessary check. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-SNMP-fix-to-usmUserStorageType-semantics.patch Type: text/x-patch Size: 2903 bytes Desc: not available URL: From henrik@REDACTED Wed Sep 5 10:50:08 2012 From: henrik@REDACTED (Henrik Nord) Date: Wed, 5 Sep 2012 10:50:08 +0200 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: References: <610BC6F9-18BF-46A2-B487-492A9B41E42A@gmail.com> <4FCE3186.3000202@erlang.org> <5034FB10.7090804@erlang.org> <503CC79B.2020009@erlang.org> Message-ID: <50471240.3060005@erlang.org> I would like you to rebase this on R15B02 after the release. /Henrik On 09/02/2012 08:26 PM, Anthony Ramine wrote: > Hi, > > Again, see responses inlined; please refetch. > > Regards. > > -- > Anthony Ramine > > Le 28 ao?t 2012 ? 15:28, Lukas Larsson a ?crit : > >> Hello, >> >> See responses inlined. >> >> Lukas >> >> On 24/08/12 12:22, Anthony Ramine wrote: >>> Most OTP (at least erl_lint, erl_parse and syntax_tools) already knows that locations can be a line or a line and a column; furthermore it is said in erl_parse itself that one should always use get_line/1 and set_line/3 instead of depending on having an integer there. >> It does indeed say so inside the code of erl_parse. But all of the visible documentation (here[1] and here[2]) say that it is an integer. So if you have only read the documentation (which I assume most people only have) you would assume that it is an integer. That documentation has to be updated so that LINE can be either an integer() or a tuple(integer(),integer()), and a reference to use erl_parse:set/get_attribute to manipulate it safely. >> >> The compiler should also be updated to use these API's, this includes the convention that a line number of -1 is used to say that something is compiler generated. To make sure that all uses of the non-api is eliminated, it might be a good idea to declare erl_scan:line as -opaque and let dialyzer search through the otp code for errors. >> >> [1]: http://www.erlang.org/doc/apps/erts/absform.html >> [2]: http://www.erlang.org/doc/man/erl_scan.html#type-line > I replaced LINE by LOC in the first documentation you point to and I've patched various type specs in erl_scan and erl_parse so they both use location(). > > With regard to negative line numbers, it should be noted that user-supplied -file attributes have their line numbers negated whereas as you said in other modules like erl_lint and v3_core, compile-generated nodes are the ones which lines are negated. Shouldn't the opposite be done in epp's -file attributes handling? > >>> If it is really that heavy of a change, why do we have erl_scan:set_attribute/3 and erl_scan:attributes_info/{1,2}? They obviously were coded to mitigate these issues. >> We have indeed been working on getting this to work before, but the effort was left as you see it now because there were a number of issues which needed solving and more important things got in the way. The reason why I say it is a heavy change is that we want to feel that a good effort has been made to make sure that all error and warning column numbers point to the correct position. > I've already added a 'file' item to these functions to improve the code populating every node with the file from the -file attributes of the module declaration in erl_lint; maybe another 'generated' item should be added to replace the multiple neg_line and abs_line functions there are in some compile-related modules? > >>> Any parse transform that break because of this change will break because it does AST manipulation wrong and their users will just have to not use the "column" option for it to continue to work. >> Strictly speaking parse transform is also an experimental/undocumented feature of Erlang/OTP. But unfortunately a lot of people seem to use them, so we have to take some backwards compatibility into consideration. The closest thing to a documentation is the example found here lib/stdlib/example/erl_id_trans.erl, and that does not deal with line numbers at all. >> >> We really really have to be sure that the fun2ms and qlc parse transforms work. > I've read through the code of various parse transforms this week and they don't seem to make anything related to the transformed nodes' locations. Most OTP-provided parse transforms are covered in the test suites I patched. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From sverker.eriksson@REDACTED Wed Sep 5 13:28:18 2012 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Wed, 5 Sep 2012 13:28:18 +0200 Subject: [erlang-patches] Crypto RIPEMD-160 Support In-Reply-To: References: <503E2C29.7080808@erlang.org> Message-ID: <50473752.6050908@erix.ericsson.se> Michael Loftis wrote: > On Wed, Aug 29, 2012 at 8:50 AM, Henrik Nord wrote: > >> There is one in 'pu' actually it is just taking a small break outside of >> it. >> >> git fetch git://github.com/ahf/otp.git feature-crypto-ripemd160 >> >> af/feature-crypto-ripemd160 >> >> @Alexander: would you mind rebasing it on R15B02 after the release next >> week? >> > > Excellent, many thanks. I'll keep an eye out for it to make it onto > the official crypto app! > > > When rebasing this patch onto R15B02, the API should be changed to make use of the new functions hash/2, hash_init/1, hash_update/2, hash_final/1 that was introduced in R15B02. /Sverker, Erlang/OTP From ahf@REDACTED Wed Sep 5 13:30:30 2012 From: ahf@REDACTED (=?ISO-8859-1?Q?Alexander_F=E6r=F8y?=) Date: Wed, 5 Sep 2012 13:30:30 +0200 Subject: [erlang-patches] Crypto RIPEMD-160 Support In-Reply-To: <50473752.6050908@erix.ericsson.se> References: <503E2C29.7080808@erlang.org> <50473752.6050908@erix.ericsson.se> Message-ID: On 5 September 2012 13:28, Sverker Eriksson wrote: > When rebasing this patch onto R15B02, the API should be changed to make use > of the new functions hash/2, hash_init/1, hash_update/2, hash_final/1 that > was introduced in R15B02. Cool. I will take a look at it. I also noticed that I do some unnecessary type-casting in my code which I will clean up during the rebase. Cheers, Alex. -- Alexander F?r?y From henrik@REDACTED Wed Sep 5 14:49:03 2012 From: henrik@REDACTED (Henrik Nord) Date: Wed, 5 Sep 2012 14:49:03 +0200 Subject: [erlang-patches] SSL Next Protocol Negotiation Patch In-Reply-To: References: Message-ID: <50474A3F.2010107@erlang.org> Would you mind rebaseing this upon the latest master branch? /Henrik On 12/11/2011 07:29 PM, Ben Murphy wrote: > I have a branch that implements Next Protocol Negotiation for SSL > (http://technotes.googlecode.com/git/nextprotoneg.html). The protocol > is requirement for SPDY which is an alternative to HTTP that google is > pushing. > > git fetch git://github.com/benmmurphy/otp.git ssl_npn > https://github.com/benmmurphy/otp/compare/ssl_npn > https://github.com/benmmurphy/otp/compare/ssl_npn.patch > > I ran the SSL tests against 'OpenSSL 0.9.8r 8 Feb 2011' and they all > passed but my npn tests were skipped because that version does not > support npn. When i ran my tests against 'OpenSSL SNAP-20111130' my > npn tests ran fine but another test failed > (erlang_server_openssl_client_no_wrap_sequence_number). If i run > master against that version of OpenSSL that test fails as well. It > appears that OpenSSL client for that version will send the current > session id as the suggested session id and this results in the session > id not changing during renegotiation. Also, some of the openssl NPN > tests will fail if they are run with a version of openssl that > supports NPN and has a broken NPN renegotiation implementation. I > think the 1.0.x series is like this. (change set where it was fixed in > openssl: http://cvs.openssl.org/chngview?cn=21760) > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From daniel.goertzen@REDACTED Wed Sep 5 16:13:03 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Wed, 5 Sep 2012 09:13:03 -0500 Subject: [erlang-patches] ssh synchronous eof In-Reply-To: <503F15DB.2040902@erix.ericsson.se> References: <503F15DB.2040902@erix.ericsson.se> Message-ID: Here is a new ssh suite that tests some of the functionality of ssh_connection. It is based on the ssh_to_openssh_SUITE. There are presently 2 failing test cases: "big_cat" shows ssh_connection:send() behaving asynchronously for large sends. This is the issue I was talking about earlier in this thread. "send_after_exit" shows that ssh_connection:send() does not report an appropriate {error, closed} if send() is attempted after a channel is closed. I have a use case in my project that really needs a proper {error, closed}. I will start working on fixes for both of these. (Oops, just saw your patch. I will give it a try.) Cheers, Dan. git fetch git@REDACTED:goertzenator/otp.git ssh_connection_suite https://github.com/goertzenator/otp/compare/ssh_connection_suite https://github.com/goertzenator/otp/compare/ssh_connection_suite.patch On Thu, Aug 30, 2012 at 2:27 AM, Ingela Anderton Andin < ingela.anderton.andin@REDACTED> wrote: > Hi! > > > Daniel Goertzen wrote: > >> After looking through the SSH code and learning more about it, I feel >> this patch is solving the wrong problem. The REAL problem is that >> ssh_connection:send() is supposed to be synchronous, but is actually not in >> some cases. >> >> send() will be synchronous only if the given data will fit in the channel >> send window. Any data beyond that will be sent asynchronously. So if you >> send a very large binary, or repeatedly send smaller binaries you will run >> into this problem. >> >> The minimum ssh packet size mandated by the RFCs is 32kB, so the minimum >> window is the same. OpenSSH gives me a send window of approx 200kB. For >> most of the applications that people use SSH for, the send window never >> gets overrun and you never see asynchronous send behavior out of Erlang SSH. >> >> Ingela, I'm inclined to write some failing test cases for this and some >> other problems I've seen. Would this be helpful? I have some ideas about >> how to fix the problems, but I may not have time to actually fix them. >> >> > Yes it would be helpful. Then I will not include your patch. The remote > id fix is already added. And we can investigate this other problem further > I may need to refresh my ssh > RFC knowledge too. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew@REDACTED Thu Sep 6 03:12:01 2012 From: matthew@REDACTED (Matthew Dempsky) Date: Wed, 5 Sep 2012 18:12:01 -0700 Subject: [erlang-patches] Erlang build issue on OpenBSD -current In-Reply-To: References: Message-ID: In the mean time, I committed a slight tweak to this to OpenBSD's ports tree, just additionally defining DED_LD_FLAG_RUNTIME_LIBRARY_PATH as "$CFLAG_RUNTIME_LIBRARY_PATH". Patch available at http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/erlang/patches/patch-erts_configure_in?annotate=1.6. On Tue, Sep 4, 2012 at 11:58 AM, Matthew Dempsky wrote: > On OpenBSD, shared objects should be linked with "cc -shared", not "ld > -shared". This is particularly important now that OpenBSD's C > compiler emits code that depends on crtbeginS.o/crtendS.o much more > frequently than before, and those object files are not linked in by > default when "ld -shared". > > Diff below tested on OpenBSD 5.2-current. Excuse the sloppy > copy/paste whitespace, but it's a trivial patch and I think it needs > to be applied to erts/configure.in instead of erts/configure anyway. > > Cheers! > > --- erts/configure.orig Tue Sep 4 11:35:01 2012 > +++ erts/configure Tue Sep 4 11:35:01 2012 > @@ -35122,6 +35122,10 @@ case $host_os in > DED_LDFLAGS="-m32 $DED_LDFLAGS" > fi > ;; > + openbsd*) > + DED_LD="$CC" > + DED_LDFLAGS="-shared" > + ;; > osf*) > # NOTE! Whitespace after -rpath is important. > DED_LD_FLAG_RUNTIME_LIBRARY_PATH="-rpath " From egil@REDACTED Thu Sep 6 11:46:04 2012 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 6 Sep 2012 11:46:04 +0200 Subject: [erlang-patches] Erlang build issue on OpenBSD -current In-Reply-To: References: Message-ID: <504870DC.9040905@erlang.org> On 2012-09-04 20:58, Matthew Dempsky wrote: > On OpenBSD, shared objects should be linked with "cc -shared", not "ld > -shared". This is particularly important now that OpenBSD's C > compiler emits code that depends on crtbeginS.o/crtendS.o much more > frequently than before, and those object files are not linked in by > default when "ld -shared". > > Diff below tested on OpenBSD 5.2-current. Excuse the sloppy > copy/paste whitespace, but it's a trivial patch and I think it needs > to be applied to erts/configure.in instead of erts/configure anyway. > > Cheers! > > --- erts/configure.orig Tue Sep 4 11:35:01 2012 > +++ erts/configure Tue Sep 4 11:35:01 2012 > @@ -35122,6 +35122,10 @@ case $host_os in > DED_LDFLAGS="-m32 $DED_LDFLAGS" > fi > ;; > + openbsd*) > + DED_LD="$CC" > + DED_LDFLAGS="-shared" > + ;; > osf*) > # NOTE! Whitespace after -rpath is important. > DED_LD_FLAG_RUNTIME_LIBRARY_PATH="-rpath " Thank you for reporting this. I'll create a ticket and fix for it. // Bj?rn-Egil Erlang/OTP > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From boris@REDACTED Thu Sep 6 21:38:39 2012 From: boris@REDACTED (Boris Faure) Date: Thu, 6 Sep 2012 21:38:39 +0200 Subject: [erlang-patches] custom LDFLAGS ignored Message-ID: <20120906193839.GA49035@apocatequil.fau.re> Hi, While writing an ebuild to compile latest erlang release on gentoo, I noticed a few binaries are linked ignoring custom LDFLAGS. You can get the patch targeting the maint branch with: git fetch git://github.com/billiob/otp.git maint Best Regards -- Boris Faure Pointer Arithmetician From henrik@REDACTED Fri Sep 7 10:49:15 2012 From: henrik@REDACTED (Henrik Nord) Date: Fri, 7 Sep 2012 10:49:15 +0200 Subject: [erlang-patches] Bugfix to snmpTargetAddrExtTable In-Reply-To: <1346682405.2982.10.camel@ax-sze> References: <1346682405.2982.10.camel@ax-sze> Message-ID: <5049B50B.1060704@erlang.org> I have added your patch to 'pu' Thank you for your contribution! On 09/03/2012 04:26 PM, Stefan Zegenhagen wrote: > Dear all, > > snmpTargetAddrExtTable instrumentation in snmp_community_mib.erl can > pass error return values with invalid column numbers to the SNMP engine > in response to set requests. The problem arises as follows: > > * snmpTargetAddrExtTable columns are stored in the appropriate row > of snmpTargetAddrTable starting at column 11 > * snmpTargetAddrExtTable instrumentation does some basic checks of > the column data in set requests, adds 10 to each column number > (maps to the corresponding columns in snmpTargetAddrTable > storage) and passes the data to the generic SNMP table handler, > changing the table name to snmpTargetAddrTable > * errors from the generic SNMP table handler are returned as-is, > including column numbers+10 > * the SNMP engine detects invalid column numbers returned from > snmpTargetAddrExtTable instrumentation and emits a genErr error > report > > The resulting genErr obscures the real problem behind the set-request. > > The patch attached to this e-mail solves the problem by inspecting the > result from the generic SNMP table handler and by converting the column > numbers back to the allowed range in case of error responses. > > > Kind regards, > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Fri Sep 7 10:49:23 2012 From: henrik@REDACTED (Henrik Nord) Date: Fri, 7 Sep 2012 10:49:23 +0200 Subject: [erlang-patches] SNMP: fix wrong error code for invalid get requests In-Reply-To: <1346682581.2982.13.camel@ax-sze> References: <1346682581.2982.13.camel@ax-sze> Message-ID: <5049B513.5010700@erlang.org> I have added your patch to 'pu' Thank you for your contribution! On 09/03/2012 04:29 PM, Stefan Zegenhagen wrote: > Dear all, > > when an SNMP get request references an existing scalar variable without > instance OID (e.g. sysName instead of sysName.0), the erlang SNMP agent > returns a noSuchObject error instead of the correct noSuchInstance > error. Some SNMP test suites flag this as error. > > The patch attached to this e-mail solves the problem by letting the OID > lookup routine return the correct noSuchInstance error. > > Kind regards, > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Fri Sep 7 10:49:33 2012 From: henrik@REDACTED (Henrik Nord) Date: Fri, 7 Sep 2012 10:49:33 +0200 Subject: [erlang-patches] SNMP: Bugfix to usmUserStorageType semantics In-Reply-To: <1346830944.2982.18.camel@ax-sze> References: <1346830944.2982.18.camel@ax-sze> Message-ID: <5049B51D.70807@erlang.org> I have added your patch to 'pu' Thank you for your contribution! On 09/05/2012 09:42 AM, Stefan Zegenhagen wrote: > Dear all, > > > the SNMP-USER-BASED-SM MIB dictates that the storage type of a user > entry in usmUserTable must not be readOnly if authentication or privacy > are enabled for the user, because the user must be able to change > his/her password. > > The patch attached to this e-mail implements the necessary check. > > > Kind regards, > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Fri Sep 7 22:23:19 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 7 Sep 2012 15:23:19 -0500 Subject: [erlang-patches] possible SSH auth methods typo Message-ID: While bug hunting my own app, I noted the default supported auth methods for the erlang SSH app are... "publickey,keyboard_interactive,password" I *think* that underscore is supposed to be a hyphen. My app does not use that codepath, so I can't tell if it changes anything. Patch info below: git fetch git://github.com/goertzenator/otp.git keyboard_interactive https://github.com/goertzenator/otp/compare/keyboard_interactive https://github.com/goertzenator/otp/compare/keyboard_interactive.patch Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Fri Sep 7 23:21:08 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 7 Sep 2012 16:21:08 -0500 Subject: [erlang-patches] hi-res windows icon Message-ID: The Windows erlang application icon looks a little blocky, especially when you have the text size turned up, so I added some higher resolution images. I grabbed the image from http://www.erlang.org/doc/ , and used paint.netand icofx to add true color 256x256, 48x48, and 32x32 images to the icon. I implanted this icon into werl.exe using icofx; I am not prepared to figure out compiling Erlang on Windows. See attached comparison of old and new. It is on the fuzzy side and could use some hand-crafting from an actual artist, but I find this one less jarring than the old one. Patch below... Dan. git fetch git://github.com/goertzenator/otp.git win_icon https://github.com/goertzenator/otp/compare/win_icon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: erlang_win_icon_comparison.png Type: image/png Size: 26573 bytes Desc: not available URL: From n.oxyde@REDACTED Sun Sep 9 12:52:22 2012 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 9 Sep 2012 12:52:22 +0200 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: <50471240.3060005@erlang.org> References: <610BC6F9-18BF-46A2-B487-492A9B41E42A@gmail.com> <4FCE3186.3000202@erlang.org> <5034FB10.7090804@erlang.org> <503CC79B.2020009@erlang.org> <50471240.3060005@erlang.org> Message-ID: Hi, I've rebased it against the latest maint branch. Please refetch. On Wed, Sep 5, 2012 at 10:50 AM, Henrik Nord wrote: > > I would like you to rebase this on R15B02 after the release. > /Henrik > > On 09/02/2012 08:26 PM, Anthony Ramine wrote: >> >> Hi, >> >> Again, see responses inlined; please refetch. >> >> Regards. >> >> -- >> Anthony Ramine >> >> Le 28 ao?t 2012 ? 15:28, Lukas Larsson a ?crit : >> >>> Hello, >>> >>> See responses inlined. >>> >>> Lukas >>> >>> On 24/08/12 12:22, Anthony Ramine wrote: >>>> >>>> Most OTP (at least erl_lint, erl_parse and syntax_tools) already knows >>>> that locations can be a line or a line and a column; furthermore it is said >>>> in erl_parse itself that one should always use get_line/1 and set_line/3 >>>> instead of depending on having an integer there. >>> >>> It does indeed say so inside the code of erl_parse. But all of the >>> visible documentation (here[1] and here[2]) say that it is an integer. So if >>> you have only read the documentation (which I assume most people only have) >>> you would assume that it is an integer. That documentation has to be updated >>> so that LINE can be either an integer() or a tuple(integer(),integer()), and >>> a reference to use erl_parse:set/get_attribute to manipulate it safely. >>> >>> The compiler should also be updated to use these API's, this includes >>> the convention that a line number of -1 is used to say that something is >>> compiler generated. To make sure that all uses of the non-api is eliminated, >>> it might be a good idea to declare erl_scan:line as -opaque and let dialyzer >>> search through the otp code for errors. >>> >>> [1]: http://www.erlang.org/doc/apps/erts/absform.html >>> [2]: http://www.erlang.org/doc/man/erl_scan.html#type-line >> >> I replaced LINE by LOC in the first documentation you point to and I've >> patched various type specs in erl_scan and erl_parse so they both use >> location(). >> >> With regard to negative line numbers, it should be noted that >> user-supplied -file attributes have their line numbers negated whereas as >> you said in other modules like erl_lint and v3_core, compile-generated nodes >> are the ones which lines are negated. Shouldn't the opposite be done in >> epp's -file attributes handling? >> >>>> If it is really that heavy of a change, why do we have >>>> erl_scan:set_attribute/3 and erl_scan:attributes_info/{1,2}? They obviously >>>> were coded to mitigate these issues. >>> >>> We have indeed been working on getting this to work before, but the >>> effort was left as you see it now because there were a number of issues >>> which needed solving and more important things got in the way. The reason >>> why I say it is a heavy change is that we want to feel that a good effort >>> has been made to make sure that all error and warning column numbers point >>> to the correct position. >> >> I've already added a 'file' item to these functions to improve the code >> populating every node with the file from the -file attributes of the module >> declaration in erl_lint; maybe another 'generated' item should be added to >> replace the multiple neg_line and abs_line functions there are in some >> compile-related modules? >> >>>> Any parse transform that break because of this change will break >>>> because it does AST manipulation wrong and their users will just have to not >>>> use the "column" option for it to continue to work. >>> >>> Strictly speaking parse transform is also an experimental/undocumented >>> feature of Erlang/OTP. But unfortunately a lot of people seem to use them, >>> so we have to take some backwards compatibility into consideration. The >>> closest thing to a documentation is the example found here >>> lib/stdlib/example/erl_id_trans.erl, and that does not deal with line >>> numbers at all. >>> >>> We really really have to be sure that the fun2ms and qlc parse >>> transforms work. >> >> I've read through the code of various parse transforms this week and they >> don't seem to make anything related to the transformed nodes' locations. >> Most OTP-provided parse transforms are covered in the test suites I patched. >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > > -- > /Henrik Nord Erlang/OTP > From henrik@REDACTED Mon Sep 10 10:25:50 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 10 Sep 2012 10:25:50 +0200 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: References: <610BC6F9-18BF-46A2-B487-492A9B41E42A@gmail.com> <4FCE3186.3000202@erlang.org> <5034FB10.7090804@erlang.org> <503CC79B.2020009@erlang.org> <50471240.3060005@erlang.org> Message-ID: <504DA40E.2070807@erlang.org> Thank you! I have refetched this On 09/09/2012 12:52 PM, Anthony Ramine wrote: > Hi, > > I've rebased it against the latest maint branch. Please refetch. > > On Wed, Sep 5, 2012 at 10:50 AM, Henrik Nord wrote: >> I would like you to rebase this on R15B02 after the release. >> /Henrik >> >> On 09/02/2012 08:26 PM, Anthony Ramine wrote: >>> Hi, >>> >>> Again, see responses inlined; please refetch. >>> >>> Regards. >>> >>> -- >>> Anthony Ramine >>> >>> Le 28 ao?t 2012 ? 15:28, Lukas Larsson a ?crit : >>> >>>> Hello, >>>> >>>> See responses inlined. >>>> >>>> Lukas >>>> >>>> On 24/08/12 12:22, Anthony Ramine wrote: >>>>> Most OTP (at least erl_lint, erl_parse and syntax_tools) already knows >>>>> that locations can be a line or a line and a column; furthermore it is said >>>>> in erl_parse itself that one should always use get_line/1 and set_line/3 >>>>> instead of depending on having an integer there. >>>> It does indeed say so inside the code of erl_parse. But all of the >>>> visible documentation (here[1] and here[2]) say that it is an integer. So if >>>> you have only read the documentation (which I assume most people only have) >>>> you would assume that it is an integer. That documentation has to be updated >>>> so that LINE can be either an integer() or a tuple(integer(),integer()), and >>>> a reference to use erl_parse:set/get_attribute to manipulate it safely. >>>> >>>> The compiler should also be updated to use these API's, this includes >>>> the convention that a line number of -1 is used to say that something is >>>> compiler generated. To make sure that all uses of the non-api is eliminated, >>>> it might be a good idea to declare erl_scan:line as -opaque and let dialyzer >>>> search through the otp code for errors. >>>> >>>> [1]: http://www.erlang.org/doc/apps/erts/absform.html >>>> [2]: http://www.erlang.org/doc/man/erl_scan.html#type-line >>> I replaced LINE by LOC in the first documentation you point to and I've >>> patched various type specs in erl_scan and erl_parse so they both use >>> location(). >>> >>> With regard to negative line numbers, it should be noted that >>> user-supplied -file attributes have their line numbers negated whereas as >>> you said in other modules like erl_lint and v3_core, compile-generated nodes >>> are the ones which lines are negated. Shouldn't the opposite be done in >>> epp's -file attributes handling? >>> >>>>> If it is really that heavy of a change, why do we have >>>>> erl_scan:set_attribute/3 and erl_scan:attributes_info/{1,2}? They obviously >>>>> were coded to mitigate these issues. >>>> We have indeed been working on getting this to work before, but the >>>> effort was left as you see it now because there were a number of issues >>>> which needed solving and more important things got in the way. The reason >>>> why I say it is a heavy change is that we want to feel that a good effort >>>> has been made to make sure that all error and warning column numbers point >>>> to the correct position. >>> I've already added a 'file' item to these functions to improve the code >>> populating every node with the file from the -file attributes of the module >>> declaration in erl_lint; maybe another 'generated' item should be added to >>> replace the multiple neg_line and abs_line functions there are in some >>> compile-related modules? >>> >>>>> Any parse transform that break because of this change will break >>>>> because it does AST manipulation wrong and their users will just have to not >>>>> use the "column" option for it to continue to work. >>>> Strictly speaking parse transform is also an experimental/undocumented >>>> feature of Erlang/OTP. But unfortunately a lot of people seem to use them, >>>> so we have to take some backwards compatibility into consideration. The >>>> closest thing to a documentation is the example found here >>>> lib/stdlib/example/erl_id_trans.erl, and that does not deal with line >>>> numbers at all. >>>> >>>> We really really have to be sure that the fun2ms and qlc parse >>>> transforms work. >>> I've read through the code of various parse transforms this week and they >>> don't seem to make anything related to the transformed nodes' locations. >>> Most OTP-provided parse transforms are covered in the test suites I patched. >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> >> -- >> /Henrik Nord Erlang/OTP >> -- /Henrik Nord Erlang/OTP From henrik@REDACTED Mon Sep 10 15:11:54 2012 From: henrik@REDACTED (Henrik Nord) Date: Mon, 10 Sep 2012 15:11:54 +0200 Subject: [erlang-patches] hi-res windows icon In-Reply-To: References: Message-ID: <504DE71A.9000402@erlang.org> Thank you for the contribution. If it all still works I do not see any problems with including this. On 09/07/2012 11:21 PM, Daniel Goertzen wrote: > The Windows erlang application icon looks a little blocky, especially > when you have the text size turned up, so I added some higher > resolution images. > > I grabbed the image from http://www.erlang.org/doc/ , and used > paint.net and icofx to add true color 256x256, > 48x48, and 32x32 images to the icon. > > I implanted this icon into werl.exe using icofx; I am not prepared to > figure out compiling Erlang on Windows. See attached comparison of > old and new. > > It is on the fuzzy side and could use some hand-crafting from an > actual artist, but I find this one less jarring than the old one. > > Patch below... > > Dan. > > > > git fetch git://github.com/goertzenator/otp.git > win_icon > > https://github.com/goertzenator/otp/compare/win_icon > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Tue Sep 11 09:34:21 2012 From: henrik@REDACTED (Henrik Nord) Date: Tue, 11 Sep 2012 09:34:21 +0200 Subject: [erlang-patches] possible SSH auth methods typo In-Reply-To: References: Message-ID: <504EE97D.8050100@erlang.org> Thank you for your contribution. This will be included in the next major release. On 09/07/2012 10:23 PM, Daniel Goertzen wrote: > git fetch git://github.com/goertzenator/otp.git > keyboard_interactive -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Sep 19 10:05:21 2012 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 19 Sep 2012 10:05:21 +0200 Subject: [erlang-patches] add code:get_mode/0 Message-ID: Hi, I have a small feature to suggest: add code:get_mode() to detect how the code servers behaves, returning embedded, interactive or minimal. Rationale: Some applications (like erlide) have code to be loaded dynamically on a node. It may be slow to load everything upfront every time, so if the node is in interactive mode, we would like to just append to the load path. Currently, there is no direct way to detect if the node is running in embedded mode or not. git fetch git://github.com/vladdu/otp.git code_get_mode https://github.com/vladdu/otp/compare/code_get_mode https://github.com/vladdu/otp/compare/code_get_mode.patch Since it is a very small, trivial addition, no tests are provided, but I can do it on request. best regards, Vlad From vladdu55@REDACTED Wed Sep 19 11:19:28 2012 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 19 Sep 2012 11:19:28 +0200 Subject: [erlang-patches] jinterface: OtpEpmd.get Message-ID: Hi, I found a problem with OtpEpmd if the network is badly configured: In an enterprise environment, it's not an easy task to get the machine configuration corrected. On some machines with weird network configurations, InetAddress.getLocalHost() hangs. Searching for "localhost" works (at least in the cases I met). The difference is that the loopback address will be returned, instead of the real IP address, but for the local machine this should not be a problem. git fetch git://github.com/vladdu/otp.git jinterface_epmd_localhost https://github.com/vladdu/otp/compare/jinterface_epmd_localhost https://github.com/vladdu/otp/compare/jinterface_epmd_localhost.patch I don't know how to configure the network to provoke the problem, but I just got confirmation from someone that has it that with this fix everything works as expected. [Note that for this user, "erl -sname foo" and "erl -sname bar" can't connect to each other, one has to use "erl -sname foo@REDACTED"] There are no tests covering OtpEpmd, would this change require any? best regards, Vlad From n.oxyde@REDACTED Wed Sep 19 19:28:58 2012 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 19 Sep 2012 19:28:58 +0200 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: <50598C38.8060506@erlang.org> References: <610BC6F9-18BF-46A2-B487-492A9B41E42A@gmail.com> <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> Message-ID: Hi, I've documented the 'file' attribute item in the branch's first commit and reordered some erl_scan commits; please refetch. -- Anthony Ramine Le 19 sept. 2012 ? 11:11, Henrik Nord a ?crit : > done > On 09/14/2012 03:41 PM, Anthony Ramine wrote: >> Hi, >> >> I've rewritten the erl_lint_SUITE patch with less formatting changes so the diff is clearer; please refetch. >> >> Regards, >> >> -- >> Anthony Ramine >> >> >> Le 13 sept. 2012 ? 10:54, Henrik Nord a ?crit : >> >>> Refetched. >>> >>> On 09/11/2012 12:13 PM, Anthony Ramine wrote: >>>> Fixed, please refetch. Sorry for the inconvenience; I tried to remove every duplicate definition of erl_scan:error_info() and forgot to update the docs. >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> >>>> >>>> >>>> Le 10 sept. 2012 ? 16:02, Henrik Nord a ?crit : >>>> >>>>> build error >>>>> >>>>> >>>>> >>>>> date=`date +"%B %e %Y"`; \ >>>>> xsltproc --output "../man6/stdlib.6" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl stdlib_app.xml >>>>> /usr/bin/install -c -m 644 ushell1.gif ../html/ushell1.gif >>>>> /usr/bin/install -c -m 644 ushell2.gif ../html/ushell2.gif >>>>> /usr/bin/install -c -m 644 ushell3.gif ../html/ushell3.gif >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_array.xml; \ >>>>> xsltproc --output "../man3/array.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl array.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_base64.xml; \ >>>>> xsltproc --output "../man3/base64.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl base64.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_beam_lib.xml; \ >>>>> xsltproc --output "../man3/beam_lib.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl beam_lib.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_binary.xml; \ >>>>> xsltproc --output "../man3/binary.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl binary.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_c.xml; \ >>>>> xsltproc --output "../man3/c.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl c.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_calendar.xml; \ >>>>> xsltproc --output "../man3/calendar.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl calendar.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_dets.xml; \ >>>>> xsltproc --output "../man3/dets.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl dets.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_dict.xml; \ >>>>> xsltproc --output "../man3/dict.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl dict.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_digraph.xml; \ >>>>> xsltproc --output "../man3/digraph.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl digraph.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_digraph_utils.xml; \ >>>>> xsltproc --output "../man3/digraph_utils.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl digraph_utils.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_epp.xml; \ >>>>> xsltproc --output "../man3/epp.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl epp.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_erl_eval.xml; \ >>>>> xsltproc --output "../man3/erl_eval.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl erl_eval.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_erl_expand_records.xml; \ >>>>> xsltproc --output "../man3/erl_expand_records.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl erl_expand_records.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_erl_id_trans.xml; \ >>>>> xsltproc --output "../man3/erl_id_trans.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl erl_id_trans.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_erl_internal.xml; \ >>>>> xsltproc --output "../man3/erl_internal.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl erl_internal.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_erl_lint.xml; \ >>>>> xsltproc --output "../man3/erl_lint.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl erl_lint.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_erl_parse.xml; \ >>>>> xsltproc --output "../man3/erl_parse.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl erl_parse.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_erl_pp.xml; \ >>>>> xsltproc --output "../man3/erl_pp.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl erl_pp.xml >>>>> date=`date +"%B %e %Y"`; \ >>>>> specs_file=`pwd`/../specs/specs_erl_scan.xml; \ >>>>> xsltproc --output "../man3/erl_scan.3" --stringparam company "Ericsson AB" --stringparam docgen "/ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen" --stringparam gendate "$date" --stringparam appname "stdlib" --stringparam appver "1.18.3" --stringparam specs_file "$specs_file" --xinclude -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd -path /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/dtd_man_entities /ldisk/jenkins/jobs/compile-pu/workspace/lib/erl_docgen/priv/xsl/db_man.xsl erl_scan.xml >>>>> >>>>> Error in erl_parse:error_description: unknown type >>>>> make[4]: *** [../man3/erl_parse.3] Error 10 >>>>> make[4]: *** Waiting for unfinished jobs.... >>>>> make[4]: Leaving directory `/ldisk/jenkins/jobs/compile-pu/workspace/lib/stdlib/doc/src' >>>>> make[3]: *** [release_docs] Error 2 >>>>> make[3]: Leaving directory `/ldisk/jenkins/jobs/compile-pu/workspace/lib/stdlib/doc/src' >>>>> make[2]: *** [release_docs] Error 2 >>>>> make[2]: Leaving directory `/ldisk/jenkins/jobs/compile-pu/workspace/lib/stdlib' >>>>> make[1]: *** [release_docs] Error 2 >>>>> make[1]: Leaving directory `/ldisk/jenkins/jobs/compile-pu/workspace/lib' >>>>> make: *** [release_docs] Error 2 >>>>> >>>>> On 09/09/2012 12:52 PM, Anthony Ramine wrote: >>>>>> Hi, >>>>>> >>>>>> I've rebased it against the latest maint branch. Please refetch. >>>>>> >>>>>> On Wed, Sep 5, 2012 at 10:50 AM, Henrik Nord wrote: >>>>>>> I would like you to rebase this on R15B02 after the release. >>>>>>> /Henrik >>>>>>> >>>>>>> On 09/02/2012 08:26 PM, Anthony Ramine wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Again, see responses inlined; please refetch. >>>>>>>> >>>>>>>> Regards. >>>>>>>> >>>>>>>> -- >>>>>>>> Anthony Ramine >>>>>>>> >>>>>>>> Le 28 ao?t 2012 ? 15:28, Lukas Larsson a ?crit : >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> See responses inlined. >>>>>>>>> >>>>>>>>> Lukas >>>>>>>>> >>>>>>>>> On 24/08/12 12:22, Anthony Ramine wrote: >>>>>>>>>> Most OTP (at least erl_lint, erl_parse and syntax_tools) already knows >>>>>>>>>> that locations can be a line or a line and a column; furthermore it is said >>>>>>>>>> in erl_parse itself that one should always use get_line/1 and set_line/3 >>>>>>>>>> instead of depending on having an integer there. >>>>>>>>> It does indeed say so inside the code of erl_parse. But all of the >>>>>>>>> visible documentation (here[1] and here[2]) say that it is an integer. So if >>>>>>>>> you have only read the documentation (which I assume most people only have) >>>>>>>>> you would assume that it is an integer. That documentation has to be updated >>>>>>>>> so that LINE can be either an integer() or a tuple(integer(),integer()), and >>>>>>>>> a reference to use erl_parse:set/get_attribute to manipulate it safely. >>>>>>>>> >>>>>>>>> The compiler should also be updated to use these API's, this includes >>>>>>>>> the convention that a line number of -1 is used to say that something is >>>>>>>>> compiler generated. To make sure that all uses of the non-api is eliminated, >>>>>>>>> it might be a good idea to declare erl_scan:line as -opaque and let dialyzer >>>>>>>>> search through the otp code for errors. >>>>>>>>> >>>>>>>>> [1]: http://www.erlang.org/doc/apps/erts/absform.html >>>>>>>>> [2]: http://www.erlang.org/doc/man/erl_scan.html#type-line >>>>>>>> I replaced LINE by LOC in the first documentation you point to and I've >>>>>>>> patched various type specs in erl_scan and erl_parse so they both use >>>>>>>> location(). >>>>>>>> >>>>>>>> With regard to negative line numbers, it should be noted that >>>>>>>> user-supplied -file attributes have their line numbers negated whereas as >>>>>>>> you said in other modules like erl_lint and v3_core, compile-generated nodes >>>>>>>> are the ones which lines are negated. Shouldn't the opposite be done in >>>>>>>> epp's -file attributes handling? >>>>>>>> >>>>>>>>>> If it is really that heavy of a change, why do we have >>>>>>>>>> erl_scan:set_attribute/3 and erl_scan:attributes_info/{1,2}? They obviously >>>>>>>>>> were coded to mitigate these issues. >>>>>>>>> We have indeed been working on getting this to work before, but the >>>>>>>>> effort was left as you see it now because there were a number of issues >>>>>>>>> which needed solving and more important things got in the way. The reason >>>>>>>>> why I say it is a heavy change is that we want to feel that a good effort >>>>>>>>> has been made to make sure that all error and warning column numbers point >>>>>>>>> to the correct position. >>>>>>>> I've already added a 'file' item to these functions to improve the code >>>>>>>> populating every node with the file from the -file attributes of the module >>>>>>>> declaration in erl_lint; maybe another 'generated' item should be added to >>>>>>>> replace the multiple neg_line and abs_line functions there are in some >>>>>>>> compile-related modules? >>>>>>>> >>>>>>>>>> Any parse transform that break because of this change will break >>>>>>>>>> because it does AST manipulation wrong and their users will just have to not >>>>>>>>>> use the "column" option for it to continue to work. >>>>>>>>> Strictly speaking parse transform is also an experimental/undocumented >>>>>>>>> feature of Erlang/OTP. But unfortunately a lot of people seem to use them, >>>>>>>>> so we have to take some backwards compatibility into consideration. The >>>>>>>>> closest thing to a documentation is the example found here >>>>>>>>> lib/stdlib/example/erl_id_trans.erl, and that does not deal with line >>>>>>>>> numbers at all. >>>>>>>>> >>>>>>>>> We really really have to be sure that the fun2ms and qlc parse >>>>>>>>> transforms work. >>>>>>>> I've read through the code of various parse transforms this week and they >>>>>>>> don't seem to make anything related to the transformed nodes' locations. >>>>>>>> Most OTP-provided parse transforms are covered in the test suites I patched. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> erlang-patches mailing list >>>>>>>> erlang-patches@REDACTED >>>>>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>>>> -- >>>>>>> /Henrik Nord Erlang/OTP >>>>>>> >>>>> -- >>>>> /Henrik Nord Erlang/OTP >>>>> >>> -- >>> /Henrik Nord Erlang/OTP >>> > > -- > /Henrik Nord Erlang/OTP > From andrew@REDACTED Wed Sep 19 23:23:27 2012 From: andrew@REDACTED (Andrew Thompson) Date: Wed, 19 Sep 2012 17:23:27 -0400 Subject: [erlang-patches] Fix binary printing for depth 1 Message-ID: <20120919212327.GD8089@hijacked.us> A case clause ordering problem is causing the empty binary to be printed as <<...>> rather than the correct <<>> when using ~W with a depth of 1. Add new tests to verify correct behaviour. git fetch git://github.com/Vagabond/otp.git adt-binary-depth-printing https://github.com/Vagabond/otp/compare/adt-binary-depth-printing https://github.com/Vagabond/otp/compare/adt-binary-depth-printing.patch See also this thread: http://erlang.org/pipermail/erlang-questions/2012-September/069043.html Andrew From henrik@REDACTED Thu Sep 20 09:49:21 2012 From: henrik@REDACTED (Henrik Nord) Date: Thu, 20 Sep 2012 09:49:21 +0200 Subject: [erlang-patches] Fix binary printing for depth 1 In-Reply-To: <20120919212327.GD8089@hijacked.us> References: <20120919212327.GD8089@hijacked.us> Message-ID: <505ACA81.1000303@erlang.org> Thank you for your contribution! I have added your patch to the master-pu branch On 09/19/2012 11:23 PM, Andrew Thompson wrote: > A case clause ordering problem is causing the empty binary to be > printed as <<...>> rather than the correct <<>> when using ~W with a > depth of 1. Add new tests to verify correct behaviour. > > git fetch git://github.com/Vagabond/otp.git adt-binary-depth-printing > > https://github.com/Vagabond/otp/compare/adt-binary-depth-printing > https://github.com/Vagabond/otp/compare/adt-binary-depth-printing.patch > > See also this thread: > > http://erlang.org/pipermail/erlang-questions/2012-September/069043.html > > Andrew > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Thu Sep 20 11:58:20 2012 From: henrik@REDACTED (Henrik Nord) Date: Thu, 20 Sep 2012 11:58:20 +0200 Subject: [erlang-patches] jinterface: OtpEpmd.get In-Reply-To: References: Message-ID: <505AE8BC.5020601@erlang.org> Hi (Raimo wrote) Could you try: + return lookupNames(InetAddress.getByName(null)); instead, as it is documented to return the loopback address. That would save us from surprises if "localhost" is strangely configured. The epmd will listen to * so locally using the loopback address should always work. If we one day change socket type (configurable) in OtpEpmd to inet6 I guess the corresponding ::1 address is returned by the above line. Thank you for your contributions! On 09/19/2012 11:19 AM, Vlad Dumitrescu wrote: > Hi, > > I found a problem with OtpEpmd if the network is badly configured: > > In an enterprise environment, it's not an easy task to get the machine > configuration corrected. > On some machines with weird network configurations, > InetAddress.getLocalHost() hangs. Searching for "localhost" works (at > least in the cases I met). The difference is that the loopback address > will be returned, instead of the real IP address, but for the local > machine this should not be a problem. > > > git fetch git://github.com/vladdu/otp.git jinterface_epmd_localhost > > https://github.com/vladdu/otp/compare/jinterface_epmd_localhost > https://github.com/vladdu/otp/compare/jinterface_epmd_localhost.patch > > I don't know how to configure the network to provoke the problem, but > I just got confirmation from someone that has it that with this fix > everything works as expected. > [Note that for this user, "erl -sname foo" and "erl -sname bar" can't > connect to each other, one has to use "erl -sname foo@REDACTED"] > > There are no tests covering OtpEpmd, would this change require any? > > best regards, > Vlad > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From vladdu55@REDACTED Thu Sep 20 12:09:05 2012 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 20 Sep 2012 12:09:05 +0200 Subject: [erlang-patches] jinterface: OtpEpmd.get In-Reply-To: <505AE8BC.5020601@erlang.org> References: <505AE8BC.5020601@erlang.org> Message-ID: Hi! Thanks for the hint. I'll try that. The only relevant tests are from users that have this configuration problem but it feels safe enough. regards, Vlad On Thu, Sep 20, 2012 at 11:58 AM, Henrik Nord wrote: > Hi > > (Raimo wrote) > Could you try: + return lookupNames(InetAddress.**getByName(null)); > instead, as it is documented to return the loopback address. That would > save us from surprises if "localhost" is strangely configured. The epmd > will listen to * so locally using the loopback address should always work. > If we one day change socket type (configurable) in OtpEpmd to inet6 I guess > the corresponding ::1 address is returned by the above line. > > Thank you for your contributions! > > > On 09/19/2012 11:19 AM, Vlad Dumitrescu wrote: > >> Hi, >> >> I found a problem with OtpEpmd if the network is badly configured: >> >> In an enterprise environment, it's not an easy task to get the machine >> configuration corrected. >> On some machines with weird network configurations, >> InetAddress.getLocalHost() hangs. Searching for "localhost" works (at >> least in the cases I met). The difference is that the loopback address >> will be returned, instead of the real IP address, but for the local >> machine this should not be a problem. >> >> >> git fetch git://github.com/vladdu/otp.**gitjinterface_epmd_localhost >> >> https://github.com/vladdu/otp/**compare/jinterface_epmd_**localhost >> https://github.com/vladdu/otp/**compare/jinterface_epmd_**localhost.patch >> >> I don't know how to configure the network to provoke the problem, but >> I just got confirmation from someone that has it that with this fix >> everything works as expected. >> [Note that for this user, "erl -sname foo" and "erl -sname bar" can't >> connect to each other, one has to use "erl -sname foo@REDACTED"] >> >> There are no tests covering OtpEpmd, would this change require any? >> >> best regards, >> Vlad >> ______________________________**_________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-patches >> > > -- > /Henrik Nord Erlang/OTP > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norton@REDACTED Sun Sep 23 15:16:14 2012 From: norton@REDACTED (Joseph Wayne Norton) Date: Sun, 23 Sep 2012 22:16:14 +0900 Subject: [erlang-patches] Export ets:match_pattern/0 type Message-ID: <7F97C37D-9E99-4071-AE51-35E3780CDE0A@lovely.email.ne.jp> https://github.com/norton/otp/commit/589e047e5558d965ca48f96eda3cd452b0627df2 $ git fetch git://github.com/norton/otp.git ets-match-pattern-export-type commit 589e047e5558d965ca48f96eda3cd452b0627df2 Author: Joseph Wayne Norton Date: Sun Sep 23 21:52:53 2012 +0900 Export ets:match_pattern/0 type Similar to match specification, some of the ets functions uses a match pattern. Export the match pattern type to allow for inclusion in the types and function specifications of other modules. From jeremy.heater@REDACTED Mon Sep 24 18:05:54 2012 From: jeremy.heater@REDACTED (Jeremy Heater) Date: Mon, 24 Sep 2012 18:05:54 +0200 Subject: [erlang-patches] ASN.1 Patch moving num_bits to compile-time Message-ID: Hello, Here is a proposed patch that moves asn1rt_uper_bin:num_bits/1 from the runtime to the compile-time (from asn1rt_uper_bin to asn1ct_gen_per and asn1ct_constructed_per).* *The bit number information is added to the SizeConstraint and ValueRange constraints when possible, and as another parameter in getchoice/3 and set_choice/3 (now getchoice/4 and set_choice/4 for the uper encoding). git fetch git://github.com/Kwisatx/otp.git move_num_bits_call_to_compilation https://github.com/Kwisatx/otp/compare/maint...move_num_bits_call_to_compilation https://github.com/Kwisatx/otp/compare/maint...move_num_bits_call_to_compilation.patch I tested the patch with an example written to call heavily on the num_bits function and got encouraging results (time measured with timer:tc to encode was 5 to 15% faster, and to decode was 3 to 4 times faster with the patch). Best regards, Jeremy Heater. PS: here's the ASN.1 grammar I used to test: NumBitsBench DEFINITIONS AUTOMATIC TAGS ::= BEGIN TestType ::= SEQUENCE { a SEQUENCE (SIZE (1..1000)) OF INTEGER(0..1000), b SEQUENCE (SIZE (1..100000)) OF INTEGER(0..100000), c SEQUENCE (SIZE (1..10000000)) OF INTEGER(0..10000000), d SEQUENCE (SIZE (1..1000000000)) OF INTEGER(0..1000000000), e SEQUENCE (SIZE (1..100000000000)) OF INTEGER(0..100000000000) } END* * -------------- next part -------------- An HTML attachment was scrubbed... URL: From aronisstav@REDACTED Wed Sep 26 11:11:09 2012 From: aronisstav@REDACTED (Stavros Aronis) Date: Wed, 26 Sep 2012 11:11:09 +0200 Subject: [erlang-patches] Dialyzer fixes Message-ID: Hi, This is a series of patches that fix all the crashes that were reported after the release of R15B02 version of OTP: git fetch git://github.com/aronisstav/otp.git dialyzer-fix Regards, Stavros -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Wed Sep 26 16:27:09 2012 From: james@REDACTED (James Wheare) Date: Wed, 26 Sep 2012 15:27:09 +0100 Subject: [erlang-patches] mnesia: Use chained send_after instead of send_interval Message-ID: Fetch command: git fetch git://github.com/jwheare/otp.git mnesia_interval_removal Compare: https://github.com/jwheare/otp/compare/mnesia_interval_removal Patch: https://github.com/jwheare/otp/compare/mnesia_interval_removal.patch mnesia_controller.erl | 15 +++++++++-- mnesia_recover.erl | 66 ++++++++++++++++++++++++++++---------------------- mnesia_tm.erl | 3 +- 1 commit, 3 files changed, 51 insertions(+), 33 deletions(-) --- mnesia: Use chained send_after instead of send_interval timer:send_interval behaves badly when resuming from sleep on some platforms. For example, if I sleep for 10 minutes, and have a send_interval running once per minute, when I resume, 10 messages will be sent immediately, eliminating the benefit of only running the work periodically. This is admittedly a separate bug with send_interval, but the workaround is straightforward, and also protects from messages piling up in the queue when the work takes longer than the interval. This patch fixes piled up error reports on resume from sleep: ** WARNING ** Mnesia is overloaded: {dump_log, write_threshold} You'll still be warned if mnesia is overloaded, just not repeatedly. Additionally, erlang:send_after is more efficient than using the timer module equivalent [1] [1] http://www.erlang.org/doc/efficiency_guide/commoncaveats.html#id57251 From daniel@REDACTED Wed Sep 26 16:50:26 2012 From: daniel@REDACTED (Daniel White) Date: Thu, 27 Sep 2012 00:50:26 +1000 Subject: [erlang-patches] Crypto documentation enhancements for HMAC types Message-ID: Had a few surprises with the documentation, particularly with HMAC-SHA256 being available but not realising until I dug into the code. The primary patch documents every type available to hmac_init. I'm less sure about whether the second patch as it adds an entry for each sha*_mac function. Is there a desire to keep both types of interface standard in the long run? Or is the more general hmac_init suitable enough? Patch info: git fetch git://github.com/danielwhite/otp.git enhance-crypto-hmac-documentation https://github.com/danielwhite/otp/compare/enhance-crypto-hmac-documentation https://github.com/danielwhite/otp/compare/enhance-crypto-hmac-documentation.patch Regards, -- Daniel White From sverker.eriksson@REDACTED Wed Sep 26 17:51:02 2012 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Wed, 26 Sep 2012 17:51:02 +0200 Subject: [erlang-patches] Crypto documentation enhancements for HMAC types In-Reply-To: References: Message-ID: <50632466.2040102@erix.ericsson.se> Daniel White wrote: > Had a few surprises with the documentation, particularly with > HMAC-SHA256 being available but not realising until I dug into the > code. > > The primary patch documents every type available to hmac_init. > > I'm less sure about whether the second patch as it adds an entry for > each sha*_mac function. Is there a desire to keep both types of > interface standard in the long run? Or is the more general hmac_init > suitable enough? > > I think I would prefer a generic hmac(Type, Key, Data) similar to hash(Type;Data) that was added in R15B02. /Sverker, Erlang/OTP From daniel@REDACTED Wed Sep 26 18:49:12 2012 From: daniel@REDACTED (Daniel White) Date: Thu, 27 Sep 2012 02:49:12 +1000 Subject: [erlang-patches] Crypto documentation enhancements for HMAC types In-Reply-To: <50632466.2040102@erix.ericsson.se> References: <50632466.2040102@erix.ericsson.se> Message-ID: On Thu, Sep 27, 2012 at 1:51 AM, Sverker Eriksson wrote: > Daniel White wrote: >> I'm less sure about whether the second patch as it adds an entry for >> each sha*_mac function. Is there a desire to keep both types of >> interface standard in the long run? Or is the more general hmac_init >> suitable enough? > > I think I would prefer a generic hmac(Type, Key, Data) similar to > hash(Type;Data) that was added in R15B02. > > /Sverker, Erlang/OTP > With that in mind, I've pushed a new branch, throwing away the documentation of the sha*_mac functions. This includes a generic interface to the hmac functions as the second patch. What is potentially missing are tests, as I wasn't sure how best to approach them in this context and hash/2 doesn't have any tests itself. I suspect some minimal sanity tests applied to both would be worthwhile, but only if necessary. Is an approach like this sensible? And is this more suited to master rather than maint? Patch info: git fetch git://github.com/danielwhite/otp.git crypto-hmac-enhancements.patch https://github.com/danielwhite/otp/compare/crypto-hmac-enhancements https://github.com/danielwhite/otp/compare/crypto-hmac-enhancements.patch Regards, -- Daniel White From aschultz@REDACTED Wed Sep 26 19:19:50 2012 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 26 Sep 2012 19:19:50 +0200 (CEST) Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <264751947.49623.1348679373058.JavaMail.root@tpip.net> Message-ID: <243075147.49636.1348679990473.JavaMail.root@tpip.net> Hi, I have implemented the more interesting parts of RFC 4279, RFC 5487 and RFC 5054 (aka TLS PSK and SRP ciphers). The use and usefulness of those ciphers is rather limited, the one notable exception being the eID server protocol for German national identity cards (nPA). The test suite can only verify some PSK suites against openssl as currently no openssl version supports them all. There is patch that add some to openssl, but it has not been incorporated into upstream. GNU-TLS implements some more (but not all) PSK suites and I have manually tested interoperability. Patch info: git fetch git://github.com/RoadRunnr/otp.git tls-psk-srp-suites https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch Regards 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 henrik@REDACTED Thu Sep 27 10:19:52 2012 From: henrik@REDACTED (Henrik Nord) Date: Thu, 27 Sep 2012 10:19:52 +0200 Subject: [erlang-patches] Dialyzer fixes In-Reply-To: References: Message-ID: <50640C28.4070507@erlang.org> Thank you Stavros, I have included this in 'pu' for R15B03 On 09/26/2012 11:11 AM, Stavros Aronis wrote: > Hi, > > This is a series of patches that fix all the crashes that were > reported after the release of R15B02 version of OTP: > > git fetch git://github.com/aronisstav/otp.git > dialyzer-fix > > Regards, > > Stavros > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Thu Sep 27 11:14:23 2012 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 27 Sep 2012 11:14:23 +0200 Subject: [erlang-patches] Crypto documentation enhancements for HMAC types In-Reply-To: References: <50632466.2040102@erix.ericsson.se> Message-ID: <506418EF.8020806@erix.ericsson.se> Daniel White wrote: > On Thu, Sep 27, 2012 at 1:51 AM, Sverker Eriksson > wrote: > >> Daniel White wrote: >> >>> I'm less sure about whether the second patch as it adds an entry for >>> each sha*_mac function. Is there a desire to keep both types of >>> interface standard in the long run? Or is the more general hmac_init >>> suitable enough? >>> >> I think I would prefer a generic hmac(Type, Key, Data) similar to >> hash(Type;Data) that was added in R15B02. >> >> /Sverker, Erlang/OTP >> >> > > With that in mind, I've pushed a new branch, throwing away the > documentation of the sha*_mac functions. > > This includes a generic interface to the hmac functions as the second > patch. What is potentially missing are tests, as I wasn't sure how > best to approach them in this context and hash/2 doesn't have any > tests itself. I suspect some minimal sanity tests applied to both > would be worthwhile, but only if necessary. > > I guess I didn't set a very good example, neglecting tests for the new hash_* functions. However, test case hmac_rfc4231 contains tests for all flavors of hmac functions (even the undocumeneted). You could add calls to your new hmac functions there and check that you get the same result. > Is an approach like this sensible? And is this more suited to master > rather than maint? > > Yes, as new functionality this is more suitable for master. /Sverker From henrik@REDACTED Fri Sep 28 10:26:01 2012 From: henrik@REDACTED (Henrik Nord) Date: Fri, 28 Sep 2012 10:26:01 +0200 Subject: [erlang-patches] ASN.1 Patch moving num_bits to compile-time In-Reply-To: References: Message-ID: <50655F19.5010808@erlang.org> Thank you for your contribution! I have rebased your branch on the 'master' branch and included it in 'master-pu' On 09/24/2012 06:05 PM, Jeremy Heater wrote: > Hello, > > Here is a proposed patch that moves asn1rt_uper_bin:num_bits/1 from > the runtime to the compile-time (from asn1rt_uper_bin to > asn1ct_gen_per and asn1ct_constructed_per)./ > /The bit number information is added to the SizeConstraint and > ValueRange constraints when possible, and as another parameter in > getchoice/3 and set_choice/3 (now getchoice/4 and set_choice/4 for the > uper encoding). > > git fetch git://github.com/Kwisatx/otp.git > move_num_bits_call_to_compilation > > https://github.com/Kwisatx/otp/compare/maint...move_num_bits_call_to_compilation > https://github.com/Kwisatx/otp/compare/maint...move_num_bits_call_to_compilation.patch > > I tested the patch with an example written to call heavily on the > num_bits function and got encouraging results (time measured with > timer:tc to encode was 5 to 15% faster, and to decode was 3 to 4 times > faster with the patch). > > Best regards, > Jeremy Heater. > > PS: here's the ASN.1 grammar I used to test: > > NumBitsBench DEFINITIONS AUTOMATIC TAGS ::= BEGIN > TestType ::= SEQUENCE { > a SEQUENCE (SIZE (1..1000)) OF INTEGER(0..1000), > b SEQUENCE (SIZE (1..100000)) OF INTEGER(0..100000), > c SEQUENCE (SIZE (1..10000000)) OF INTEGER(0..10000000), > d SEQUENCE (SIZE (1..1000000000)) OF INTEGER(0..1000000000), > e SEQUENCE (SIZE (1..100000000000)) OF INTEGER(0..100000000000) > } END/ > / > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Fri Sep 28 10:28:01 2012 From: henrik@REDACTED (Henrik Nord) Date: Fri, 28 Sep 2012 10:28:01 +0200 Subject: [erlang-patches] Export ets:match_pattern/0 type In-Reply-To: <7F97C37D-9E99-4071-AE51-35E3780CDE0A@lovely.email.ne.jp> References: <7F97C37D-9E99-4071-AE51-35E3780CDE0A@lovely.email.ne.jp> Message-ID: <50655F91.8090509@erlang.org> Thank you for your contribution, I have included this patch in 'master-pu' On 09/23/2012 03:16 PM, Joseph Wayne Norton wrote: > https://github.com/norton/otp/commit/589e047e5558d965ca48f96eda3cd452b0627df2 > > > $ git fetch git://github.com/norton/otp.git ets-match-pattern-export-type > > > commit 589e047e5558d965ca48f96eda3cd452b0627df2 > Author: Joseph Wayne Norton > Date: Sun Sep 23 21:52:53 2012 +0900 > > Export ets:match_pattern/0 type > > Similar to match specification, some of the ets functions uses a match > pattern. Export the match pattern type to allow for inclusion in the > types and function specifications of other modules. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From daniel@REDACTED Sat Sep 29 14:51:35 2012 From: daniel@REDACTED (Daniel White) Date: Sat, 29 Sep 2012 22:51:35 +1000 Subject: [erlang-patches] Crypto documentation enhancements for HMAC types In-Reply-To: <506418EF.8020806@erix.ericsson.se> References: <50632466.2040102@erix.ericsson.se> <506418EF.8020806@erix.ericsson.se> Message-ID: On Thu, Sep 27, 2012 at 7:14 PM, Sverker Eriksson wrote: > Daniel White wrote: >> >> On Thu, Sep 27, 2012 at 1:51 AM, Sverker Eriksson >> wrote: >> >>> >>> Daniel White wrote: >>> >>>> >>>> I'm less sure about whether the second patch as it adds an entry for >>>> each sha*_mac function. Is there a desire to keep both types of >>>> interface standard in the long run? Or is the more general hmac_init >>>> suitable enough? >>>> >>> >>> I think I would prefer a generic hmac(Type, Key, Data) similar to >>> hash(Type;Data) that was added in R15B02. >>> Ok, so I've updated the patchset to utilise the generic interface in the RFC-4231 tests, and also to utilise test vectors in RFC-2202 to test HMAC-MD5 and HMAC-SHA1. Additionally, the RFC-4231 tests now include the truncation test (test vector 5) to exercise that particular code-path (i.e. hmac/4). Patch info: git fetch git://github.com/danielwhite/otp.git crypto-hmac-enhancements https://github.com/danielwhite/otp/compare/erlang:master...danielwhite:crypto-hmac-enhancements https://github.com/danielwhite/otp/compare/erlang:master...danielwhite:crypto-hmac-enhancements.patch (Sorry about the dupe email, forgot to cc erlang-patches). Regards, -- Daniel White