From serge@REDACTED Fri Nov 1 05:58:56 2013 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 01 Nov 2013 00:58:56 -0400 Subject: [erlang-patches] Added net_kernel support for multiple transport protocols Message-ID: <52733510.1030305@aleynikov.org> Hi, [Note: this patch is submitted by email as as a pull request #121] Short problem description ========================= I want an Erlang node to listen on incoming connections using TCPv4, TCPv6, UDS, and TLS transports on different ports. I'd like other nodes to connect to this node using TLS if nodes are in external networks, use TCPv4 or TCPv6 if nodes are in the same subnet, and use UDS if nodes are on the same machine. Present implementation requires that all nodes in the network use the same transport, which is a huge limitation git fetch git://github.com/saleyn/otp.git proto_dist https://github.com/saleyn/otp/compare/erlang:master...proto_dist https://github.com/saleyn/otp/compare/erlang:maint...proto_dist.patch Long solution description ========================= This patch addresses the limitation of registering only one Erlang distributed transport with Erlang Port Mapping Daemon, and therefore enabling a node to listen for distributed node connections on multiple port using different protocols, and selectively choose the protocol to use when connecting to a node from different secure and unsecure networks. The legacy implementation of Erlang distributed transport allows to start a node with more than one transport via the "-proto_dist mod1 mod2 ..." command-line option. But epmd didn't support registration of multiple protocols. And net_kernel doesn't implement a way of figuring out which transports are supported on a remote node and doesn't allow to select a desired transport protocol of choice to use it for connecting to the node. The current patch extends epmd by having it store the name of the protocol handling module passed to the -proto_dist startup option during node registration. Multiple registrations are allowed, and they can be registered to different ports. This way a node can start distributed transport listeners (e.g. TCP, SSL, UDS), and register them with epmd. When another node does epmd "PORT_PLEASE" lookup in order to connect to node X, it now gives to epmd a list of transport names it supports (i.e. the ones that were passed to it via -proto_dist option at startup) together with the node name it queries. The epmd filters out only the transports supported by the calling client node, and gives back only those along with the corresponding port numbers. net_kernel now supports a new command-line option "-proto_dist_mf Mod Fun" which is a user-define callback function that can be used to resolve which transport protocol to use to connect to a node. This function is called after the epmd query returned a list of protocols supported by the target node. By default the first transport in the list is used. An example implementation of this function is included in `lib/kernel/examples/uds_dist/src/dist_selector.erl`. In order to support backward compatibility the EPMD protocol was extended with new commands documented in erl_dist_rotocol.xml. Old nodes can query the new EPMD version, but new nodes (using this patch) require new version of EPMD. Here's an illustration: # Node 's' is started with TCP and TLS support # see http://www.erlang.org/doc/apps/ssl/ssl_distribution.html#id61752 # note that lib/kernel/examples/uds_dist/src/dist_selector.erl # module is used to do custom transport selection $ erl -boot start_ssl -proto_dist inet_tcp inet_tls -ssl_difile "/home/serge/tmp/key.pem" -ssl_dist_opt server_certfile "/home/serge/tmp/certificate.pem" -ssl_dist_opt server_secure_renegotiate true client_secure_renegotiate true -proto_dist_mf dist_selector select -pa "lib/kernel/examples/uds_dist/ebin" -sname s@REDACTED (s@REDACTED)1> erl_epmd:names(). [{ok,{"s",[{49645,"inet_tcp"},{41477,"inet_tls"}]}}] (s@REDACTED)2> As we see the node registered itself with epmd and has TCP listener on port 49645, and TLS listener on port 41477. We now start another node with just TCP transport: $ install/bin/erl -sname k@REDACTED Erlang R17A (erts-5.11) [source-7e9f18c] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.11 (abort with ^G) (k@REDACTED)1> erl_epmd:names(). [{ok,{"k",[{38558,"inet_tcp"}]}}, {ok,{"s",[{49645,"inet_tcp"},{41477,"inet_tls"}]}}] (k@REDACTED)2> Connect it to node 's': (k@REDACTED)2> net_kernel:connect_node(s@REDACTED). true (k@REDACTED)4> nodes(). [s@REDACTED] Start the 3rd node 'm' with TCP and SSL, and connect it to node 's': $ erl -boot start_ssl -proto_dist inet_tcp inet_tls -ssl_difile "/home/serge/tmp/key.pem" -ssl_dist_opt server_certfile "/home/serge/tmp/certificate.pem" -ssl_dist_opt server_secure_renegotiate true client_secure_renegotiate true -proto_dist_mf dist_selector select -pa "/home/serge/tmp/otp/lib/kernel/examples/uds_dist/ebin" -sname m@REDACTED % Let's query the EPMD to see which transports/ports are available % to connect (m@REDACTED)1> erl_epmd:port_please(s,"localhost",net_kernel:dist_protos(),infinity). {ports,[{49645,"inet_tcp"},{41477,"inet_tls"}], 5, [{epmd,{{127,0,0,1},4369}}]} % Let the magic begin (since this is a node in the same subnet, % dist_selector will select the TCP protocol (m@REDACTED)2> net_kernel:connect_node(s@REDACTED). true This is a long email, and a sizable patch. I hope others find it useful and it can be included in the distribution. Regards, Serge From fredrik@REDACTED Fri Nov 1 09:03:18 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 1 Nov 2013 09:03:18 +0100 Subject: [erlang-patches] SSL, client_preferred_next_protocol option documentation fix In-Reply-To: References: Message-ID: <52736046.1050703@erlang.org> On 10/31/2013 05:47 PM, Julien Barbot wrote: > Hi, > > Here is a simple documentation fix for the > client_preferred_next_protocol option. > > git fetch git://github.com/klyr/otp.git fix-ssl-npn-doc-2 > > https://github.com/klyr/otp/compare/erlang:maint...fix-ssl-npn-doc-2 > https://github.com/klyr/otp/compare/erlang:maint...fix-ssl-npn-doc-2.patch > > Regards, > Hey Julien, I've fetched your branch and assigned it to be reviewed by the responsible developers. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Fri Nov 1 12:29:14 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 1 Nov 2013 12:29:14 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <524D636B.4080508@erlang.org> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> Message-ID: <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> Ping? This is still ? Status: Author ? in the Development page. -- Anthony Ramine Le 3 oct. 2013 ? 14:30, Henrik Nord a ?crit : > I will move it into the que > Thank you for your contribution! From klyr@REDACTED Sun Nov 3 21:50:02 2013 From: klyr@REDACTED (Julien Barbot) Date: Sun, 3 Nov 2013 21:50:02 +0100 Subject: [erlang-patches] SSL Server Name Indication (SNI) client support In-Reply-To: <52738FDE.3030201@erix.ericsson.se> References: <52738FDE.3030201@erix.ericsson.se> Message-ID: Hi, I added a new client-side option 'server_name_indication', this option can be set to: - a hostname, when upgrading a TCP socket to TLS, - disable, to explicitly disable sni extension. If nothing is specified, SNI hello extension is used. Same branch. Regards, -- Julien Barbot 2013/11/1 Ingela Anderton Andin : > On 10/31/2013 03:00 PM, Julien Barbot wrote: >> Here is a new attempt to implement SNI (RFC 6066, section 3). This is >> *only* the client side implementation. >> git fetch git://github.com/klyr/otp.git r17_ssl_sni_client >> >> https://github.com/klyr/otp/compare/master...r17_ssl_sni_client >> https://github.com/klyr/otp/compare/master...r17_ssl_sni_client.patch >> >> Pending questions are: >> - how to do an ssl upgrade with sni ? >> - is an aditional option to ssl:connect needed to explicitly choose an >> ssl virtual host (like {virtual_host, string()}) ? > > I think that client should not be concerned with the notion of virtual > hosts, from > its point of view there should not be a difference between real hosts and > virtual ones. > Virtual host is however a good option name on the server side when > specifying a > use of the server name indication extension. > However when upgrading a tcp connection to TLS you can not hide > everything that > you can doing the connection from scratch. So I think that when upgrading a > tcp_socket > there should be an sni-option available to specify the hostname and if it is > not set > the sni-extension should not be sent. The RFC says: > > "If an application negotiates a server name using an application > protocol and then upgrades to TLS, and if a server_name extension is > sent, then the extension SHOULD contain the same name that was > negotiated in the application protocol." >> - is an aditional option to ssl:connect needed to explicitly disable sni ? > > Well in the ideal world I would say no, but it could be nice if other > implementations off SSL/TLS don't handle > extensions correctly. I am thinking maybe there should be a general > ssl:connection option like > {server_name_indication, Hostname} that defaults to the first argument of > connect unless it is > an upgrade when it defaults to undefined. In this way you will get the > server name indication by > default without changing anything (unless it is an upgrade), but if it > causes a problem you can work around it. From klyr@REDACTED Mon Nov 4 10:28:28 2013 From: klyr@REDACTED (Julien Barbot) Date: Mon, 4 Nov 2013 10:28:28 +0100 Subject: [erlang-patches] SSL Server Name Indication (SNI) client support In-Reply-To: <52776265.5010200@erix.ericsson.se> References: <52738FDE.3030201@erix.ericsson.se> <52776265.5010200@erix.ericsson.se> Message-ID: Hi, Documentation updated on same branch. 2013/11/4 Ingela Anderton Andin : > Hi! > > Looks good but the following sentence I think at least needs a comma. > >

This option can also be set to disable to explicitly disable usage of the > Server Name Indication extension.

> >

This option can also be set to disable, to explicitly disable usage of > the Server Name Indication extension.

> > Maybe > >

When starting a TLS connection without upgrade the Server Name > Indication extension will > be sent (if possible), this option may also be used to disable that > behavior. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > On 11/03/2013 09:50 PM, Julien Barbot wrote: >> >> Hi, >> >> I added a new client-side option 'server_name_indication', this option >> can be set to: >> - a hostname, when upgrading a TCP socket to TLS, >> - disable, to explicitly disable sni extension. >> >> If nothing is specified, SNI hello extension is used. >> >> Same branch. >> >> Regards, >> > From serge@REDACTED Tue Nov 5 03:06:57 2013 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 4 Nov 2013 21:06:57 -0500 Subject: [erlang-patches] Added net_kernel support for multiple transport protocols In-Reply-To: <52733510.1030305@aleynikov.org> References: <52733510.1030305@aleynikov.org> Message-ID: Fixed failing documentation formatting error, added test cases. Please refetch: git fetch git://github.com/saleyn/otp.git proto_dist https://github.com/saleyn/otp/compare/erlang:master...proto_dist https://github.com/saleyn/otp/compare/erlang:maint...proto_dist.patch On Fri, Nov 1, 2013 at 12:58 AM, Serge Aleynikov wrote: > Hi, > > [Note: this patch is submitted by email as as a pull request #121] > > Short problem description > ========================= > I want an Erlang node to listen on incoming connections using > TCPv4, TCPv6, UDS, and TLS transports on different ports. > > I'd like other nodes to connect to this node using TLS if nodes > are in external networks, use TCPv4 or TCPv6 if nodes are > in the same subnet, and use UDS if nodes are on the same machine. > > Present implementation requires that all nodes in the network > use the same transport, which is a huge limitation > > git fetch git://github.com/saleyn/otp.git proto_dist > > https://github.com/saleyn/otp/compare/erlang:master...proto_dist > https://github.com/saleyn/otp/compare/erlang:maint...proto_dist.patch > > Long solution description > ========================= > > This patch addresses the limitation of registering only one Erlang > distributed transport with Erlang Port Mapping Daemon, and therefore > enabling a node to listen for distributed node connections on multiple > port using different protocols, and selectively choose the protocol > to use when connecting to a node from different secure and unsecure > networks. > > The legacy implementation of Erlang distributed transport allows to > start a node with more than one transport via the > "-proto_dist mod1 mod2 ..." command-line option. But epmd didn't support > registration of multiple protocols. And net_kernel doesn't implement a > way of figuring out which transports are supported on a remote node and > doesn't allow to select a desired transport protocol of choice to use it > for connecting to the node. > > The current patch extends epmd by having it store the name of the > protocol handling module passed to the -proto_dist startup option during > node registration. Multiple registrations are allowed, and they can be > registered to different ports. This way a node can start distributed > transport listeners (e.g. TCP, SSL, UDS), and register them with epmd. > > When another node does epmd "PORT_PLEASE" lookup in order to connect to > node X, it now gives to epmd a list of transport names it supports (i.e. > the ones that were passed to it via -proto_dist option at startup) > together with the node name it queries. The epmd filters out only the > transports supported by the calling client node, and gives back only > those along with the corresponding port numbers. > > net_kernel now supports a new command-line option > "-proto_dist_mf Mod Fun" which is a user-define callback function that > can be used to resolve which transport protocol to use to connect to > a node. This function is called after the epmd query returned a list > of protocols supported by the target node. By default the first > transport in the list is used. An example implementation of this > function is included in > `lib/kernel/examples/uds_dist/src/dist_selector.erl`. > > In order to support backward compatibility the EPMD protocol was > extended with new commands documented in erl_dist_rotocol.xml. Old > nodes can query the new EPMD version, but new nodes (using this patch) > require new version of EPMD. > > Here's an illustration: > > # Node 's' is started with TCP and TLS support > # see http://www.erlang.org/doc/apps/ssl/ssl_distribution.html#id61752 > # note that lib/kernel/examples/uds_dist/src/dist_selector.erl > # module is used to do custom transport selection > > $ erl -boot start_ssl -proto_dist inet_tcp inet_tls -ssl_difile > "/home/serge/tmp/key.pem" -ssl_dist_opt server_certfile > "/home/serge/tmp/certificate.pem" -ssl_dist_opt > server_secure_renegotiate true client_secure_renegotiate true > -proto_dist_mf dist_selector select -pa > "lib/kernel/examples/uds_dist/ebin" -sname s@REDACTED > > (s@REDACTED)1> erl_epmd:names(). > [{ok,{"s",[{49645,"inet_tcp"},{41477,"inet_tls"}]}}] > (s@REDACTED)2> > > As we see the node registered itself with epmd and has TCP listener on > port 49645, and TLS listener on port 41477. > > We now start another node with just TCP transport: > > $ install/bin/erl -sname k@REDACTED > Erlang R17A (erts-5.11) [source-7e9f18c] [64-bit] [smp:4:4] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.11 (abort with ^G) > (k@REDACTED)1> erl_epmd:names(). > [{ok,{"k",[{38558,"inet_tcp"}]}}, > {ok,{"s",[{49645,"inet_tcp"},{41477,"inet_tls"}]}}] > (k@REDACTED)2> > > Connect it to node 's': > > (k@REDACTED)2> net_kernel:connect_node(s@REDACTED). > true > (k@REDACTED)4> nodes(). > [s@REDACTED] > > Start the 3rd node 'm' with TCP and SSL, and connect it to node 's': > > $ erl -boot start_ssl -proto_dist inet_tcp inet_tls -ssl_difile > "/home/serge/tmp/key.pem" -ssl_dist_opt server_certfile > "/home/serge/tmp/certificate.pem" -ssl_dist_opt > server_secure_renegotiate true client_secure_renegotiate true > -proto_dist_mf dist_selector select -pa > "/home/serge/tmp/otp/lib/kernel/examples/uds_dist/ebin" -sname m@REDACTED > > % Let's query the EPMD to see which transports/ports are available > % to connect > (m@REDACTED)1> > erl_epmd:port_please(s,"localhost",net_kernel:dist_protos(),infinity). > {ports,[{49645,"inet_tcp"},{41477,"inet_tls"}], > 5, > [{epmd,{{127,0,0,1},4369}}]} > > % Let the magic begin (since this is a node in the same subnet, > % dist_selector will select the TCP protocol > > (m@REDACTED)2> net_kernel:connect_node(s@REDACTED). > true > > This is a long email, and a sizable patch. I hope others find it useful > and it can be included in the distribution. > > Regards, > > Serge > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew@REDACTED Fri Nov 8 01:46:03 2013 From: andrew@REDACTED (Andrew Bennett) Date: Thu, 7 Nov 2013 17:46:03 -0700 Subject: [erlang-patches] public_key: Workaround for incorrectly encoded utf8 emailAddress Message-ID: Hello, https://github.com/erlang/otp/pull/131 This pull request allows certificates with an improperly encoded emailAddress entry to be decoded. It is very similar to commit https://github.com/erlang/otp/commit/69d4a56d9f7ade14fd0496ffbf56d96bf9184aeffrom 2012-08-23 which did the same thing for improperly encoded X520countryName entries. In addition to the extra test case for emailAddress, there is a minor spelling correction in public_key_SUITE related to the X520countryName test case (incorrect_cuntry_name to incorrect_country_name). Most common browsers are lax in thier handling of how the emailAddress field is encoded. RFC 3280 section 4.1.2.6 defines the encoding as IA5String, however browsers will also handle certificates with the emailAddress field encoded as UTF8String. This fix allows the emailAddress to be decoded as both an IA5String and an UTF8String. Thanks, Andrew Bennett andrew@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Mon Nov 11 15:33:22 2013 From: henrik@REDACTED (Henrik Nord) Date: Mon, 11 Nov 2013 15:33:22 +0100 Subject: [erlang-patches] Fix serialization problem in xmerl export In-Reply-To: <5270FD23.1050402@gmail.com> References: <524570D0.9040605@gmail.com> <52457AD3.80405@erlang.org> <5270FD23.1050402@gmail.com> Message-ID: <5280EAB2.10504@erlang.org> This was merged to maint on the 6th of november. Thank you for your contribution! On 2013-10-30 13:35, Richard Carlsson wrote: > Ping? > > /Richard > > On 2013-09-27 14:32, Fredrik wrote: >> On 09/27/2013 01:49 PM, Richard Carlsson wrote: >>> The inheritance mechanism in xmerl uses 'catch apply(M,F,Args)' >>> to try different modules M until one was found that had a function >>> F/A. However, when M:F/A does not exist, apply/3 will trap to >>> error_handler:undefined_function/3, which will call >>> code:ensure_loaded(M), making a synchronous request to the code >>> server process. If many processes tried to use xmerl:export() >>> concurrently, they would get serialized waiting for the code server >>> process. >>> >>> This patch uses erlang:function_exported/3 instead to check if M:F/A >>> exists. If M exists, it should already have been loaded at that point >>> due to the inheritance checking in the xmerl:callbacks/1 function. >>> >>> git fetch git@REDACTED:richcarl/otp.git >>> xmerl-avoid-code-server-serialization >>> >>> https://github.com/richcarl/otp/tree/xmerl-avoid-code-server-serialization >>> >>> >>> >>> >>> /Richard >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> Hello Richard, >> I've created a pullrequest for your patch, which you can follow here: >> https://github.com/erlang/otp/pull/87 >> The patch will be run through initial tests and then be assigned to be >> reviewed by responsible developers. >> Thanks, >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Mon Nov 11 15:42:37 2013 From: henrik@REDACTED (Henrik Nord) Date: Mon, 11 Nov 2013 15:42:37 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> Message-ID: <5280ECDD.3020001@erlang.org> Its moving forward as we speak. Thank you for your contribution! On 2013-11-01 12:29, Anthony Ramine wrote: > Ping? This is still ? Status: Author ? in the Development page. > -- /Henrik Nord Erlang/OTP From jose.valim@REDACTED Mon Nov 11 19:49:04 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Mon, 11 Nov 2013 19:49:04 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: <473CD07F-27D0-4933-AECF-D369BDD26992@gmail.com> References: <66EC6D06-4291-4544-921A-325EBD8BBF5F@gmail.com> <473CD07F-27D0-4933-AECF-D369BDD26992@gmail.com> Message-ID: I have pushed a commit that allows dialyzer to work on fun with names (letrecs) and Anthony has cherry picked it into his branch: https://github.com/nox/otp/compare/eep37 I believe this is ready for another try. :) *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Mon, Oct 28, 2013 at 12:26 AM, Anthony Ramine wrote: > With DEBUG and DEBUG_PP defined in dialyzer_dataflow: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Tue Nov 12 10:44:23 2013 From: henrik@REDACTED (Henrik Nord) Date: Tue, 12 Nov 2013 10:44:23 +0100 Subject: [erlang-patches] [PATCH] - Add NIF function enif_phash2 In-Reply-To: <511CF3E7.4070402@erlang.org> References: <5114B87A.1070709@erlang.org> <5114FFFA.9090700@erix.ericsson.se> <511CF3E7.4070402@erlang.org> Message-ID: <5281F877.3070801@erlang.org> On 2013-02-14 15:25, Fredrik wrote: > On 02/08/2013 09:19 PM, Paul Davis wrote: >> Fredrik, >> >> Rebased against master: >> >> git fetch git://github.com/davisp/otp.git enif_phash2 >> >> https://github.com/davisp/otp/compare/master...enif_phash2 >> https://github.com/davisp/otp/compare/master...enif_phash2.patch >> >> Sverker, >> >> I've updated the function ordering as per the comment in >> erl_nif_api_funcs.h. For use case, I'm implementing a couple data >> structures that use hash tables to speed up some hot loops. I can get >> away for awhile using erlang:phash2/2 in Erlang and passing that value >> into the NIF but this breaks down when I don't know a priori which >> terms (or subterms) I may need to hash in the NIF. >> >> A similar example would be trying to reimplement ets without this. >> Either I'd have to store enough information in the Erlang term >> representing the table to be able to know which elements of the tuple >> to hash or I'd have to ask the table what to hash before passing the >> term off to the NIF. There are definitely work arounds to not having >> access to phash2 but they aren't pretty. >> >> Thanks, >> Paul Davis >> >> On Fri, Feb 8, 2013 at 7:39 AM, Sverker Eriksson >> wrote: >>> Fredrik wrote: >>>> On 02/08/2013 12:58 AM, Paul Davis wrote: >>>>> git fetch git://github.com/davisp/otp.git enif_phash2 >>>>> >>>>> https://github.com/davisp/otp/compare/maint...enif_phash2 >>>>> https://github.com/davisp/otp/compare/maint...enif_phash2.patch >>>>> >>>>> This patch exposes the phash2 function to NIFs. It is exactly >>>>> equivalent >>>>> to: >>>>> >>>>> erlang:phash2(Term, 16#100000000) >>>>> >>>>> Thanks, >>>>> Paul Davis >>>>> _______________________________________________ >>>>> erlang-patches mailing list >>>>> erlang-patches@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> Please rebase this patch upon the current 'master' branch. >>>> Thanks, >>>> >>> Also read the comments in erl_nif_api_funcs.h of how to add new >>> functions. >>> You do not have to increase ERL_NIF_MINOR_VERSION as I've already >>> done that >>> for R16B. >>> >>> I guess you have a real use case for enif_phash2 and why >>> erlang:phash2 is >>> not enough. >>> >>> /Sverker > Hello could you rebase this upon the current 'master' branch on github > Thanks, Ping! -- /Henrik Nord Erlang/OTP From henrik@REDACTED Tue Nov 12 10:54:50 2013 From: henrik@REDACTED (Henrik Nord) Date: Tue, 12 Nov 2013 10:54:50 +0100 Subject: [erlang-patches] Fix crash in mnesia_controller due to a function_clause exception from is_tab_blocked/1 In-Reply-To: References: <518211D0.4020003@erlang.org> Message-ID: <5281FAEA.8050400@erlang.org> On 2013-05-20 15:02, Dan Gudmundsson wrote: > Hi > > I believe the bug is that block_table is called twice, I don't think > that should happen. > It was some time ago I wrote that part, so can you try to investigate > why that happens? > > I do not want to take this patch as it is, without knowing why it > happens, since it may mask > other more serious faults. > > /Dan Ping! > > > On Thu, May 2, 2013 at 10:23 AM, Ahmed Omar > wrote: > > Thanks Fredrik for your comments, to avoid confusing commits, > Please fetch from > > git fetch git://github.com/spawnthink/otp.git > fix_mnesia_block_table_exception > > https://github.com/spawnthink/otp/compare/fix_mnesia_block_table_exception > https://github.com/spawnthink/otp/compare/fix_mnesia_block_table_exception.patch > > > On Thu, May 2, 2013 at 10:05 AM, Ahmed Omar > wrote: > > Hello Fredrik, > Could you please refetch, I removed an extra call to val(Var) > https://github.com/spawnthink/otp/compare/fix_mnesia_block_table > > > On Thu, May 2, 2013 at 9:12 AM, Fredrik > wrote: > > On 05/01/2013 03:49 PM, Ahmed Omar wrote: >> git fetch git://github.com/spawnthink/otp.git >> fix_mnesia_block_table >> >> Fix crash in mnesia_controller due to a function_clause >> exception from is_tab_blocked/1 >> >> If mnesia_controller:block_table/1 is called twice for >> same table, >> the new stored value of {Tab, where_to_commit} will be >> {blocked, {blocked,List}}. >> This will result in an exception when calling >> is_tab_blocked/1. >> mnesia_conttoller:block_table/1 should check if the table >> is already blocked. >> >> https://github.com/spawnthink/otp/compare/fix_mnesia_block_table.patch >> https://github.com/spawnthink/otp/compare/fix_mnesia_block_table >> >> Best Regards, >> Ahmed Omar >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > Hello Ahmed, > I've fetched your patch and it is currently in the 'pu' > branch. > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Tue Nov 12 23:39:03 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 12 Nov 2013 17:39:03 -0500 Subject: [erlang-patches] add o_sync option to file:open/2 Message-ID: https://github.com/erlang/otp/pull/137 This pull request adds an o_sync option to file:open/2. The o_sync option adds the POSIX O_SYNC flag to the open system call on platforms that support the flag or its equivalent, e.g., FILE_FLAG_WRITE_THROUGH on Windows. For platforms that don't support it, file:open/2 returns {error, enotsup} if the o_sync option is passed in. Joe Blomstedt (jtuple) wrote most of this patch, I just dotted the Ts, crossed the Is, and submitted it. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvstrand@REDACTED Wed Nov 13 11:37:23 2013 From: tjarvstrand@REDACTED (=?ISO-8859-1?Q?Thomas_J=E4rvstrand?=) Date: Wed, 13 Nov 2013 11:37:23 +0100 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: References: <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> <9EB6A04F-AB90-480F-B2FB-E1A8B7CBCC1F@gmail.com> <6FFF00A1-0745-4B22-9A94-4A9C154B6BC6@gmail.com> <5267D157.7020305@erlang.org> Message-ID: Hi! I just tried this patch out yesterday. I would like to ask why, if you're going to all this trouble, do you not also include information about the end of each token as well as the start? From a toolbuilder's perspective it would make this patch immensely more useful. Just a couple of examples would be when building Erlang backends for refactoring tools or context sensitive autocompletion in the editor. I think this is an awesome initiative, but please take it all the way! :) Thomas 2013/10/23 Anthony Ramine > You?re welcome. I know you have a lot to do! > > -- > Anthony Ramine > > Le 23 oct. 2013 ? 15:38, Fredrik a ?crit : > > > On 10/18/2013 09:20 PM, Anthony Ramine wrote: > >> Pang? > >> > > Hello Anthony, > > There has been a decision made that we are going to start investigating > this issue in the coming weeks and you will get further information in a > couple of weeks regarding the outcome of this. > > Thanks for your patience. > > > > -- > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvstrand@REDACTED Wed Nov 13 11:48:18 2013 From: tjarvstrand@REDACTED (=?ISO-8859-1?Q?Thomas_J=E4rvstrand?=) Date: Wed, 13 Nov 2013 11:48:18 +0100 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> Message-ID: A more generic version would be to return the first result of applying the fun to an element that does not return false. That way you can choose whether to return the actual element, the result of the computation you just or even something completely different. The user is also free to wrap the result in case he/she is worried that the return value might be `false`. Example implementation: *find(_MatchF, []) ->* * false;* *find(MatchF, [X|Xs]) -> case MatchF(X) of false -> find(MatchF, Xs); Val -> Val end.* Thomas 2013/10/22 Anthony Ramine > Forwarding to list. > > -- > Anthony Ramine > > Le 22 oct. 2013 ? 11:56, Anthony Ramine a ?crit : > > > Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not > F(X) end, L). > > > > Of course, the function would be written less naively to avoid > constructing a new fun. > > > > -- > > Anthony Ramine > > > > Le 14 oct. 2013 ? 15:52, Sean Cribbs a ?crit : > > > >> #1: Would tagging the return value address like Masklinn mentions > address your concern? {ok, Term} | error (instead of a default value)? > >> > >> #2: Also, I considered dropwhile but it involves introducing another > fun, whereas the version I wrote is direct. > >> > >> > >> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine > wrote: > >> Hello Sean, > >> > >> I don't like this patch. > >> > >> 1/ You can't know whether an element was found or not if the list > elements are arbitrary terms. > >> 2/ I don't see why you would say people hack either foreach/2 or > foldl/3 to do that when they should just use dropwhile/2. > >> > >> A naive implementation of find/2 using dropwhile/2: > >> > >> find(F, L) -> > >> case dropwhile(fun (E) -> not F(E) end, L) of > >> [] -> undefined; > >> [E|_] -> E > >> end. > >> > >> Regards, > >> > >> -- > >> Anthony Ramine > >> > >> Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : > >> > >>> `lists:find/2,3` returns the first element of the passed list for > which the predicate fun returns `true`. If no elements result in the > predicate being true, `undefined` (/2) or the given default value (/3) is > returned. > >>> > >>> ## Why this new feature? > >>> > >>> A common task is to select the first element from a list that matches > a condition, but there is no existing lists function or language feature > that avoids traversing the entire list, while still returning a "safe" > value. `lists:find/2,3` codifies the pattern of a tail-recursive search for > the matching item without resorting to exceptions (used to abort > `foreach/2` or `foldl/3`) and always returns either the first matching > item, or an otherwise safe value. > >>> > >>> ## Risks / uncertain artifacts > >>> > >>> It is unclear the desired order of arguments for the 3-arity version. > I have made the default value the final argument which is consistent with > `application:get_env/3` and `proplists:get_value/3`, but most functions in > lists place the `List` argument last. > >>> > >>> ## How did you solve it? > >>> > >>> Following the patterns of other functions in the lists module, > `lists:find/3` tests the predicate function against the head of the list, > returning the head if the predicate passes, or recursing over the tail if > it does not. > >>> > >>> https://github.com/erlang/otp/pull/102 > >>> > >>> -- > >>> Sean Cribbs > >>> Software Engineer > >>> Basho Technologies, Inc. > >>> http://basho.com/ > >>> _______________________________________________ > >>> erlang-patches mailing list > >>> erlang-patches@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-patches > >> > >> > >> > >> > >> -- > >> Sean Cribbs > >> Software Engineer > >> Basho Technologies, Inc. > >> http://basho.com/ > > > > _______________________________________________ > 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 Nov 13 13:56:30 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 13 Nov 2013 13:56:30 +0100 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: References: <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> <9EB6A04F-AB90-480F-B2FB-E1A8B7CBCC1F@gmail.com> <6FFF00A1-0745-4B22-9A94-4A9C154B6BC6@gmail.com> <5267D157.7020305@erlang.org> Message-ID: <1DE2FCAD-E203-415F-B336-860E1E7761A4@gmail.com> See my scan-end-location branch :) I also have an epp-read-lines branch which allows a tool builder to ask epp to print specific lines of parsed files. Final objective is Clang-like diagnostics. -- Anthony Ramine Le 13 nov. 2013 ? 11:37, Thomas J?rvstrand a ?crit : > I just tried this patch out yesterday. I would like to ask why, if you're going to all this trouble, do you not also include information about the end of each token as well as the start? From a toolbuilder's perspective it would make this patch immensely more useful. Just a couple of examples would be when building Erlang backends for refactoring tools or context sensitive autocompletion in the editor. From n.oxyde@REDACTED Wed Nov 13 14:00:52 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 13 Nov 2013 14:00:52 +0100 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: <1DE2FCAD-E203-415F-B336-860E1E7761A4@gmail.com> References: <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> <9EB6A04F-AB90-480F-B2FB-E1A8B7CBCC1F@gmail.com> <6FFF00A1-0745-4B22-9A94-4A9C154B6BC6@gmail.com> <5267D157.7020305@erlang.org> <1DE2FCAD-E203-415F-B336-860E1E7761A4@gmail.com> Message-ID: <2F334755-2CE5-4998-8863-BF890355737A@gmail.com> Another branch that may interest you is parse-ranges, which uses scan-end-location to compute start and end locations of each node in the AST. I also have a work in progress branch which let epp also track any macro expansion and keep their respective locations. -- Anthony Ramine Le 13 nov. 2013 ? 13:56, Anthony Ramine a ?crit : > See my scan-end-location branch :) > > I also have an epp-read-lines branch which allows a tool builder to ask epp to print specific lines of parsed files. > > Final objective is Clang-like diagnostics. > > -- > Anthony Ramine > > Le 13 nov. 2013 ? 11:37, Thomas J?rvstrand a ?crit : > >> I just tried this patch out yesterday. I would like to ask why, if you're going to all this trouble, do you not also include information about the end of each token as well as the start? From a toolbuilder's perspective it would make this patch immensely more useful. Just a couple of examples would be when building Erlang backends for refactoring tools or context sensitive autocompletion in the editor. > From yura.beznos@REDACTED Wed Nov 13 15:01:41 2013 From: yura.beznos@REDACTED (Yura Beznos) Date: Wed, 13 Nov 2013 18:01:41 +0400 Subject: [erlang-patches] crypto: Add IGE mode for AES In-Reply-To: References: <51FA1A44.4060401@erlang.org> <520A29FA.9080602@erix.ericsson.se> Message-ID: Hello! The patch isn't graduated ? (IGE mode for AES) On Tue, Aug 13, 2013 at 11:31 PM, Yura Beznos wrote: > > On Tue, Aug 13, 2013 at 4:43 PM, Sverker Eriksson < > sverker.eriksson@REDACTED> wrote: > >> Fredrik wrote: >> >>> On 08/01/2013 07:40 AM, Yura Beznos wrote: >>> >>>> Hello, >>>> >>>> I'd like to submit this patch to add two new functions to the crypt >>>> library. >>>> >>>> Repo branch: https://github.com/Zhiz0id/otp/tree/aes_ige_crypt >>>> Compare: >>>> https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt >>>> >>>> Why this new feature? >>>> >>>> It allows to use OpenSSL aes_ige_encrypt function. >>>> >>>> Risks / uncertain artifacts >>>> >>>> None. >>>> >>>> How did you solve it? >>>> >>>> Added two functions: aes_ige_256_decrypt, aes_ige_256_encrypt . >>>> >>>> >>>> Thanks. >>>> >>>> >>>> -- >>>> Yura >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> >>> Hello Yura, >>> I've assigned this patch to be reviewed by responsible, you will get >>> feedback as soon as this is done. >>> Thanks, >>> >> >> Looks good, Yura. Two objections though: >> >> 1. Do not export the aes_ige_256_encrypt/decrypt functions. Users should >> only use block_encrypt/4 and block_decrypt/4. >> >> 2. Documentation updates is missing (of block_encrypt/4 and >> block_decrypt/4). >> >> >> /Sverker, Erlang/OTP >> >> > > Compare url: > https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Wed Nov 13 15:08:52 2013 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 13 Nov 2013 09:08:52 -0500 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> Message-ID: Since finding an element in the list is already doable via lists:member/2, it seems to me that there's very little benefit in that find/2 function. Whereas a more valuable addition would be to find an index of the element in the given list. An example of a common use case for that would be to locate a field's position in a mnesia table by name (e.g. index_of): update_table(Table, FieldName, Value) -> Attrs = mnesia:table_info(Table, attributes), {ok, Pos} = index_of(FieldName, Attrs), R = mnesia:dirty_read(Table, Key), R1 = setelement(Pos, R, NewValue), ok = mnesia:dirty_write(Table, R1). index_of(Value, List) -> index_of(Value, List, 1). index_of(V, [V|T], N) -> {ok, N}; index_of(V, [_|T], N) -> index_of(V, T, N+1); index_of(_, [], _) -> false. On Wed, Nov 13, 2013 at 5:48 AM, Thomas J?rvstrand wrote: > A more generic version would be to return the first result of applying the > fun to an element that does not return false. That way you can choose > whether to return the actual element, the result of the computation you > just or even something completely different. The user is also free to wrap > the result in case he/she is worried that the return value might be `false`. > > Example implementation: > > *find(_MatchF, []) ->* > > * false;* > > > > > *find(MatchF, [X|Xs]) -> case MatchF(X) of false -> find(MatchF, > Xs); Val -> Val end.* > > Thomas > > > 2013/10/22 Anthony Ramine > >> Forwarding to list. >> >> -- >> Anthony Ramine >> >> Le 22 oct. 2013 ? 11:56, Anthony Ramine a ?crit : >> >> > Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not >> F(X) end, L). >> > >> > Of course, the function would be written less naively to avoid >> constructing a new fun. >> > >> > -- >> > Anthony Ramine >> > >> > Le 14 oct. 2013 ? 15:52, Sean Cribbs a ?crit : >> > >> >> #1: Would tagging the return value address like Masklinn mentions >> address your concern? {ok, Term} | error (instead of a default value)? >> >> >> >> #2: Also, I considered dropwhile but it involves introducing another >> fun, whereas the version I wrote is direct. >> >> >> >> >> >> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine >> wrote: >> >> Hello Sean, >> >> >> >> I don't like this patch. >> >> >> >> 1/ You can't know whether an element was found or not if the list >> elements are arbitrary terms. >> >> 2/ I don't see why you would say people hack either foreach/2 or >> foldl/3 to do that when they should just use dropwhile/2. >> >> >> >> A naive implementation of find/2 using dropwhile/2: >> >> >> >> find(F, L) -> >> >> case dropwhile(fun (E) -> not F(E) end, L) of >> >> [] -> undefined; >> >> [E|_] -> E >> >> end. >> >> >> >> Regards, >> >> >> >> -- >> >> Anthony Ramine >> >> >> >> Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : >> >> >> >>> `lists:find/2,3` returns the first element of the passed list for >> which the predicate fun returns `true`. If no elements result in the >> predicate being true, `undefined` (/2) or the given default value (/3) is >> returned. >> >>> >> >>> ## Why this new feature? >> >>> >> >>> A common task is to select the first element from a list that matches >> a condition, but there is no existing lists function or language feature >> that avoids traversing the entire list, while still returning a "safe" >> value. `lists:find/2,3` codifies the pattern of a tail-recursive search for >> the matching item without resorting to exceptions (used to abort >> `foreach/2` or `foldl/3`) and always returns either the first matching >> item, or an otherwise safe value. >> >>> >> >>> ## Risks / uncertain artifacts >> >>> >> >>> It is unclear the desired order of arguments for the 3-arity version. >> I have made the default value the final argument which is consistent with >> `application:get_env/3` and `proplists:get_value/3`, but most functions in >> lists place the `List` argument last. >> >>> >> >>> ## How did you solve it? >> >>> >> >>> Following the patterns of other functions in the lists module, >> `lists:find/3` tests the predicate function against the head of the list, >> returning the head if the predicate passes, or recursing over the tail if >> it does not. >> >>> >> >>> https://github.com/erlang/otp/pull/102 >> >>> >> >>> -- >> >>> Sean Cribbs >> >>> Software Engineer >> >>> Basho Technologies, Inc. >> >>> http://basho.com/ >> >>> _______________________________________________ >> >>> erlang-patches mailing list >> >>> erlang-patches@REDACTED >> >>> http://erlang.org/mailman/listinfo/erlang-patches >> >> >> >> >> >> >> >> >> >> -- >> >> Sean Cribbs >> >> Software Engineer >> >> Basho Technologies, Inc. >> >> http://basho.com/ >> > >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Wed Nov 13 15:18:02 2013 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 13 Nov 2013 09:18:02 -0500 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> Message-ID: Sorry, a couple of typos in my previous example: > update_table(Table, > > Key, > > FieldName, > > Value) -> > Attrs = mnesia:table_info(Table, attributes), > {ok, Pos} = index_of(FieldName, Attrs), > R = mnesia:dirty_read(Table, Key), > R1 = setelement(Pos, R, Value), > ok = mnesia:dirty_write(Table, R1). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Wed Nov 13 15:23:29 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 13 Nov 2013 09:23:29 -0500 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> Message-ID: lists:member/2 matches (using =:=) entire elements to determine whether or not they are present in the list, whereas the proposed lists:find/2,3 allows the caller to pass a fun to test for element presence. The fun allows the caller to ignore fields of an element that's a tuple, record etc. for purposes of determining whether something is or is not present in the list. Therefore lists:member/2 can't do what the proposed lists:find/2,3 can do. --steve On Wed, Nov 13, 2013 at 9:08 AM, Serge Aleynikov wrote: > Since finding an element in the list is already doable via lists:member/2, > it seems to me that there's very little benefit in that find/2 function. > Whereas a more valuable addition would be to find an index of the element > in the given list. An example of a common use case for that would be to > locate a field's position in a mnesia table by name (e.g. index_of): > > update_table(Table, FieldName, Value) -> > Attrs = mnesia:table_info(Table, attributes), > {ok, Pos} = index_of(FieldName, Attrs), > R = mnesia:dirty_read(Table, Key), > R1 = setelement(Pos, R, NewValue), > ok = mnesia:dirty_write(Table, R1). > > index_of(Value, List) -> > index_of(Value, List, 1). > index_of(V, [V|T], N) -> > {ok, N}; > index_of(V, [_|T], N) -> > index_of(V, T, N+1); > index_of(_, [], _) -> > false. > > > On Wed, Nov 13, 2013 at 5:48 AM, Thomas J?rvstrand wrote: > >> A more generic version would be to return the first result of applying >> the fun to an element that does not return false. That way you can choose >> whether to return the actual element, the result of the computation you >> just or even something completely different. The user is also free to wrap >> the result in case he/she is worried that the return value might be `false`. >> >> Example implementation: >> >> *find(_MatchF, []) ->* >> >> * false;* >> >> >> >> >> *find(MatchF, [X|Xs]) -> case MatchF(X) of false -> find(MatchF, >> Xs); Val -> Val end.* >> >> Thomas >> >> >> 2013/10/22 Anthony Ramine >> >>> Forwarding to list. >>> >>> -- >>> Anthony Ramine >>> >>> Le 22 oct. 2013 ? 11:56, Anthony Ramine a ?crit : >>> >>> > Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not >>> F(X) end, L). >>> > >>> > Of course, the function would be written less naively to avoid >>> constructing a new fun. >>> > >>> > -- >>> > Anthony Ramine >>> > >>> > Le 14 oct. 2013 ? 15:52, Sean Cribbs a ?crit : >>> > >>> >> #1: Would tagging the return value address like Masklinn mentions >>> address your concern? {ok, Term} | error (instead of a default value)? >>> >> >>> >> #2: Also, I considered dropwhile but it involves introducing another >>> fun, whereas the version I wrote is direct. >>> >> >>> >> >>> >> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine >>> wrote: >>> >> Hello Sean, >>> >> >>> >> I don't like this patch. >>> >> >>> >> 1/ You can't know whether an element was found or not if the list >>> elements are arbitrary terms. >>> >> 2/ I don't see why you would say people hack either foreach/2 or >>> foldl/3 to do that when they should just use dropwhile/2. >>> >> >>> >> A naive implementation of find/2 using dropwhile/2: >>> >> >>> >> find(F, L) -> >>> >> case dropwhile(fun (E) -> not F(E) end, L) of >>> >> [] -> undefined; >>> >> [E|_] -> E >>> >> end. >>> >> >>> >> Regards, >>> >> >>> >> -- >>> >> Anthony Ramine >>> >> >>> >> Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : >>> >> >>> >>> `lists:find/2,3` returns the first element of the passed list for >>> which the predicate fun returns `true`. If no elements result in the >>> predicate being true, `undefined` (/2) or the given default value (/3) is >>> returned. >>> >>> >>> >>> ## Why this new feature? >>> >>> >>> >>> A common task is to select the first element from a list that >>> matches a condition, but there is no existing lists function or language >>> feature that avoids traversing the entire list, while still returning a >>> "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive >>> search for the matching item without resorting to exceptions (used to abort >>> `foreach/2` or `foldl/3`) and always returns either the first matching >>> item, or an otherwise safe value. >>> >>> >>> >>> ## Risks / uncertain artifacts >>> >>> >>> >>> It is unclear the desired order of arguments for the 3-arity >>> version. I have made the default value the final argument which is >>> consistent with `application:get_env/3` and `proplists:get_value/3`, but >>> most functions in lists place the `List` argument last. >>> >>> >>> >>> ## How did you solve it? >>> >>> >>> >>> Following the patterns of other functions in the lists module, >>> `lists:find/3` tests the predicate function against the head of the list, >>> returning the head if the predicate passes, or recursing over the tail if >>> it does not. >>> >>> >>> >>> https://github.com/erlang/otp/pull/102 >>> >>> >>> >>> -- >>> >>> Sean Cribbs >>> >>> Software Engineer >>> >>> Basho Technologies, Inc. >>> >>> http://basho.com/ >>> >>> _______________________________________________ >>> >>> erlang-patches mailing list >>> >>> erlang-patches@REDACTED >>> >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Sean Cribbs >>> >> Software Engineer >>> >> Basho Technologies, Inc. >>> >> http://basho.com/ >>> > >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Wed Nov 13 16:51:14 2013 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 13 Nov 2013 10:51:14 -0500 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> Message-ID: Thanks Steve for clarification. Though for that type of matching there's lists:keymember/3 (*) that covers a good portion of suggested use cases, I can see that in more complex scenarios find/2 could be useful, but is it generic enough to warrant an addition to the lists module? If find/2 is accepted, it seems to me that the index_of/2 prototyped in my prior email could be another valuable candidate, as that is currently not doable via a combination of functions in the lists module (other than by means of lists:foldl/3 and throw, which is a bit ugly). (*) 1> lists:keymember(a, 1, [{c, 2}, d, {e, 3}, [a,b,c], {a, 4}]). true On Wed, Nov 13, 2013 at 9:23 AM, Steve Vinoski wrote: > lists:member/2 matches (using =:=) entire elements to determine whether or > not they are present in the list, whereas the proposed lists:find/2,3 > allows the caller to pass a fun to test for element presence. The fun > allows the caller to ignore fields of an element that's a tuple, record > etc. for purposes of determining whether something is or is not present in > the list. Therefore lists:member/2 can't do what the proposed > lists:find/2,3 can do. > > --steve > > > > On Wed, Nov 13, 2013 at 9:08 AM, Serge Aleynikov wrote: > >> Since finding an element in the list is already doable via >> lists:member/2, it seems to me that there's very little benefit in that >> find/2 function. Whereas a more valuable addition would be to find an >> index of the element in the given list. An example of a common use case >> for that would be to locate a field's position in a mnesia table by name >> (e.g. index_of): >> >> update_table(Table, FieldName, Value) -> >> Attrs = mnesia:table_info(Table, attributes), >> {ok, Pos} = index_of(FieldName, Attrs), >> R = mnesia:dirty_read(Table, Key), >> R1 = setelement(Pos, R, NewValue), >> ok = mnesia:dirty_write(Table, R1). >> >> index_of(Value, List) -> >> index_of(Value, List, 1). >> index_of(V, [V|T], N) -> >> {ok, N}; >> index_of(V, [_|T], N) -> >> index_of(V, T, N+1); >> index_of(_, [], _) -> >> false. >> >> >> On Wed, Nov 13, 2013 at 5:48 AM, Thomas J?rvstrand > > wrote: >> >>> A more generic version would be to return the first result of applying >>> the fun to an element that does not return false. That way you can choose >>> whether to return the actual element, the result of the computation you >>> just or even something completely different. The user is also free to wrap >>> the result in case he/she is worried that the return value might be `false`. >>> >>> Example implementation: >>> >>> *find(_MatchF, []) ->* >>> >>> * false;* >>> >>> >>> >>> >>> *find(MatchF, [X|Xs]) -> case MatchF(X) of false -> find(MatchF, >>> Xs); Val -> Val end.* >>> >>> Thomas >>> >>> >>> 2013/10/22 Anthony Ramine >>> >>>> Forwarding to list. >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 22 oct. 2013 ? 11:56, Anthony Ramine a ?crit : >>>> >>>> > Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not >>>> F(X) end, L). >>>> > >>>> > Of course, the function would be written less naively to avoid >>>> constructing a new fun. >>>> > >>>> > -- >>>> > Anthony Ramine >>>> > >>>> > Le 14 oct. 2013 ? 15:52, Sean Cribbs a ?crit : >>>> > >>>> >> #1: Would tagging the return value address like Masklinn mentions >>>> address your concern? {ok, Term} | error (instead of a default value)? >>>> >> >>>> >> #2: Also, I considered dropwhile but it involves introducing another >>>> fun, whereas the version I wrote is direct. >>>> >> >>>> >> >>>> >> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine >>>> wrote: >>>> >> Hello Sean, >>>> >> >>>> >> I don't like this patch. >>>> >> >>>> >> 1/ You can't know whether an element was found or not if the list >>>> elements are arbitrary terms. >>>> >> 2/ I don't see why you would say people hack either foreach/2 or >>>> foldl/3 to do that when they should just use dropwhile/2. >>>> >> >>>> >> A naive implementation of find/2 using dropwhile/2: >>>> >> >>>> >> find(F, L) -> >>>> >> case dropwhile(fun (E) -> not F(E) end, L) of >>>> >> [] -> undefined; >>>> >> [E|_] -> E >>>> >> end. >>>> >> >>>> >> Regards, >>>> >> >>>> >> -- >>>> >> Anthony Ramine >>>> >> >>>> >> Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : >>>> >> >>>> >>> `lists:find/2,3` returns the first element of the passed list for >>>> which the predicate fun returns `true`. If no elements result in the >>>> predicate being true, `undefined` (/2) or the given default value (/3) is >>>> returned. >>>> >>> >>>> >>> ## Why this new feature? >>>> >>> >>>> >>> A common task is to select the first element from a list that >>>> matches a condition, but there is no existing lists function or language >>>> feature that avoids traversing the entire list, while still returning a >>>> "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive >>>> search for the matching item without resorting to exceptions (used to abort >>>> `foreach/2` or `foldl/3`) and always returns either the first matching >>>> item, or an otherwise safe value. >>>> >>> >>>> >>> ## Risks / uncertain artifacts >>>> >>> >>>> >>> It is unclear the desired order of arguments for the 3-arity >>>> version. I have made the default value the final argument which is >>>> consistent with `application:get_env/3` and `proplists:get_value/3`, but >>>> most functions in lists place the `List` argument last. >>>> >>> >>>> >>> ## How did you solve it? >>>> >>> >>>> >>> Following the patterns of other functions in the lists module, >>>> `lists:find/3` tests the predicate function against the head of the list, >>>> returning the head if the predicate passes, or recursing over the tail if >>>> it does not. >>>> >>> >>>> >>> https://github.com/erlang/otp/pull/102 >>>> >>> >>>> >>> -- >>>> >>> Sean Cribbs >>>> >>> Software Engineer >>>> >>> Basho Technologies, Inc. >>>> >>> http://basho.com/ >>>> >>> _______________________________________________ >>>> >>> erlang-patches mailing list >>>> >>> erlang-patches@REDACTED >>>> >>> http://erlang.org/mailman/listinfo/erlang-patches >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Sean Cribbs >>>> >> Software Engineer >>>> >> Basho Technologies, Inc. >>>> >> http://basho.com/ >>>> > >>>> >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> >>> >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Wed Nov 13 20:35:54 2013 From: sean@REDACTED (Sean Cribbs) Date: Wed, 13 Nov 2013 13:35:54 -0600 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> Message-ID: I've changed and force-pushed my pull-request to adjust the return values. Instead of the bare element being returned, it is now wrapped in a tuple as {value, Elem}. If nothing passes the predicate, 'false' is the new default return value rather than 'undefined'. I believe this makes it more consistent with other functions in the lists module, e.g. lists:keyfind/3. Please refetch: https://github.com/erlang/otp/pull/102 On Wed, Nov 13, 2013 at 9:51 AM, Serge Aleynikov wrote: > Thanks Steve for clarification. Though for that type of matching there's > lists:keymember/3 (*) that covers a good portion of suggested use cases, I > can see that in more complex scenarios find/2 could be useful, but is it > generic enough to warrant an addition to the lists module? If find/2 is > accepted, it seems to me that the index_of/2 prototyped in my prior email > could be another valuable candidate, as that is currently not doable via a > combination of functions in the lists module (other than by means of > lists:foldl/3 and throw, which is a bit ugly). > > (*) 1> lists:keymember(a, 1, [{c, 2}, d, {e, 3}, [a,b,c], {a, 4}]). > true > > > > > On Wed, Nov 13, 2013 at 9:23 AM, Steve Vinoski wrote: > >> lists:member/2 matches (using =:=) entire elements to determine whether >> or not they are present in the list, whereas the proposed lists:find/2,3 >> allows the caller to pass a fun to test for element presence. The fun >> allows the caller to ignore fields of an element that's a tuple, record >> etc. for purposes of determining whether something is or is not present in >> the list. Therefore lists:member/2 can't do what the proposed >> lists:find/2,3 can do. >> >> --steve >> >> >> >> On Wed, Nov 13, 2013 at 9:08 AM, Serge Aleynikov wrote: >> >>> Since finding an element in the list is already doable via >>> lists:member/2, it seems to me that there's very little benefit in that >>> find/2 function. Whereas a more valuable addition would be to find an >>> index of the element in the given list. An example of a common use case >>> for that would be to locate a field's position in a mnesia table by name >>> (e.g. index_of): >>> >>> update_table(Table, FieldName, Value) -> >>> Attrs = mnesia:table_info(Table, attributes), >>> {ok, Pos} = index_of(FieldName, Attrs), >>> R = mnesia:dirty_read(Table, Key), >>> R1 = setelement(Pos, R, NewValue), >>> ok = mnesia:dirty_write(Table, R1). >>> >>> index_of(Value, List) -> >>> index_of(Value, List, 1). >>> index_of(V, [V|T], N) -> >>> {ok, N}; >>> index_of(V, [_|T], N) -> >>> index_of(V, T, N+1); >>> index_of(_, [], _) -> >>> false. >>> >>> >>> On Wed, Nov 13, 2013 at 5:48 AM, Thomas J?rvstrand < >>> tjarvstrand@REDACTED> wrote: >>> >>>> A more generic version would be to return the first result of applying >>>> the fun to an element that does not return false. That way you can choose >>>> whether to return the actual element, the result of the computation you >>>> just or even something completely different. The user is also free to wrap >>>> the result in case he/she is worried that the return value might be `false`. >>>> >>>> Example implementation: >>>> >>>> *find(_MatchF, []) ->* >>>> >>>> * false;* >>>> >>>> >>>> >>>> >>>> *find(MatchF, [X|Xs]) -> case MatchF(X) of false -> find(MatchF, >>>> Xs); Val -> Val end.* >>>> >>>> Thomas >>>> >>>> >>>> 2013/10/22 Anthony Ramine >>>> >>>>> Forwarding to list. >>>>> >>>>> -- >>>>> Anthony Ramine >>>>> >>>>> Le 22 oct. 2013 ? 11:56, Anthony Ramine a ?crit : >>>>> >>>>> > Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not >>>>> F(X) end, L). >>>>> > >>>>> > Of course, the function would be written less naively to avoid >>>>> constructing a new fun. >>>>> > >>>>> > -- >>>>> > Anthony Ramine >>>>> > >>>>> > Le 14 oct. 2013 ? 15:52, Sean Cribbs a ?crit : >>>>> > >>>>> >> #1: Would tagging the return value address like Masklinn mentions >>>>> address your concern? {ok, Term} | error (instead of a default value)? >>>>> >> >>>>> >> #2: Also, I considered dropwhile but it involves introducing >>>>> another fun, whereas the version I wrote is direct. >>>>> >> >>>>> >> >>>>> >> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine >>>>> wrote: >>>>> >> Hello Sean, >>>>> >> >>>>> >> I don't like this patch. >>>>> >> >>>>> >> 1/ You can't know whether an element was found or not if the list >>>>> elements are arbitrary terms. >>>>> >> 2/ I don't see why you would say people hack either foreach/2 or >>>>> foldl/3 to do that when they should just use dropwhile/2. >>>>> >> >>>>> >> A naive implementation of find/2 using dropwhile/2: >>>>> >> >>>>> >> find(F, L) -> >>>>> >> case dropwhile(fun (E) -> not F(E) end, L) of >>>>> >> [] -> undefined; >>>>> >> [E|_] -> E >>>>> >> end. >>>>> >> >>>>> >> Regards, >>>>> >> >>>>> >> -- >>>>> >> Anthony Ramine >>>>> >> >>>>> >> Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : >>>>> >> >>>>> >>> `lists:find/2,3` returns the first element of the passed list for >>>>> which the predicate fun returns `true`. If no elements result in the >>>>> predicate being true, `undefined` (/2) or the given default value (/3) is >>>>> returned. >>>>> >>> >>>>> >>> ## Why this new feature? >>>>> >>> >>>>> >>> A common task is to select the first element from a list that >>>>> matches a condition, but there is no existing lists function or language >>>>> feature that avoids traversing the entire list, while still returning a >>>>> "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive >>>>> search for the matching item without resorting to exceptions (used to abort >>>>> `foreach/2` or `foldl/3`) and always returns either the first matching >>>>> item, or an otherwise safe value. >>>>> >>> >>>>> >>> ## Risks / uncertain artifacts >>>>> >>> >>>>> >>> It is unclear the desired order of arguments for the 3-arity >>>>> version. I have made the default value the final argument which is >>>>> consistent with `application:get_env/3` and `proplists:get_value/3`, but >>>>> most functions in lists place the `List` argument last. >>>>> >>> >>>>> >>> ## How did you solve it? >>>>> >>> >>>>> >>> Following the patterns of other functions in the lists module, >>>>> `lists:find/3` tests the predicate function against the head of the list, >>>>> returning the head if the predicate passes, or recursing over the tail if >>>>> it does not. >>>>> >>> >>>>> >>> https://github.com/erlang/otp/pull/102 >>>>> >>> >>>>> >>> -- >>>>> >>> Sean Cribbs >>>>> >>> Software Engineer >>>>> >>> Basho Technologies, Inc. >>>>> >>> http://basho.com/ >>>>> >>> _______________________________________________ >>>>> >>> erlang-patches mailing list >>>>> >>> erlang-patches@REDACTED >>>>> >>> http://erlang.org/mailman/listinfo/erlang-patches >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Sean Cribbs >>>>> >> Software Engineer >>>>> >> Basho Technologies, Inc. >>>>> >> http://basho.com/ >>>>> > >>>>> >>>>> _______________________________________________ >>>>> erlang-patches mailing list >>>>> erlang-patches@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> >>>> >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Nov 13 21:25:39 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 13 Nov 2013 21:25:39 +0100 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> Message-ID: <2EC7C0A2-E0A8-4BAD-91FB-BA6270454307@gmail.com> For fun and bonus points, you could inline these two functions with +inline_list_funcs. See sys_core_fold:call_1/5. -- Anthony Ramine Le 13 nov. 2013 ? 20:35, Sean Cribbs a ?crit : > I've changed and force-pushed my pull-request to adjust the return values. Instead of the bare element being returned, it is now wrapped in a tuple as {value, Elem}. If nothing passes the predicate, 'false' is the new default return value rather than 'undefined'. I believe this makes it more consistent with other functions in the lists module, e.g. lists:keyfind/3. > > Please refetch: https://github.com/erlang/otp/pull/102 > > > On Wed, Nov 13, 2013 at 9:51 AM, Serge Aleynikov wrote: > Thanks Steve for clarification. Though for that type of matching there's lists:keymember/3 (*) that covers a good portion of suggested use cases, I can see that in more complex scenarios find/2 could be useful, but is it generic enough to warrant an addition to the lists module? If find/2 is accepted, it seems to me that the index_of/2 prototyped in my prior email could be another valuable candidate, as that is currently not doable via a combination of functions in the lists module (other than by means of lists:foldl/3 and throw, which is a bit ugly). > > (*) 1> lists:keymember(a, 1, [{c, 2}, d, {e, 3}, [a,b,c], {a, 4}]). > true > > > > > On Wed, Nov 13, 2013 at 9:23 AM, Steve Vinoski wrote: > lists:member/2 matches (using =:=) entire elements to determine whether or not they are present in the list, whereas the proposed lists:find/2,3 allows the caller to pass a fun to test for element presence. The fun allows the caller to ignore fields of an element that's a tuple, record etc. for purposes of determining whether something is or is not present in the list. Therefore lists:member/2 can't do what the proposed lists:find/2,3 can do. > > --steve > > > > On Wed, Nov 13, 2013 at 9:08 AM, Serge Aleynikov wrote: > Since finding an element in the list is already doable via lists:member/2, it seems to me that there's very little benefit in that find/2 function. Whereas a more valuable addition would be to find an index of the element in the given list. An example of a common use case for that would be to locate a field's position in a mnesia table by name (e.g. index_of): > > update_table(Table, FieldName, Value) -> > Attrs = mnesia:table_info(Table, attributes), > {ok, Pos} = index_of(FieldName, Attrs), > R = mnesia:dirty_read(Table, Key), > R1 = setelement(Pos, R, NewValue), > ok = mnesia:dirty_write(Table, R1). > > index_of(Value, List) -> > index_of(Value, List, 1). > index_of(V, [V|T], N) -> > {ok, N}; > index_of(V, [_|T], N) -> > index_of(V, T, N+1); > index_of(_, [], _) -> > false. > > > On Wed, Nov 13, 2013 at 5:48 AM, Thomas J?rvstrand wrote: > A more generic version would be to return the first result of applying the fun to an element that does not return false. That way you can choose whether to return the actual element, the result of the computation you just or even something completely different. The user is also free to wrap the result in case he/she is worried that the return value might be `false`. > > Example implementation: > find(_MatchF, []) -> > false; > find(MatchF, [X|Xs]) -> > case MatchF(X) of > false -> find(MatchF, Xs); > Val -> Val > end. > > Thomas > > > 2013/10/22 Anthony Ramine > Forwarding to list. > > -- > Anthony Ramine > > Le 22 oct. 2013 ? 11:56, Anthony Ramine a ?crit : > > > Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not F(X) end, L). > > > > Of course, the function would be written less naively to avoid constructing a new fun. > > > > -- > > Anthony Ramine > > > > Le 14 oct. 2013 ? 15:52, Sean Cribbs a ?crit : > > > >> #1: Would tagging the return value address like Masklinn mentions address your concern? {ok, Term} | error (instead of a default value)? > >> > >> #2: Also, I considered dropwhile but it involves introducing another fun, whereas the version I wrote is direct. > >> > >> > >> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine wrote: > >> Hello Sean, > >> > >> I don't like this patch. > >> > >> 1/ You can't know whether an element was found or not if the list elements are arbitrary terms. > >> 2/ I don't see why you would say people hack either foreach/2 or foldl/3 to do that when they should just use dropwhile/2. > >> > >> A naive implementation of find/2 using dropwhile/2: > >> > >> find(F, L) -> > >> case dropwhile(fun (E) -> not F(E) end, L) of > >> [] -> undefined; > >> [E|_] -> E > >> end. > >> > >> Regards, > >> > >> -- > >> Anthony Ramine > >> > >> Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : > >> > >>> `lists:find/2,3` returns the first element of the passed list for which the predicate fun returns `true`. If no elements result in the predicate being true, `undefined` (/2) or the given default value (/3) is returned. > >>> > >>> ## Why this new feature? > >>> > >>> A common task is to select the first element from a list that matches a condition, but there is no existing lists function or language feature that avoids traversing the entire list, while still returning a "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive search for the matching item without resorting to exceptions (used to abort `foreach/2` or `foldl/3`) and always returns either the first matching item, or an otherwise safe value. > >>> > >>> ## Risks / uncertain artifacts > >>> > >>> It is unclear the desired order of arguments for the 3-arity version. I have made the default value the final argument which is consistent with `application:get_env/3` and `proplists:get_value/3`, but most functions in lists place the `List` argument last. > >>> > >>> ## How did you solve it? > >>> > >>> Following the patterns of other functions in the lists module, `lists:find/3` tests the predicate function against the head of the list, returning the head if the predicate passes, or recursing over the tail if it does not. > >>> > >>> https://github.com/erlang/otp/pull/102 > >>> > >>> -- > >>> Sean Cribbs > >>> Software Engineer > >>> Basho Technologies, Inc. > >>> http://basho.com/ > >>> _______________________________________________ > >>> erlang-patches mailing list > >>> erlang-patches@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-patches > >> > >> > >> > >> > >> -- > >> Sean Cribbs > >> Software Engineer > >> Basho Technologies, Inc. > >> http://basho.com/ > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From sean@REDACTED Wed Nov 13 23:06:29 2013 From: sean@REDACTED (Sean Cribbs) Date: Wed, 13 Nov 2013 16:06:29 -0600 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: <2EC7C0A2-E0A8-4BAD-91FB-BA6270454307@gmail.com> References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> <2EC7C0A2-E0A8-4BAD-91FB-BA6270454307@gmail.com> Message-ID: Ah, that would be nice, does that essentially produce a hand-tuned Core Erlang version of the function? On Wed, Nov 13, 2013 at 2:25 PM, Anthony Ramine wrote: > For fun and bonus points, you could inline these two functions with > +inline_list_funcs. > > See sys_core_fold:call_1/5. > > -- > Anthony Ramine > > Le 13 nov. 2013 ? 20:35, Sean Cribbs a ?crit : > > > I've changed and force-pushed my pull-request to adjust the return > values. Instead of the bare element being returned, it is now wrapped in a > tuple as {value, Elem}. If nothing passes the predicate, 'false' is the new > default return value rather than 'undefined'. I believe this makes it more > consistent with other functions in the lists module, e.g. lists:keyfind/3. > > > > Please refetch: https://github.com/erlang/otp/pull/102 > > > > > > On Wed, Nov 13, 2013 at 9:51 AM, Serge Aleynikov > wrote: > > Thanks Steve for clarification. Though for that type of matching there's > lists:keymember/3 (*) that covers a good portion of suggested use cases, I > can see that in more complex scenarios find/2 could be useful, but is it > generic enough to warrant an addition to the lists module? If find/2 is > accepted, it seems to me that the index_of/2 prototyped in my prior email > could be another valuable candidate, as that is currently not doable via a > combination of functions in the lists module (other than by means of > lists:foldl/3 and throw, which is a bit ugly). > > > > (*) 1> lists:keymember(a, 1, [{c, 2}, d, {e, 3}, [a,b,c], {a, 4}]). > > true > > > > > > > > > > On Wed, Nov 13, 2013 at 9:23 AM, Steve Vinoski wrote: > > lists:member/2 matches (using =:=) entire elements to determine whether > or not they are present in the list, whereas the proposed lists:find/2,3 > allows the caller to pass a fun to test for element presence. The fun > allows the caller to ignore fields of an element that's a tuple, record > etc. for purposes of determining whether something is or is not present in > the list. Therefore lists:member/2 can't do what the proposed > lists:find/2,3 can do. > > > > --steve > > > > > > > > On Wed, Nov 13, 2013 at 9:08 AM, Serge Aleynikov > wrote: > > Since finding an element in the list is already doable via > lists:member/2, it seems to me that there's very little benefit in that > find/2 function. Whereas a more valuable addition would be to find an > index of the element in the given list. An example of a common use case > for that would be to locate a field's position in a mnesia table by name > (e.g. index_of): > > > > update_table(Table, FieldName, Value) -> > > Attrs = mnesia:table_info(Table, attributes), > > {ok, Pos} = index_of(FieldName, Attrs), > > R = mnesia:dirty_read(Table, Key), > > R1 = setelement(Pos, R, NewValue), > > ok = mnesia:dirty_write(Table, R1). > > > > index_of(Value, List) -> > > index_of(Value, List, 1). > > index_of(V, [V|T], N) -> > > {ok, N}; > > index_of(V, [_|T], N) -> > > index_of(V, T, N+1); > > index_of(_, [], _) -> > > false. > > > > > > On Wed, Nov 13, 2013 at 5:48 AM, Thomas J?rvstrand < > tjarvstrand@REDACTED> wrote: > > A more generic version would be to return the first result of applying > the fun to an element that does not return false. That way you can choose > whether to return the actual element, the result of the computation you > just or even something completely different. The user is also free to wrap > the result in case he/she is worried that the return value might be `false`. > > > > Example implementation: > > find(_MatchF, []) -> > > false; > > find(MatchF, [X|Xs]) -> > > case MatchF(X) of > > false -> find(MatchF, Xs); > > Val -> Val > > end. > > > > Thomas > > > > > > 2013/10/22 Anthony Ramine > > Forwarding to list. > > > > -- > > Anthony Ramine > > > > Le 22 oct. 2013 ? 11:56, Anthony Ramine a ?crit : > > > > > Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not > F(X) end, L). > > > > > > Of course, the function would be written less naively to avoid > constructing a new fun. > > > > > > -- > > > Anthony Ramine > > > > > > Le 14 oct. 2013 ? 15:52, Sean Cribbs a ?crit : > > > > > >> #1: Would tagging the return value address like Masklinn mentions > address your concern? {ok, Term} | error (instead of a default value)? > > >> > > >> #2: Also, I considered dropwhile but it involves introducing another > fun, whereas the version I wrote is direct. > > >> > > >> > > >> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine > wrote: > > >> Hello Sean, > > >> > > >> I don't like this patch. > > >> > > >> 1/ You can't know whether an element was found or not if the list > elements are arbitrary terms. > > >> 2/ I don't see why you would say people hack either foreach/2 or > foldl/3 to do that when they should just use dropwhile/2. > > >> > > >> A naive implementation of find/2 using dropwhile/2: > > >> > > >> find(F, L) -> > > >> case dropwhile(fun (E) -> not F(E) end, L) of > > >> [] -> undefined; > > >> [E|_] -> E > > >> end. > > >> > > >> Regards, > > >> > > >> -- > > >> Anthony Ramine > > >> > > >> Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : > > >> > > >>> `lists:find/2,3` returns the first element of the passed list for > which the predicate fun returns `true`. If no elements result in the > predicate being true, `undefined` (/2) or the given default value (/3) is > returned. > > >>> > > >>> ## Why this new feature? > > >>> > > >>> A common task is to select the first element from a list that > matches a condition, but there is no existing lists function or language > feature that avoids traversing the entire list, while still returning a > "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive > search for the matching item without resorting to exceptions (used to abort > `foreach/2` or `foldl/3`) and always returns either the first matching > item, or an otherwise safe value. > > >>> > > >>> ## Risks / uncertain artifacts > > >>> > > >>> It is unclear the desired order of arguments for the 3-arity > version. I have made the default value the final argument which is > consistent with `application:get_env/3` and `proplists:get_value/3`, but > most functions in lists place the `List` argument last. > > >>> > > >>> ## How did you solve it? > > >>> > > >>> Following the patterns of other functions in the lists module, > `lists:find/3` tests the predicate function against the head of the list, > returning the head if the predicate passes, or recursing over the tail if > it does not. > > >>> > > >>> https://github.com/erlang/otp/pull/102 > > >>> > > >>> -- > > >>> Sean Cribbs > > >>> Software Engineer > > >>> Basho Technologies, Inc. > > >>> http://basho.com/ > > >>> _______________________________________________ > > >>> erlang-patches mailing list > > >>> erlang-patches@REDACTED > > >>> http://erlang.org/mailman/listinfo/erlang-patches > > >> > > >> > > >> > > >> > > >> -- > > >> Sean Cribbs > > >> Software Engineer > > >> Basho Technologies, Inc. > > >> http://basho.com/ > > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > -- > > Sean Cribbs > > Software Engineer > > Basho Technologies, Inc. > > http://basho.com/ > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Nov 13 23:49:31 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 13 Nov 2013 23:49:31 +0100 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> <2EC7C0A2-E0A8-4BAD-91FB-BA6270454307@gmail.com> Message-ID: <25334AE0-6BB5-4CEE-A37A-B14E6F5ED597@gmail.com> Yes, you can see the result with erlc +inline_list_funcs +to_core. I fixed some things in the past there, reading the commits may help you if you ever fancy doing this: https://github.com/nox/otp/compare/promote-inline_list_funcs Regards, -- Anthony Ramine Le 13 nov. 2013 ? 23:06, Sean Cribbs a ?crit : > Ah, that would be nice, does that essentially produce a hand-tuned Core Erlang version of the function? > > On Wed, Nov 13, 2013 at 2:25 PM, Anthony Ramine wrote: > For fun and bonus points, you could inline these two functions with +inline_list_funcs. > > See sys_core_fold:call_1/5. > > -- > Anthony Ramine > > Le 13 nov. 2013 ? 20:35, Sean Cribbs a ?crit : > > > I've changed and force-pushed my pull-request to adjust the return values. Instead of the bare element being returned, it is now wrapped in a tuple as {value, Elem}. If nothing passes the predicate, 'false' is the new default return value rather than 'undefined'. I believe this makes it more consistent with other functions in the lists module, e.g. lists:keyfind/3. > > > > Please refetch: https://github.com/erlang/otp/pull/102 > > > > > > On Wed, Nov 13, 2013 at 9:51 AM, Serge Aleynikov wrote: > > Thanks Steve for clarification. Though for that type of matching there's lists:keymember/3 (*) that covers a good portion of suggested use cases, I can see that in more complex scenarios find/2 could be useful, but is it generic enough to warrant an addition to the lists module? If find/2 is accepted, it seems to me that the index_of/2 prototyped in my prior email could be another valuable candidate, as that is currently not doable via a combination of functions in the lists module (other than by means of lists:foldl/3 and throw, which is a bit ugly). > > > > (*) 1> lists:keymember(a, 1, [{c, 2}, d, {e, 3}, [a,b,c], {a, 4}]). > > true > > > > > > > > > > On Wed, Nov 13, 2013 at 9:23 AM, Steve Vinoski wrote: > > lists:member/2 matches (using =:=) entire elements to determine whether or not they are present in the list, whereas the proposed lists:find/2,3 allows the caller to pass a fun to test for element presence. The fun allows the caller to ignore fields of an element that's a tuple, record etc. for purposes of determining whether something is or is not present in the list. Therefore lists:member/2 can't do what the proposed lists:find/2,3 can do. > > > > --steve > > > > > > > > On Wed, Nov 13, 2013 at 9:08 AM, Serge Aleynikov wrote: > > Since finding an element in the list is already doable via lists:member/2, it seems to me that there's very little benefit in that find/2 function. Whereas a more valuable addition would be to find an index of the element in the given list. An example of a common use case for that would be to locate a field's position in a mnesia table by name (e.g. index_of): > > > > update_table(Table, FieldName, Value) -> > > Attrs = mnesia:table_info(Table, attributes), > > {ok, Pos} = index_of(FieldName, Attrs), > > R = mnesia:dirty_read(Table, Key), > > R1 = setelement(Pos, R, NewValue), > > ok = mnesia:dirty_write(Table, R1). > > > > index_of(Value, List) -> > > index_of(Value, List, 1). > > index_of(V, [V|T], N) -> > > {ok, N}; > > index_of(V, [_|T], N) -> > > index_of(V, T, N+1); > > index_of(_, [], _) -> > > false. > > > > > > On Wed, Nov 13, 2013 at 5:48 AM, Thomas J?rvstrand wrote: > > A more generic version would be to return the first result of applying the fun to an element that does not return false. That way you can choose whether to return the actual element, the result of the computation you just or even something completely different. The user is also free to wrap the result in case he/she is worried that the return value might be `false`. > > > > Example implementation: > > find(_MatchF, []) -> > > false; > > find(MatchF, [X|Xs]) -> > > case MatchF(X) of > > false -> find(MatchF, Xs); > > Val -> Val > > end. > > > > Thomas > > > > > > 2013/10/22 Anthony Ramine > > Forwarding to list. > > > > -- > > Anthony Ramine > > > > Le 22 oct. 2013 ? 11:56, Anthony Ramine a ?crit : > > > > > Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not F(X) end, L). > > > > > > Of course, the function would be written less naively to avoid constructing a new fun. > > > > > > -- > > > Anthony Ramine > > > > > > Le 14 oct. 2013 ? 15:52, Sean Cribbs a ?crit : > > > > > >> #1: Would tagging the return value address like Masklinn mentions address your concern? {ok, Term} | error (instead of a default value)? > > >> > > >> #2: Also, I considered dropwhile but it involves introducing another fun, whereas the version I wrote is direct. > > >> > > >> > > >> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine wrote: > > >> Hello Sean, > > >> > > >> I don't like this patch. > > >> > > >> 1/ You can't know whether an element was found or not if the list elements are arbitrary terms. > > >> 2/ I don't see why you would say people hack either foreach/2 or foldl/3 to do that when they should just use dropwhile/2. > > >> > > >> A naive implementation of find/2 using dropwhile/2: > > >> > > >> find(F, L) -> > > >> case dropwhile(fun (E) -> not F(E) end, L) of > > >> [] -> undefined; > > >> [E|_] -> E > > >> end. > > >> > > >> Regards, > > >> > > >> -- > > >> Anthony Ramine > > >> > > >> Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : > > >> > > >>> `lists:find/2,3` returns the first element of the passed list for which the predicate fun returns `true`. If no elements result in the predicate being true, `undefined` (/2) or the given default value (/3) is returned. > > >>> > > >>> ## Why this new feature? > > >>> > > >>> A common task is to select the first element from a list that matches a condition, but there is no existing lists function or language feature that avoids traversing the entire list, while still returning a "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive search for the matching item without resorting to exceptions (used to abort `foreach/2` or `foldl/3`) and always returns either the first matching item, or an otherwise safe value. > > >>> > > >>> ## Risks / uncertain artifacts > > >>> > > >>> It is unclear the desired order of arguments for the 3-arity version. I have made the default value the final argument which is consistent with `application:get_env/3` and `proplists:get_value/3`, but most functions in lists place the `List` argument last. > > >>> > > >>> ## How did you solve it? > > >>> > > >>> Following the patterns of other functions in the lists module, `lists:find/3` tests the predicate function against the head of the list, returning the head if the predicate passes, or recursing over the tail if it does not. > > >>> > > >>> https://github.com/erlang/otp/pull/102 > > >>> > > >>> -- > > >>> Sean Cribbs > > >>> Software Engineer > > >>> Basho Technologies, Inc. > > >>> http://basho.com/ > > >>> _______________________________________________ > > >>> erlang-patches mailing list > > >>> erlang-patches@REDACTED > > >>> http://erlang.org/mailman/listinfo/erlang-patches > > >> > > >> > > >> > > >> > > >> -- > > >> Sean Cribbs > > >> Software Engineer > > >> Basho Technologies, Inc. > > >> http://basho.com/ > > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > -- > > Sean Cribbs > > Software Engineer > > Basho Technologies, Inc. > > http://basho.com/ > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ From n.oxyde@REDACTED Thu Nov 14 13:26:42 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 14 Nov 2013 13:26:42 +0100 Subject: [erlang-patches] Rewrite merge of clause variable tables (in case, try, etc) Message-ID: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> Hello, I have finally got around fixing the two regressions reported in R16B02 with regard to unused variable warnings. The fix was more complicated than what I expected it to be. git fetch https://github.com/nox/otp.git fix-exporting-rules https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules.patch Regards, -- Anthony Ramine From n.oxyde@REDACTED Fri Nov 15 02:53:13 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 15 Nov 2013 02:53:13 +0100 Subject: [erlang-patches] Use isfinite() instead of finite() when available Message-ID: Hello, This fixes the following warning on Mac OS X 10.9 Mavericks: hipe/hipe_bif0.c:1025:10: warning: 'finite' is deprecated: first deprecated in OS X 10.9 [-Wdeprecated-declarations] if (!finite(p->hipe.float_result)) { ^ /usr/include/math.h:718:12: note: 'finite' declared here extern int finite(double) __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0, __MAC_10_9, __IPHONE_NA, __IPHONE_NA); ^ git fetch https://github.com/nox/otp isfinite https://github.com/nox/otp/compare/isfinite https://github.com/nox/otp/compare/isfinite.patch Regards, -- Anthony Ramine From fredrik@REDACTED Fri Nov 15 08:59:21 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 15 Nov 2013 08:59:21 +0100 Subject: [erlang-patches] Rewrite merge of clause variable tables (in case, try, etc) In-Reply-To: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> References: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> Message-ID: <5285D459.2060807@erlang.org> On 11/14/2013 01:26 PM, Anthony Ramine wrote: > Hello, > > I have finally got around fixing the two regressions reported in R16B02 with regard to unused variable warnings. > > The fix was more complicated than what I expected it to be. > > git fetch https://github.com/nox/otp.git fix-exporting-rules > > https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules > https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules.patch > > Regards, > Hello Anthony, I've fetched your patch and assigned it to be reviewed. Thanks for contribution, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Fri Nov 15 09:01:49 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 15 Nov 2013 09:01:49 +0100 Subject: [erlang-patches] Use isfinite() instead of finite() when available In-Reply-To: References: Message-ID: <5285D4ED.7020900@erlang.org> On 11/15/2013 02:53 AM, Anthony Ramine wrote: > Hello, > > This fixes the following warning on Mac OS X 10.9 Mavericks: > > hipe/hipe_bif0.c:1025:10: warning: 'finite' is deprecated: first deprecated in OS X 10.9 [-Wdeprecated-declarations] > if (!finite(p->hipe.float_result)) { > ^ > /usr/include/math.h:718:12: note: 'finite' declared here > extern int finite(double) __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0, __MAC_10_9, __IPHONE_NA, __IPHONE_NA); > ^ > > git fetch https://github.com/nox/otp isfinite > > https://github.com/nox/otp/compare/isfinite > https://github.com/nox/otp/compare/isfinite.patch > > Regards, > Hello Anthony, Fetched your patch and assigned it to be reviewed by responsible developers. Thanks! -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Fri Nov 15 11:21:59 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 15 Nov 2013 11:21:59 +0100 Subject: [erlang-patches] Fix some uninitialized pointers in crypto Message-ID: <04D5B4C2-33AD-41B8-BE0C-B29F2B9E4B69@gmail.com> Hello, There are some initialized pointers in crypto that may cause free() to be called on arbitrary values. git fetch https://github.com/nox/otp.git crypto-uninitialized-vars https://github.com/nox/otp/compare/crypto-uninitialized-vars https://github.com/nox/otp/compare/crypto-uninitialized-vars.patch Regards, -- Anthony Ramine From n.oxyde@REDACTED Fri Nov 15 11:25:45 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 15 Nov 2013 11:25:45 +0100 Subject: [erlang-patches] Include ctype.h in odbcserver.c for tolower() Message-ID: Hello, Clang complains about tolower() being implicitly declared because ctype.h is not included in odbcserver.c git fetch https://github.com/nox/otp.git odbcserver-tolower https://github.com/nox/otp/compare/odbcserver-tolower https://github.com/nox/otp/compare/odbcserver-tolower.patch Regards, -- Anthony Ramine From n.oxyde@REDACTED Sat Nov 16 13:58:51 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 16 Nov 2013 13:58:51 +0100 Subject: [erlang-patches] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: References: Message-ID: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Finally I may have found one. Tell me where I should write tests for that and I will add them. git fetch https://github.com/nox/otp.git core-clause-subst https://github.com/nox/otp/compare/erlang:maint...core-clause-subst https://github.com/nox/otp/compare/erlang:maint...core-clause-subst.patch Regards, -- Anthony Ramine Le 16 nov. 2013 ? 13:27, Anthony Ramine a ?crit : > Hello, > > I have trying to fix a bug for a while without success so I post it here. > > t(Bin1) -> > case Bin1 of > <<>> -> ok; > Bin2 -> > case Bin1 of > <<0>> -> ok; > _ -> Bin2 > end > end. > > In the following function, sys_core_fold fails to see that Bin2 is an alias of Bin1 and does not emit a bs_context_to_binary, making beam_validator crash quite violently: > > t: function t/1+17: > Internal consistency check failed - please report this bug. > Instruction: return > Error: {match_context,{x,0}}: > > Regards, > > -- > Anthony Ramine > From n.oxyde@REDACTED Mon Nov 18 11:52:53 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 18 Nov 2013 11:52:53 +0100 Subject: [erlang-patches] Properly let floating-point instructions through in the BEAM compiler Message-ID: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> Hello, The compiler shouldn't crash when fed an already-optimised BEAM assembly file. git fetch https://github.com/nox/otp.git beam-fp-insts https://github.com/nox/otp/compare/beam-fp-insts https://github.com/nox/otp/compare/beam-fp-insts.patch Regards, -- Anthony Ramine From bgustavsson@REDACTED Mon Nov 18 12:58:38 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 18 Nov 2013 12:58:38 +0100 Subject: [erlang-patches] [erlang-bugs] Properly let floating-point instructions through in the BEAM compiler In-Reply-To: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> References: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> Message-ID: On Mon, Nov 18, 2013 at 11:52 AM, Anthony Ramine wrote: > Hello, > > The compiler shouldn't crash when fed an already-optimised BEAM assembly > file. > > git fetch https://github.com/nox/otp.git beam-fp-insts > > https://github.com/nox/otp/compare/beam-fp-insts > https://github.com/nox/otp/compare/beam-fp-insts.patch > > I am very picky with good coverage of the compiler code. If coverage is good to begin with, it is easy to see when the coverage gets worse that some optimization is no longer being applied. Suggestion: Include the following one-line change in your patch and fix the remaining problems: diff --git a/lib/compiler/test/compile_SUITE.erl b/lib/compiler/test/compile_SUITE.erl index be01ea7..4e2753d 100644 --- a/lib/compiler/test/compile_SUITE.erl +++ b/lib/compiler/test/compile_SUITE.erl @@ -794,7 +794,7 @@ do_asm(Beam, Outdir) -> {ok,Fd} = file:open(AsmFile, [write]), beam_listing:module(Fd, Asm), ok = file:close(Fd), - case compile:file(AsmFile, [from_asm,no_postopt,binary,report]) of + case compile:file(AsmFile, [from_asm,binary,report]) of {ok,M,_} -> ok = file:delete(AsmFile); Other -> /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Nov 18 13:41:16 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 18 Nov 2013 13:41:16 +0100 Subject: [erlang-patches] [erlang-bugs] Properly let floating-point instructions through in the BEAM compiler In-Reply-To: References: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> Message-ID: <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> I owe you a beer for that tip, I should have thought to grep for no_postopt in the code. I have just found another discrepancy with regard to allocate and init by recompiling sofs. -- Anthony Ramine Le 18 nov. 2013 ? 12:58, Bj?rn Gustavsson a ?crit : > Suggestion: Include the following one-line change in your patch and > fix the remaining problems: From fredrik@REDACTED Mon Nov 18 14:25:53 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 18 Nov 2013 14:25:53 +0100 Subject: [erlang-patches] [erlang-bugs] Fix some uninitialized pointers in crypto In-Reply-To: <04D5B4C2-33AD-41B8-BE0C-B29F2B9E4B69@gmail.com> References: <04D5B4C2-33AD-41B8-BE0C-B29F2B9E4B69@gmail.com> Message-ID: <528A1561.9050502@erlang.org> On 11/15/2013 11:21 AM, Anthony Ramine wrote: > Hello, > > There are some initialized pointers in crypto that may cause free() to be called on arbitrary values. > > git fetch https://github.com/nox/otp.git crypto-uninitialized-vars > > https://github.com/nox/otp/compare/crypto-uninitialized-vars > https://github.com/nox/otp/compare/crypto-uninitialized-vars.patch > > Regards, > Hello Anthony, I've fetched your patch and assigned it to be reviewed by responsible developers. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Nov 18 14:28:42 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 18 Nov 2013 14:28:42 +0100 Subject: [erlang-patches] Include ctype.h in odbcserver.c for tolower() In-Reply-To: References: Message-ID: <528A160A.4030705@erlang.org> On 11/15/2013 11:25 AM, Anthony Ramine wrote: > Hello, > > Clang complains about tolower() being implicitly declared because ctype.h is not included in odbcserver.c > > git fetch https://github.com/nox/otp.git odbcserver-tolower > > https://github.com/nox/otp/compare/odbcserver-tolower > https://github.com/nox/otp/compare/odbcserver-tolower.patch > > Regards, > Hello Anthony, I've assigned your patch to be reviewed by responsible developers. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Tue Nov 19 20:11:50 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 19 Nov 2013 20:11:50 +0100 Subject: [erlang-patches] Let the compiler understand its own BEAM output In-Reply-To: <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> References: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> Message-ID: <600B8BEF-C89C-42CC-A74B-C5166D233774@gmail.com> I?ve made a new more general branch with other fixes: git fetch https://github.com/nox/otp.git asm-reentrant https://github.com/nox/otp/compare/erlang:maint...asm-reentrant https://github.com/nox/otp/compare/erlang:maint...asm-reentrant.patch This also tests for BEAM output recompilation in both compilation_SUITE and compile_SUITE. Regards, -- Anthony Ramine Le 18 nov. 2013 ? 13:41, Anthony Ramine a ?crit : > I owe you a beer for that tip, I should have thought to grep for no_postopt in the code. > > I have just found another discrepancy with regard to allocate and init by recompiling sofs. > > -- > Anthony Ramine > > Le 18 nov. 2013 ? 12:58, Bj?rn Gustavsson a ?crit : > >> Suggestion: Include the following one-line change in your patch and >> fix the remaining problems: > From n.oxyde@REDACTED Tue Nov 19 21:34:19 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 19 Nov 2013 21:34:19 +0100 Subject: [erlang-patches] Rewrite merge of clause variable tables (in case, try, etc) In-Reply-To: <5285D459.2060807@erlang.org> References: <6DBCC5C7-3088-4C74-96A5-C77C35E4934A@gmail.com> <5285D459.2060807@erlang.org> Message-ID: <210241A2-EEA2-4523-B949-B1493F2EC3E8@gmail.com> I?ve changed a little the way I modified vtunsafe. Please refetch. -- Anthony Ramine Le 15 nov. 2013 ? 08:59, Fredrik a ?crit : > On 11/14/2013 01:26 PM, Anthony Ramine wrote: >> Hello, >> >> I have finally got around fixing the two regressions reported in R16B02 with regard to unused variable warnings. >> >> The fix was more complicated than what I expected it to be. >> >> git fetch https://github.com/nox/otp.git fix-exporting-rules >> >> https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules >> https://github.com/nox/otp/compare/erlang:maint...fix-exporting-rules.patch >> >> Regards, >> > Hello Anthony, > I've fetched your patch and assigned it to be reviewed. > Thanks for contribution, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From alex.demidenko@REDACTED Thu Nov 21 02:41:43 2013 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Thu, 21 Nov 2013 08:41:43 +0700 Subject: [erlang-patches] SSH-daemon freezing while call io:getopts() and io:setopts() Message-ID: Hello, friends. I have a trouble with using shell in the ssh-daemon, when I call the function io:getopts() and io:setopts([{echo, false}, {encoding, latin1}]). Tested by Erlang 16B02, ssh 2.1.8 and R15B02, ssh 2.1.1 How can i see, in the ssh_cli.erl module, handle_msg metod no function for processing param ({Group, set_unicode_state, Arg}, State) and ({Group, get_unicode_state}, State). My patch for fixing: --- ssh-2.1.1/src/ssh_cli.erl 2013-10-26 14:25:26.000000000 +++ ssh-2.1.2/src/ssh_cli.erl 2013-10-26 14:18:18.000000000 @@ -159,12 +159,20 @@ %%-------------------------------------------------------------------- handle_msg({ssh_channel_up, ChannelId, ConnectionManager}, #state{channel = ChannelId, cm = ConnectionManager} = State) -> {ok, State}; +handle_msg({Group, set_unicode_state, _Arg}, State) -> + Group ! {self(), set_unicode_state, false}, + {ok, State}; + +handle_msg({Group, get_unicode_state}, State) -> + Group ! {self(), get_unicode_state, false}, + {ok, State}; + handle_msg({Group, Req}, #state{group = Group, buf = Buf, pty = Pty, cm = ConnectionManager, channel = ChannelId} = State) -> {Chars, NewBuf} = io_request(Req, Buf, Pty), write_chars(ConnectionManager, ChannelId, Chars), {ok, State#state{buf = NewBuf}}; Also I attached simple sample, where you can see this problem. To run it, compile ssh_shell.erl and ssh_manager.erl and invoke "ssh_manager:start_link()" method to run ssh-daemon. (you need generate personal keys for used it) Then run ssh-client on terminal to localhost on port 7777, after entering the password ?test?, enter the command "echo_on" or "echo_off". You can see that there is a delay when calling functions io:getopts() and io:setopts([{echo, false}, {encoding, latin1}]). -- --------------------------------------------- With best regards, Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh_delay_test.tar.gz Type: application/x-gzip Size: 3311 bytes Desc: not available URL: From alex.demidenko@REDACTED Thu Nov 21 03:51:44 2013 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Thu, 21 Nov 2013 09:51:44 +0700 Subject: [erlang-patches] SSH-daemon invalid column calculation at ssh_cli:delete_chars() Message-ID: Hello, friends. How can I see, in the ssh_cli.erl module, delete_chars method incorrectly calculate variable "NewCol". I can offer the option of a patch that fixes this problem. The person who is responsible for supporting ssh has the discretion to take it as it is, or can make own fix. Tested by Erlang 16B02, ssh 2.1.8 and R15B02, ssh 2.1.1 hurd@REDACTED:~/Documents/Erlang/reports/ssh_expand_test$ cat ssh.patch --- ssh-2.1.1/src/ssh_cli.erl 2013-10-26 14:25:26.000000000 +++ ssh-2.1.2/src/ssh_cli.erl 2013-10-26 14:18:18.000000000 @@ -311,13 +319,14 @@ NewBufTail = nthtail(N, BufTail), M = move_cursor(Col + length(NewBufTail) + N, Col, Tty), {[NewBufTail, lists:duplicate(N, $ ) | M], {Buf, NewBufTail, Col}}; delete_chars(N, {Buf, BufTail, Col}, Tty) -> % N < 0 NewBuf = nthtail(-N, Buf), - NewCol = Col + N, + NewCol = case Col + N of V when V >= 0 -> V; _ -> 0 end, M1 = move_cursor(Col, NewCol, Tty), M2 = move_cursor(NewCol + length(BufTail) - N, NewCol, Tty), {[M1, BufTail, lists:duplicate(-N, $ ) | M2], {NewBuf, BufTail, NewCol}}. %%% Window change, redraw the current line (and clear out after it I attached simple sample, where you can see this problem. To run it, compile ssh_manager.erl and invoke "ssh_manager:start()" method to run ssh-daemon. Then run simple ssh-client on terminal to localhost on port 9999, and entering the password "test". (you need put keys in .ssh folder) Below example show trouble with the display of available commands when you press Tab. At the command prompt "ssh_app:" _____________________________________________________ 1> ssh_app: _____________________________________________________ Press tab. _____________________________________________________ 1> ssh_app: module_info/0 module_info/1 start/2 stop/1 1> ssh_app: _____________________________________________________ You will see the line below "module_info/0 module_info/1 start/2 stop/1," and below that "ssh_app:". Everything is wonderful. Yet. Do the following: Go to the new line (Press enter) and enter a space as long as the input field team did not go on the line below . _____________________________________________________ 1> _____________________________________________________ Enter "ssh_app:" _____________________________________________________ 1> ssh_app: _____________________________________________________ Press tab. _____________________________________________________ 1> ssh_app: 1> ssh_app: _____________________________________________________ You will see that the tab has not worked. The string "module_info/0 module_info/1 start/2 stop/1" was not withdrawn. This is not good. You still can do the following: Go to the new line (press the button enter) and enter a space as long as the input field team did not go on 2 lines below. _____________________________________________________ 1> _____________________________________________________ Enter "ssh_app:". ____________________________________________________ 1> ssh_app: _____________________________________________________ Press tab. _____________________________________________________ 1> 1> ssh_app: _____________________________________________________ You will see that the tab has not worked. The string "module_info/0 module_info/1 start/2 stop/1" was not withdrawn. This is not good. -- --------------------------------------------- With best regards, Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh_expand_test.tar.gz Type: application/x-gzip Size: 5857 bytes Desc: not available URL: From henrik@REDACTED Thu Nov 21 11:25:20 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 21 Nov 2013 11:25:20 +0100 Subject: [erlang-patches] SSH-daemon invalid column calculation at ssh_cli:delete_chars() In-Reply-To: References: Message-ID: <528DDF90.8070508@erlang.org> Hi Alexander! I have created a pull request for this to make sure it will get into the system and assigned to the proper team etc. Thank you for your contribution! On 2013-11-21 03:51, Alexander Demidenko wrote: > Hello, friends. > > How can I see, in the ssh_cli.erl module, delete_chars method > incorrectly calculate variable "NewCol". > > I can offer the option of a patch that fixes this problem. > The person who is responsible for supporting ssh has the discretion to > take it as it is, or can make own fix. > Tested by Erlang 16B02, ssh 2.1.8 and R15B02, ssh 2.1.1 > > hurd@REDACTED:~/Documents/Erlang/reports/ssh_expand_test$ cat ssh.patch > --- ssh-2.1.1/src/ssh_cli.erl2013-10-26 14:25:26.000000000 > +++ ssh-2.1.2/src/ssh_cli.erl2013-10-26 14:18:18.000000000 > @@ -311,13 +319,14 @@ > NewBufTail = nthtail(N, BufTail), > M = move_cursor(Col + length(NewBufTail) + N, Col, Tty), > {[NewBufTail, lists:duplicate(N, $ ) | M], > {Buf, NewBufTail, Col}}; > delete_chars(N, {Buf, BufTail, Col}, Tty) -> % N < 0 > NewBuf = nthtail(-N, Buf), > - NewCol = Col + N, > + NewCol = case Col + N of V when V >= 0 -> V; _ -> 0 end, > M1 = move_cursor(Col, NewCol, Tty), > M2 = move_cursor(NewCol + length(BufTail) - N, NewCol, Tty), > {[M1, BufTail, lists:duplicate(-N, $ ) | M2], > {NewBuf, BufTail, NewCol}}. > %%% Window change, redraw the current line (and clear out after it > > > I attached simple sample, where you can see this problem. > To run it, compile ssh_manager.erl and invoke "ssh_manager:start()" > method to run ssh-daemon. > Then run simple ssh-client on terminal to localhost on port 9999, and > entering the password "test". > (you need put keys in .ssh folder) > Below example show trouble with the display of available commands when > you press Tab. > > At the command prompt "ssh_app:" > _____________________________________________________ > 1> ssh_app: > _____________________________________________________ > > Press tab. > _____________________________________________________ > 1> ssh_app: > module_info/0 module_info/1 start/2 stop/1 > 1> ssh_app: > _____________________________________________________ > > You will see the line below "module_info/0 module_info/1 start/2 > stop/1," and below that "ssh_app:". > Everything is wonderful. Yet. > > Do the following: Go to the new line (Press enter) and enter a space > as long as the input field team did not go on the line below . > _____________________________________________________ > 1> > _____________________________________________________ > > Enter "ssh_app:" > > _____________________________________________________ > 1> > ssh_app: > _____________________________________________________ > > Press tab. > _____________________________________________________ > 1> > ssh_app: > 1> > ssh_app: > _____________________________________________________ > > You will see that the tab has not worked. The string "module_info/0 > module_info/1 start/2 stop/1" was not withdrawn. > This is not good. > > You still can do the following: Go to the new line (press the button > enter) and enter a space as long as the input field team did not go on > 2 lines below. > _____________________________________________________ > 1> > _____________________________________________________ > > Enter "ssh_app:". > ____________________________________________________ > 1> > ssh_app: > _____________________________________________________ > > Press tab. > > _____________________________________________________ > 1> > 1> > > ssh_app: > _____________________________________________________ > > You will see that the tab has not worked. The string "module_info/0 > module_info/1 start/2 stop/1" was not withdrawn. This is not good. > > -- > --------------------------------------------- > With best regards, > Alexander. > > > _______________________________________________ > 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 alex.demidenko@REDACTED Wed Nov 27 04:35:55 2013 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Wed, 27 Nov 2013 10:35:55 +0700 Subject: [erlang-patches] stdlib 1.19.3, edlin.erl Key mapping extension for some unix-terminals. Message-ID: Hello, friends! Key mapping extension for some terminals. Add support new code sequences for: , , , + --- lib/stdlib/src/edlin.erl +++ lib/stdlib/src/edlin.erl @@ -232,12 +212,26 @@ key_map($F, meta_o) -> end_of_line; key_map($\177, none) -> backward_delete_char; key_map($\177, meta) -> backward_kill_word; key_map($[, meta) -> meta_left_sq_bracket; key_map($D, meta_left_sq_bracket) -> backward_char; key_map($C, meta_left_sq_bracket) -> forward_char; + +% Eltex patch +% support a +key_map($H, meta_left_sq_bracket) -> beginning_of_line; +% support a +key_map($F, meta_left_sq_bracket) -> end_of_line; +% support a +key_map($3, meta_left_sq_bracket) -> {csi, "3"}; +key_map($~, {csi, "3"}) -> forward_delete_char; +% support a + +key_map($;, {csi, "3"}) -> {csi, "3;"}; +key_map($5, {csi, "3;"}) -> {csi, "3;5"}; +key_map($~, {csi, "3;5"}) -> kill_word; + % support a few + combinations... % - forward: \e\e[C, \e[5C, \e[1;5C % - backward: \e\e[D, \e[5D, \e[1;5D key_map($\e, meta) -> meta_meta; key_map($[, meta_meta) -> meta_csi; key_map($C, meta_csi) -> forward_word; -- --------------------------------------------- With best regards, Alexander. Eltex -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Thu Nov 28 11:00:00 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 28 Nov 2013 11:00:00 +0100 Subject: [erlang-patches] Add name_in_archive option to erl_tar:add/3 In-Reply-To: <1381925595.4823.37.camel@sekic1152.release> References: <1381925595.4823.37.camel@sekic1152.release> Message-ID: On Wed, Oct 16, 2013 at 2:13 PM, Bengt Kleberg wrote: > git fetch git://github.com/ebengt/otp.git erl_tar_add3_name_option > > > https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option > > https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option.patch > > > Rejected. Since the name in the archive varies with each file, having to put it in the option list is incovenient at best. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Thu Nov 28 13:44:43 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 28 Nov 2013 13:44:43 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: On Wed, Nov 14, 2012 at 5:42 PM, Anthony Ramine wrote: > This patch implements EEP37: Funs with names > > It is now much closer to being graduated. I have added the branch to our daily builds for the master branch. I would like a comment from Kostis about the Dialyzer changes. What also remains is coverage in test suites. I have fixed a few, but xref_SUITE remains to be fixed (a named fun with the '_' name should be tested). Here are my fixes for the test suites (also included as an attachment to make it easier to apply): diff --git a/lib/compiler/test/fun_SUITE.erl b/lib/compiler/test/fun_SUITE.erl index 0ff846e..e35692e 100644 --- a/lib/compiler/test/fun_SUITE.erl +++ b/lib/compiler/test/fun_SUITE.erl @@ -197,10 +197,14 @@ external(Config) when is_list(Config) -> call_me(I) -> {ok,I}. -id(I) -> - I. - eep37(Config) when is_list(Config) -> F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, + Add = fun _(N) -> N + 1 end, + UnusedName = fun BlackAdder(N) -> N + 42 end, 720 = F(6), + 10 = Add(9), + 50 = UnusedName(8), ok. + +id(I) -> + I. diff --git a/lib/debugger/test/fun_SUITE.erl b/lib/debugger/test/fun_SUITE.erl index 569af6c..75e3b55 100644 --- a/lib/debugger/test/fun_SUITE.erl +++ b/lib/debugger/test/fun_SUITE.erl @@ -288,10 +288,14 @@ external(Config) when is_list(Config) -> call_me(I) -> {ok,I}. -id(I) -> - I. - eep37(Config) when is_list(Config) -> F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, + Add = fun _(N) -> N + 1 end, + UnusedName = fun BlackAdder(N) -> N + 42 end, 720 = F(6), + 10 = Add(9), + 50 = UnusedName(8), ok. + +id(I) -> + I. diff --git a/lib/stdlib/test/erl_lint_SUITE.erl b/lib/stdlib/test/erl_lint_SUITE.erl index ea90793..ad51bfa 100644 --- a/lib/stdlib/test/erl_lint_SUITE.erl +++ b/lib/stdlib/test/erl_lint_SUITE.erl @@ -644,7 +644,9 @@ unused_vars_warn_fun(Config) when is_list(Config) -> u() -> fun U(U) -> foo end; % U shadowed. U unused. u() -> - fun U(1) -> U; U(U) -> foo end. % U shadowed. U unused. + fun U(1) -> U; U(U) -> foo end; % U shadowed. U unused. + u() -> + fun _(N) -> N + 1 end. % Cover handling of '_' name. ">>, [warn_unused_vars], {error,[{3,erl_lint,{unbound_var,'U'}}], id/1 is a common help function, so I want it to remain at the end of the file. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fixup-Test-named-funs.patch Type: text/x-patch Size: 2323 bytes Desc: not available URL: From n.oxyde@REDACTED Thu Nov 28 13:52:29 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 28 Nov 2013 13:52:29 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: Hello Bj?rn, Replied inline. -- Anthony Ramine Le 28 nov. 2013 ? 13:44, Bj?rn Gustavsson a ?crit : > On Wed, Nov 14, 2012 at 5:42 PM, Anthony Ramine wrote: > This patch implements EEP37: Funs with names > > > It is now much closer to being graduated. > > I have added the branch to our daily builds for the master branch. Cool. > I would like a comment from Kostis about the Dialyzer changes. Me too, he suggested to me that it might break HiPE too but I couldn?t make HiPE crash. > What also remains is coverage in test suites. I have fixed a few, > but xref_SUITE remains to be fixed (a named fun with the '_' name > should be tested). Will do. > Here are my fixes for the test suites (also included as an attachment > to make it easier to apply): Will apply. > diff --git a/lib/compiler/test/fun_SUITE.erl b/lib/compiler/test/fun_SUITE.erl > index 0ff846e..e35692e 100644 > --- a/lib/compiler/test/fun_SUITE.erl > +++ b/lib/compiler/test/fun_SUITE.erl > @@ -197,10 +197,14 @@ external(Config) when is_list(Config) -> > call_me(I) -> > {ok,I}. > > -id(I) -> > - I. > - > eep37(Config) when is_list(Config) -> > F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, > + Add = fun _(N) -> N + 1 end, > + UnusedName = fun BlackAdder(N) -> N + 42 end, > 720 = F(6), > + 10 = Add(9), > + 50 = UnusedName(8), > ok. > + > +id(I) -> > + I. > diff --git a/lib/debugger/test/fun_SUITE.erl b/lib/debugger/test/fun_SUITE.erl > index 569af6c..75e3b55 100644 > --- a/lib/debugger/test/fun_SUITE.erl > +++ b/lib/debugger/test/fun_SUITE.erl > @@ -288,10 +288,14 @@ external(Config) when is_list(Config) -> > call_me(I) -> > {ok,I}. > > -id(I) -> > - I. > - > eep37(Config) when is_list(Config) -> > F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, > + Add = fun _(N) -> N + 1 end, > + UnusedName = fun BlackAdder(N) -> N + 42 end, > 720 = F(6), > + 10 = Add(9), > + 50 = UnusedName(8), > ok. > + > +id(I) -> > + I. > diff --git a/lib/stdlib/test/erl_lint_SUITE.erl b/lib/stdlib/test/erl_lint_SUITE.erl > index ea90793..ad51bfa 100644 > --- a/lib/stdlib/test/erl_lint_SUITE.erl > +++ b/lib/stdlib/test/erl_lint_SUITE.erl > @@ -644,7 +644,9 @@ unused_vars_warn_fun(Config) when is_list(Config) -> > u() -> > fun U(U) -> foo end; % U shadowed. U unused. > u() -> > - fun U(1) -> U; U(U) -> foo end. % U shadowed. U unused. > + fun U(1) -> U; U(U) -> foo end; % U shadowed. U unused. > + u() -> > + fun _(N) -> N + 1 end. % Cover handling of '_' name. > ">>, > [warn_unused_vars], > {error,[{3,erl_lint,{unbound_var,'U'}}], > > > id/1 is a common help function, so I want it to remain at the end > of the file. Thanks for nitpicking even more than myself :p > /Bjorn From lukas@REDACTED Fri Nov 29 10:57:55 2013 From: lukas@REDACTED (Lukas Larsson) Date: Fri, 29 Nov 2013 10:57:55 +0100 Subject: [erlang-patches] add o_sync option to file:open/2 In-Reply-To: References: Message-ID: <52986523.2070600@erlang.org> Hello, I've just merged this into master so it will be part of the next major release. Thank you for your contribution. Lukas On 12/11/13 23:39, Steve Vinoski wrote: > https://github.com/erlang/otp/pull/137 > > This pull request adds an o_sync option to file:open/2. The o_sync > option adds the POSIX O_SYNC flag to the open system call on platforms > that support the flag or its equivalent, e.g., FILE_FLAG_WRITE_THROUGH > on Windows. For platforms that don't support it, file:open/2 returns > {error, enotsup} if the o_sync option is passed in. > > Joe Blomstedt (jtuple) wrote most of this patch, I just dotted the Ts, > crossed the Is, and submitted it. > > --steve > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Fri Nov 29 16:22:30 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Fri, 29 Nov 2013 16:22:30 +0100 Subject: [erlang-patches] Improving ETS performances In-Reply-To: <20130910102235.GA4812@wagner.intra.a-tono.com> References: <20130910102235.GA4812@wagner.intra.a-tono.com> Message-ID: <5298B136.7040608@erix.ericsson.se> Hi This patch has now been discussed by OTP technical board. It's a desirable feature but the patch is not acceptable as-is, mainly due to too large memory overhead per object. We would need * No extra overhead for table type 'set'. * Minimized overhead per object for 'bag' and 'duplicate_bag', especially when the nested hash feature is not used. Another weakness is the lack of yielding when long key chains are traversed. BIFs should not execute too long but rather yield by returning back to the emulator loop to be continued later by the scheduler (as is done by the ets:select operations). The patch removes this problem for unrelated keys but it still arise at lookup/delete on a lot of objects with same key. If an otherwise accepted patch is supplied we can undertake the job to fix the yielding. It can be good to have in mind though while doing the design. Some tips and tricks to minimize memory overhead: (some of them are probably mutually exclusive) * Use lower bits in pointers as flags. * Combine next and kprevious as only one of them is used. * Move nkitems and lht into a separate root struct that is allocated when the first duplicate key is inserted. * Move knext and kprevious to NestedDbTerm to only allocate them when needed. * Use really dirty trick to allocate a mutilated struct with an unused prologue. typedef struct { HashDbTerm* previous; /* NOT ACCESSABLE FOR SET */ HashDbTerm* next; HashValue hvalue; DbTerm dbterm; }HashDbTerm; /* For bags */ ptr = malloc(sizeof(HashDbTerm)); /* For sets */ ptr = malloc(sizeof(HashDbTerm) - offsetof(HashDbTerm,next)); ptr = (char*)ptr - offsetof(HashDbTerm,next); ptr->next = ...; ptr->hvalue = ...; ptr->dbterm = ...; ptr->previous = NULL; /* MEMORY CORRUPTION!!! */ free((char*)ptr + offsetof(HashDbTerm,next)); Maybe there are more sensible ways to accomplish the same thing. /Sverker Erlang/OTP @ Ericsson On 09/10/2013 12:22 PM, Francesco Lattanzio wrote: > G'day people, > I would like to share with you an "improvement" patch, in the hope > that some day it will be included in the official releases. > For this is going to be a long e-mail, I have split it into two section, > a brief one for those in a hurry and a detailed one (an EEPlight) for > those who want/need to know more. > > NOTE: This e-mail contain some ASCII graphics, please read it using a > constant width font. > > BRIEF SECTION > > The patch targets ETS tables of the 'bag' and 'duplicate_bag' types, > improving performances of deletion by objects (i.e., ets:delete_object/2 > not ets:delete/2) and insertion when working with many object sharing > the same key. > > The patch is available at: > > git fetch https://github.com/fltt/otp.git ets_nested_lht > > https://github.com/fltt/otp/compare/erlang:maint...ets_nested_lht > https://github.com/fltt/otp/compare/erlang:maint...ets_nested_lht.patch > > To get a feel of the performance gain you can run the following snippet > of code both before and after applying the patch: > > > -module(ets_hash_test). > -export([test2/1]). > > write_loop(N, Tab) > when N > 0 -> > ok=mnesia:activity(sync_dirty, > fun() -> > mnesia:write(Tab, {Tab, N, erlang:integer_to_list(N), N rem 10}, write) > end, > mnesia_frag), > write_loop(N-1, Tab); > write_loop(_, _) -> > ok. > > verify_loop(N, Tab) > when N > 0 -> > Expected={Tab, N, erlang:integer_to_list(N), N rem 10}, > [Expected]= > mnesia:activity(sync_dirty, > fun() -> > mnesia:read(Tab, N, read) > end, > mnesia_frag), > verify_loop(N-1, Tab); > verify_loop(_, _) -> > ok. > > test2(TabSize) -> > TabName=frag_test, > ThisNode=erlang:node(), > ok=mnesia:start(), > {atomic, ok}= > mnesia:create_table(TabName, [{type, set}, > {attributes, [key, datum1, datum2]}, > {frag_properties, [{n_fragments, 1}, > {node_pool, [ThisNode]}]}]), > ok=write_loop(TabSize, TabName), > {Time, {atomic, ok}}= > timer:tc(fun() -> > mnesia:change_table_frag(TabName, {add_frag, [ThisNode]}) > end), > ok=verify_loop(TabSize, TabName), > stopped=mnesia:stop(), > {ok, Time}. > > > On my own PC I obtain the following results: > > Before: > test2(10000) -> {ok, 1691416} > test2(100000) -> {ok, 538015238} > > After: > test2(10000) -> {ok, 55239} > test2(100000) -> {ok, 745721} > > A last note: THIS IS EXPERIMENTAL CODE, USE IT AT YOUR OWN RISK. > In other words, this patch is still a work in progress and not > production ready. > For more details read on. > > DETAILED SECTION (EPPlight) > > Why this new feature? > > First of all this is not a new feature -- from the point of view of the > developer there are no new modules, functions, language constructs nor > options. > > It all started by the need to dynamically add fragments to a NON-EMPTY > fragmented table (using the mnesia_frag access module). > As you know, a fragment with as little as 100000 takes far more than > tollerable to be split. > > Analyzing mnesia's source code, it came out that the culprit is the > temporary storage of all the write operations under the same key in an > ETS table of the bag type. > ETS of the set, bag and duplicate_bag types use linear hashing to store > objects, thus inserting objects _with different keys_ in an ETS has O(1) > time complexity. > However, if all the objects inserted have the same key then time > complexity changes to O(k), where k is the number of objects sharing the > same key. > This is so for, in the current implementation, objects with the same > keys are all put in a simply linked list and when looking for duplicates > the whole list must be traversed. > > Risks/uncertain artifacts > > None, as far I can tell _now_. > However this patch is still experimental and I have tested it only under > Linux (ArchLinux). > Moreover, it should be optimized to reduce memory consuption, and some > code clean-up wouldn't harm. > > How did I solve it? > > Nested linear hash tables. But first some internal data structures must > be reorganized. > Reorganization is achieved by use of "bidimensional lists", i.e., > something like this: > > NULL NULL NULL > ^ kprevious ^ kprevious ^ > kprevious | | | > ----------+ +------+ next +------+ next +------+ next > bucket[i] |-->| Obj1 |------->| Obj3 |------->| Obj4 |----->NULL > ----------+ +------+ +------+ +------+ > ^ | knext knext | ^ | knext > kprevious | V V kprevious | V > +------+ NULL +------+ > | Obj2 | | Obj5 | > +------+ +------+ > | knext | knext > V V > NULL NULL > > All the ObjXs use the same data structure (a modified HashDbTerm). > Obj1 and Obj2 share the same key, as well as Obj4 and Obj5 do. > Obj2 and Obj5's next pointers are unused. > In the code Obj1, Obj3 and Obj4 are also referenced as "root nodes". > > Why the doubly linked list? As the "next chain" is traversed > sequentially, adding and removing objects is easy thing. > Whereas, to achieve the O(1) complexity, the "kprevious/knext chain" > must be accessible randomly (we'll see how in a moment). > Also, the order of insertion must be preserved, thus we cannot throw > away the linked list and substitute it with a hash table. > > Now we are ready to introduce the nested linear hash table. > When the kprevious/knext chain reach some minimum length > (DB_BAG_LHT_LEN, which I arbitrarily set at 128), an empty linear hash > table is created and a pointer to it is installed in the root node (Obj1 > or Obj4, not Obj2 nor Obj5). > Then it is filled with references to the objects of the kprevious/knext > chain, keyed with the hash value of the whole objects (Obj1 and Obj2 in > Obj1's nested LHT or Obj4 and Obj5 in Obj4's nested LHT). > > By now it should be clear how things work: whenever an object is looked > for, first the next chain is traversed to find the key, then, if a > nested LHT is installed in the root node found, a lookup is performed on > the hash value of the object. > If there's no nested LHT, a sequential traversal is performed. > > Sorry, I exceeded the 200 words limit, but I thing that that is the > minimum required to understand the whys and hows of this patch. > > There is more to be said, however the source code is more appropriate to > describe all the minute details of the implementation. > Also, note that the patch introduces some specially marked comments, like > this: > > /* ??? some question ??? */ > > These are questions and doubts I couldn't answer by myself and that I > ask you to find an appropriate answer. > > Comments are welcome, especially on how to optimize for speed and > memory consumption. > Please, don't hesitate to contact me for further details. > > Have a nice day. >