From serge@REDACTED Fri Jan 3 16:30:03 2014 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 3 Jan 2014 10:30:03 -0500 Subject: [erlang-patches] Add net_kernel and epmd support for multiple simultaneous distributed transport protocols Message-ID: I'd like to inquire the status of the following pull request: https://github.com/erlang/otp/pull/121 Has it been reviewed? Thanks! Serge -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Tue Jan 7 09:55:21 2014 From: henrik@REDACTED (Henrik Nord) Date: Tue, 7 Jan 2014 09:55:21 +0100 Subject: [erlang-patches] Add net_kernel and epmd support for multiple simultaneous distributed transport protocols In-Reply-To: References: Message-ID: <52CBC0F9.4060803@erlang.org> This is waiting for a technical board ruling. so still no news I'm afraid On 2014-01-03 16:30, Serge Aleynikov wrote: > I'd like to inquire the status of the following pull request: > https://github.com/erlang/otp/pull/121 > > Has it been reviewed? > > Thanks! > > Serge > > > _______________________________________________ > 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 Wed Jan 8 05:38:29 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 7 Jan 2014 23:38:29 -0500 Subject: [erlang-patches] erlang.el fixes Message-ID: In the #erlang room on IRC, user leo2007 suggested some changes to the emacs file erlang.el to prevent some errors. Details are in this pull request: https://github.com/erlang/otp/pull/189 --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Wed Jan 8 15:21:12 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 8 Jan 2014 15:21:12 +0100 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: Message-ID: On Fri, Dec 20, 2013 at 2:05 AM, Steve Vinoski wrote: > I've modified the branch as requested. > > https://github.com/erlang/otp/pull/91 > > Thanks! I have addet it to our daily builds for testing. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Wed Jan 8 16:11:46 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 8 Jan 2014 16:11:46 +0100 Subject: [erlang-patches] Fix evaluation of and also and orelse in the debugger In-Reply-To: <69CBECDF-CE28-4394-B0EF-D55641807695@gmail.com> References: <69CBECDF-CE28-4394-B0EF-D55641807695@gmail.com> Message-ID: On Mon, Dec 16, 2013 at 12:50 PM, Anthony Ramine wrote: > Hello, > > While implementing cond, I stumbled onto that bug. > > git fetch https://github.com/nox/otp.gitfix-dbg_ieval-exporting-rules > > https://github.com/erlang/otp/pull/171 > > https://github.com/nox/otp/compare/fix-dbg_ieval-exporting-rules > > https://github.com/nox/otp/compare/fix-dbg_ieval-exporting-rules.patch > > Thanks! Looks good. I have added it to our daily builds for testing. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Jan 9 10:48:02 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 9 Jan 2014 10:48:02 +0100 Subject: [erlang-patches] Strange thing in lib/kernel/src/group.erl In-Reply-To: <1368697279.31752.129.camel@ax-sze> References: <420733710.105442810.1368130413119.JavaMail.root@erlang-solutions.com> <1368174231.31752.112.camel@ax-sze> <1368697279.31752.129.camel@ax-sze> Message-ID: Hello, this patch has been converted to a bug-report and a ticket is created and placed in our backlog. The reason for this is that we believe the matter needs further investigation, which we have not been able to make time for yet. The ticket will be prioritized along with the rest of the items in our backlog. Thanks for your contribution! Best Regards /siri 2013/5/16 Stefan Zegenhagen > Dear all, > > since the discussion seems to have gotten quiet, I've prepared a patch > to restart the discussion of this topic. > > In an interactive shell, the shell process has no means to reliably get > the exit reason of the associated user_drv and, therefore, cannot > meaningfully react on errors reported by the user_drv. However, it > occasionally is required to know why an interactive shell session was > terminated. > > The patch attached to this e-mail solves the issue by always propagating > the exit reason of the user_drv to the shell process. In summary, the > patch does the following: > > * propagate the correct exit reason of the user_drv to the shell > under all circumstances > * always make sure that the shell process terminates when the > user_drv has exited > * give the shell process two seconds time to react on the exit > signal before forcedly killing it > > Shell processes using I/O functionality from the io.erl module will be > largely unaffected because io.erl catches exits of the group_leader() > during io_requests and translates them to {error, terminated} error > codes (independent of the exit reason found in the exit signal). Shell > processes implementing the I/O protocol themselfs might experience > unexpected 'EXIT' reasons. > > The patch makes sure that shell is forcedly killed as before, it only > gives the shell process a little time to terminate itself before doing > so. It also makes sure that the shell is killed under *ALL* > circumstances, not just while some I/O client is waiting for input. > > > Kind regards, > > -- > Dr. Stefan Zegenhagen > > arcutronix GmbH > Garbsener Landstr. 10 > 30419 Hannover > Germany > > Tel: +49 511 277-2734 > Fax: +49 511 277-2709 > Email: stefan.zegenhagen@REDACTED > Web: www.arcutronix.com > > *Synchronize the Ethernet* > > General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - > Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht > Hannover; Ust-Id: DE257551767. > > Please consider the environment before printing this message. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.zegenhagen@REDACTED Thu Jan 9 11:02:59 2014 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Thu, 09 Jan 2014 11:02:59 +0100 Subject: [erlang-patches] Strange thing in lib/kernel/src/group.erl In-Reply-To: References: <420733710.105442810.1368130413119.JavaMail.root@erlang-solutions.com> <1368174231.31752.112.camel@ax-sze> <1368697279.31752.129.camel@ax-sze> Message-ID: <1389261779.10299.18.camel@ax-sze> Hi Siri, > this patch has been converted to a bug-report and a ticket is created and > placed in our backlog. The reason for this is that we believe the matter > needs further investigation, which we have not been able to make time for > yet. The ticket will be prioritized along with the rest of the items in our > backlog. I'm looking forward for the result of the investigation because some features of our software need error propagation to be working, mostly security-related features and error logging. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From kenneth.lundin@REDACTED Thu Jan 9 16:53:59 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 9 Jan 2014 16:53:59 +0100 Subject: [erlang-patches] Add net_kernel and epmd support for multiple simultaneous distributed transport protocols In-Reply-To: References: Message-ID: On Fri, Jan 3, 2014 at 4:30 PM, Serge Aleynikov wrote: > I'd like to inquire the status of the following pull request: > https://github.com/erlang/otp/pull/121 > > Has it been reviewed? > > Thanks! > > Serge > > Hi Serge, We have discussed your contribution at the OTP technical board and here are the results: Inclusion in OTP ----------------------- Your patch touches many source files which are central for the Erlang distribution and we feel it would require quite a lot of work from our side as well to assure that nothing in the current distribution gets broken or incompatible. It would also require quite deep involvement from us giving more detailed feedback regarding interfaces, semantics etc. We can not prioritize this at the moment so we will not include your contribution now (which means REJECT for now). But we really want to add this kind of functionality and want to encourage you (and others) to continue the good work in this area for possible inclusion in OTP at a later stage. See more info and thoughts below. General thoughts ----------------------- Enhancing/extending the Erlang distribution to support heterogenous communication protocols is something we have discussed many times and it is something that we really would like to have. 1) We would like a plugin architecture where different transport protocols can be easily plugged in without having to change the basic Erlang distribution or the VM. 2) It should be possible to run different protocols towards different nodes 3) should be possible to have different timeouts (NET_TICK_TIME) per connection 4) interesting protocols would be UDS, TCP, TLS over TCP, SCTP, ... 5) it should be possible to look up nodes in different ways and maybe not only via contacting epmd on the host name which is part of the node name. I.e having the hostname as part of the node name is not always what you want, depending on protocol to use. .... Your specific contribution ----------------------------------- In your pull request you have implemented fully or partly 1,2, 4, and we see it as a good start. A general comment is that the diffs are showing differences on many places in the code where you actually haven't changed anything except tabs, line breaks and spaces. This makes it more difficult to sort out what you have changed and added. We would like a clean diff without unnecessary touches lines which has no relevance for the new function. If a formatting change is needed or suggested it should be a separate commit/pull request. Regarding details in your code we have not had the time to take a deeper look but from a quick glance it looks good. The questionmarks are more about how to introduce this new functionality in a safe way and what more is needed that you have not addressed so far. Suggested way forward ------------------------------ I think that one approach that would make it easier to include this kind of functionality soon would be to make minimal changes to the existing distribution code and only add or change so that it is possible to support heterogenous protocols with code that initially can live as a separate extension that don't need to be part of the OTP distro. In this way the functionality can be further developed and used together with an ordinary OTP distro (unpatched) and can easily be included later (hopefully within a year). Maybe you think that you already have done those minimal changes, but I suggest you take another look and see if it is possible to find a way to make minimal or now changes to net_kernel and epmd etc. which we could include and then have the rest as a separate "application"/extension project at github that can be included later. Just some thoughts: Maybe let the old distribution work as before and let the user choose "new_distro" in some way and will only then get to run the new code which allows heterogenous protocols another new EPMD or an EPMD written in Erlang or allow for plugins of different EPMD implementations that can run in parallell. The communication towards EPMD maybe needs to be secure as well and then it might be much easier to implement in Erlang. I (we) are more than willing to discuss more about how to find this minimal patch which we think we can "safely" include and which makes it possible to develop and use the rest as pure extensions to OTP in a first step. Regards Kenneth, Erlang/OTP Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Thu Jan 9 21:26:34 2014 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 9 Jan 2014 15:26:34 -0500 Subject: [erlang-patches] Add net_kernel and epmd support for multiple simultaneous distributed transport protocols In-Reply-To: References: Message-ID: Kenneth, Thank you for the thorough response! Your reasoning is appealing and I'd like to engage in the discussion on how we can move on to include this functionality in the distribution, as I believe the community will benefit greatly from being able to run an Erlang node listening on multiple transports concurrently. The changes in the patch (https://github.com/erlang/otp/pull/121) cover the following areas: 1. Extension of the EPMD distributed protocol (here we can safely add new set of commands while being fully backward compatible) erts/doc/src/erl_dist_protocol.xml 2. Modification of the EPMD daemon to support the new protocol version and to keep track of the multiple protocols/ports per node (this is also done in a backward compatible way. Nodes supporting new protocol version communicate using new spec, and old nodes communicate using old spec) erts/epmd/src/epmd.h erts/epmd/src/epmd.c 3. Modification of the EPMD command-line tool to talk to the local EPMD daemon using the new protocol version (the command-line tool uses new protocol version. This is reasonable, since it's installed together with the version of VM supporting the new EPMD protocol features) erts/epmd/src/epmd_cli.c erts/epmd/src/epmd_cli.c erts/epmd/src/epmd_int.h erts/epmd/src/epmd_srv.c 4. Updates of the UDS distribution example code. I believe the example in the current release is outdated (I was unable to compile it), but I patched it anyway to illustrate the usage of the new protocol) lib/kernel/examples/uds_dist/src/dist_selector.erl lib/kernel/examples/uds_dist/src/uds_dist.erl lib/kernel/examples/uds_dist/src/uds_server.erl 5. Change of the net_kernel transport pluggable architecture to allow support of the new EPMD protocol. 5.1 Net_kernel support for the new protocol. 5.2 TCPv4 support of the new protocol 5.3 TCPv6 support of the new protocol 5.4 TLS support of the new protocol lib/kernel/src/net_kernel.erl lib/kernel/src/dist_util.erl lib/kernel/src/inet6_tcp_dist.erl lib/kernel/src/inet_tcp_dist.erl lib/kernel/src/net_kernel.erl lib/ssl/src/inet_tls_dist.erl lib/ssl/src/ssl_tls_dist_proxy.erl lib/kernel/doc/src/net_kernel.xml It seems to me that we could roll it out in two phases: 1. Implement 1,2,3 in the first phase. This would allow to deploy a version with EPMD supporting old and new protocols. 2. Implement changes to net_kernel and transports (4,5) to be able to talk to new EPMDs If agreed, I can break up my patch in two, corresponding to this plan. What do you think? Serge On Thu, Jan 9, 2014 at 10:53 AM, Kenneth Lundin wrote: > On Fri, Jan 3, 2014 at 4:30 PM, Serge Aleynikov wrote: > >> I'd like to inquire the status of the following pull request: >> https://github.com/erlang/otp/pull/121 >> >> Has it been reviewed? >> >> Thanks! >> >> Serge >> >> Hi Serge, > > We have discussed your contribution at the OTP technical board and here > are the results: > > Inclusion in OTP > ----------------------- > > Your patch touches many source files which are central for the Erlang > distribution and we feel it would require quite a lot of work from our side > as well to assure that nothing in the current distribution gets broken or > incompatible. It would also require quite deep involvement from us giving > more detailed feedback regarding interfaces, semantics etc. We can not > prioritize this at the moment so we will not include your contribution now > (which means REJECT for now). > > But we really want to add this kind of functionality and want to encourage > you (and others) to continue the good work in this area for possible > inclusion in OTP at a later stage. See more info and thoughts below. > > > General thoughts > ----------------------- > > Enhancing/extending the Erlang distribution to support heterogenous > communication protocols is something we have discussed many times and it is > something that we really would like to have. > > 1) We would like a plugin architecture where different transport protocols > can be easily plugged in without having to change the basic Erlang > distribution or the VM. > > 2) It should be possible to run different protocols towards different nodes > > 3) should be possible to have different timeouts (NET_TICK_TIME) per > connection > > 4) interesting protocols would be UDS, TCP, TLS over TCP, SCTP, ... > > 5) it should be possible to look up nodes in different ways and maybe not > only via contacting epmd on the host name which is part of the node name. > I.e having the hostname as part of the node name is not always what you > want, depending on protocol to use. > > .... > > Your specific contribution > ----------------------------------- > In your pull request you have implemented fully or partly 1,2, 4, and we > see it as a good start. > > A general comment is that the diffs are showing differences on many places > in the code where you actually haven't changed anything except tabs, line > breaks and spaces. This makes it more difficult to sort out what you have > changed and added. We would like a clean diff without unnecessary touches > lines which has no relevance for the new function. If a formatting change > is needed or suggested it should be a separate commit/pull request. > > Regarding details in your code we have not had the time to take a deeper > look but from a quick glance it looks good. The questionmarks are more > about how to introduce this new functionality in a safe way and what more > is needed that you have not addressed so far. > > > Suggested way forward > ------------------------------ > > I think that one approach that would make it easier to include this kind > of functionality soon would be to make minimal changes to the existing > distribution code and only add or change so that it is possible to support > heterogenous protocols with code that initially can live as a separate > extension that don't need to be part of the OTP distro. > In this way the functionality can be further developed and used together > with an ordinary OTP distro (unpatched) and can easily be included later > (hopefully within a year). > > Maybe you think that you already have done those minimal changes, but I > suggest you take another look and see if it is possible to find a way to > make minimal or now changes to net_kernel and epmd etc. which we could > include and then have the rest as a separate "application"/extension > project at github that can be included later. > > Just some thoughts: > Maybe let the old distribution work as before and let the user choose > "new_distro" in some way and will only then get to run the new code which > allows heterogenous protocols another new EPMD or an EPMD written in Erlang > or allow for plugins of different EPMD implementations that can run in > parallell. The communication towards EPMD maybe needs to be secure as well > and then it might be much easier to implement in Erlang. > > I (we) are more than willing to discuss more about how to find this > minimal patch which we think we can "safely" include and which makes it > possible to develop and use the rest as pure extensions to OTP in a first > step. > > Regards Kenneth, Erlang/OTP Ericsson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nem@REDACTED Thu Jan 9 23:10:31 2014 From: nem@REDACTED (Geoff Cant) Date: Thu, 9 Jan 2014 14:10:31 -0800 Subject: [erlang-patches] Add net_kernel and epmd support for multiple simultaneous distributed transport protocols In-Reply-To: References: Message-ID: On 2014-01-09, at 07:53 , Kenneth Lundin wrote: > ... > > > General thoughts > ----------------------- > > Enhancing/extending the Erlang distribution to support heterogenous communication protocols is something we have discussed many times and it is something that we really would like to have. > > 1) We would like a plugin architecture where different transport protocols can be easily plugged in without having to change the basic Erlang distribution or the VM. > > 2) It should be possible to run different protocols towards different nodes > > 3) should be possible to have different timeouts (NET_TICK_TIME) per connection > > 4) interesting protocols would be UDS, TCP, TLS over TCP, SCTP, ... > > 5) it should be possible to look up nodes in different ways and maybe not only via contacting epmd on the host name which is part of the node name. I.e having the hostname as part of the node name is not always what you want, depending on protocol to use. > > .... > I would like to add one general thought / principle to guide improvements to ERTS's distribution machinery: 'It should be possible to implement distribution protocols in Erlang' (The current setup requires us to implement complicated network protocols in C, which I find just about unbearable when Erlang is close at hand) Cheers, -- Geoff Cant From serge@REDACTED Thu Jan 9 23:51:14 2014 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 9 Jan 2014 17:51:14 -0500 Subject: [erlang-patches] Add net_kernel and epmd support for multiple simultaneous distributed transport protocols In-Reply-To: References: Message-ID: Having implemented full Erlang distributed transport natively in C++ and C#, I wouldn't say it's unbearable. However, in some special cases, it would indeed be interesting to bridge nodes implemented in dynamic languages (e.g. Javascript) via some protocol that could be more simple than the built-in distributed transport. Frankly I would be more interested in optimizing some parts of the existing transport, e.g. introducing special encoding 1-byte tags for boolean values (as opposed to encoding a boolean as an atom on the wire taking 6 to 7 bytes), and other similar optimizations. Another thing - after coding in Erlang for some time, one feels Erlang's choice of representing strings as integer lists is natural. However, when bringing different languages over distributed transport, you'd want a message {weights, [65, 66]} to be sent as a tuple with a second element being received on the other side as a list, but the distribution encodes it as {weights, "AB"}, and decoding it in a language that understands strings differently than lists becomes a bit more challenging than necessary... Personally, I think if Erlang supported string types as a special flavor of binaries it would be easier for it to live in heterogeneous clustered environments... Serge On Thu, Jan 9, 2014 at 5:10 PM, Geoff Cant wrote: > I would like to add one general thought / principle to guide improvements > to ERTS's distribution machinery: > > 'It should be possible to implement distribution protocols in Erlang' > > (The current setup requires us to implement complicated network protocols > in C, which I find just about unbearable when Erlang is close at hand) > > Cheers, > -- > Geoff Cant > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Sat Jan 11 02:56:52 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 10 Jan 2014 20:56:52 -0500 Subject: [erlang-patches] another erlang.el patch Message-ID: This patch to erlang.el prevents an error from arising from scan-sexp in emacs for certain indentation cases. Test case included in the patch. https://github.com/erlang/otp/pull/191 Thanks to Leo Liu for reporting this. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Sun Jan 12 16:19:49 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Sun, 12 Jan 2014 10:19:49 -0500 Subject: [erlang-patches] dialyzer man page fix Message-ID: A simple fix to the dialyzer man page for the -Wno_behaviours option: https://github.com/erlang/otp/pull/192 Thanks to Kostis for verifying the issue and suggesting the proper fix. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Jan 13 11:19:36 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 13 Jan 2014 11:19:36 +0100 Subject: [erlang-patches] hi-res windows icon In-Reply-To: References: Message-ID: <52D3BDB8.5020701@erlang.org> Hello, A new version of the icon has now been merged to master and will be part of the next release. We made some additional modifications to the icon to make it look even prettier! Lukas On 07/09/12 23:21, Daniel Goertzen wrote: > The Windows erlang application icon looks a little blocky, especially > when you have the text size turned up, so I added some higher > resolution images. > > I grabbed the image from http://www.erlang.org/doc/ , and used > paint.net and icofx to add true color 256x256, > 48x48, and 32x32 images to the icon. > > I implanted this icon into werl.exe using icofx; I am not prepared to > figure out compiling Erlang on Windows. See attached comparison of > old and new. > > It is on the fuzzy side and could use some hand-crafting from an > actual artist, but I find this one less jarring than the old one. > > Patch below... > > Dan. > > > > git fetch git://github.com/goertzenator/otp.git > win_icon > > https://github.com/goertzenator/otp/compare/win_icon > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Mon Jan 13 12:17:25 2014 From: henrik@REDACTED (Henrik Nord) Date: Mon, 13 Jan 2014 12:17:25 +0100 Subject: [erlang-patches] Use isfinite() instead of finite() when available In-Reply-To: References: Message-ID: <52D3CB45.4020507@erlang.org> Hi This fails on ~20 platforms. Linux x86 and linux powerpc *** CT Error Notification 2014-01-11 22:50:02.984 *** float_SUITE:fp_drv_test failed on line 130 Reason: load_error Full error description and stacktrace === Ended at 2014-01-11 22:50:02 === location [{float_SUITE,fp_drv_test,130}, {test_server,ts_tc,1360}, {test_server,run_test_case_eval1,977}, {test_server,run_test_case_eval,925}] === reason = {load_error,"wrong ELF class: ELFCLASS32"} ------------------------------------------------------------------------------------------------ *** CT Error Notification 2014-01-11 22:36:13.287 *** float_SUITE:fp_drv_test failed on line 130 Reason: load_error Full error description and stacktrace === Ended at 2014-01-11 22:36:13 === location [{float_SUITE,fp_drv_test,130}, {test_server,ts_tc,1360}, {test_server,run_test_case_eval1,977}, {test_server,run_test_case_eval,925}] === reason = {load_error,"undefined symbol: isfinite"} On 2013-11-15 02:53, 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, > -- /Henrik Nord Erlang/OTP From roger@REDACTED Tue Jan 14 17:51:21 2014 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 14 Jan 2014 16:51:21 +0000 Subject: [erlang-patches] Make SSL max plaintext size configurable Message-ID: We've discovered that the SSL/TLS application in Erlang assumes a max plaintext size of 2^14 (16384) bytes. We're communicating with an embedded device that, due to constrained resources, can't handle plaintext fragments larger than ~2Kb. In OpenSSL, the maximum plaintext fragment size can be configured by using the (barely documented) SSL_CTRL_SET_MAX_SEND_FRAGMENT control. We're converting our back-end server to Erlang, and we'd like to be able to do the same from Erlang. I asked about this here: http://stackoverflow.com/q/19276598/8446, where it was also suggested that we look at implementing the relevant section of RFC 6066, which defines a mechanism for negotiating this parameter. We've discarded that option because (a) RFC 6066 only allows for a limited set of values for this parameter; and (b) our embedded device currently only supports TLS 1.1, and RFC 6066 is an extension to TLS 1.2. I have a patch that implements this functionality, from the server side, at least: https://github.com/rlipscombe/otp/tree/rl-ssl-fragment-size To use this feature, simply specify {max_plain_text_length, N} in the Options passed to ssl:listen/2, as follows: {ok, LSock} = ssl:listen(17120, [{max_plain_text_length, 2000}, {certfile, "server.crt"}, {keyfile, "server.key"}]). If you don't specify the option, it defaults to 2^14. I've tested this with Wireshark, and can clearly see that the SSL message is broken into roughly 2Kb-sized fragments (allowing for some overhead). I'd like to: (a) get some comments on how it can be improved. (b) see if I can shepherd this patch upstream into a future release of Erlang/OTP. Things I am aware of: - Too many magic numbers. I attempted to put these values in ssl_record.hrl, but then discovered that not everything that needed the magic number included this file. In particular, I ended up needing it in ssl_internal.hrl. I'd appreciate suggestions for where the definitions of the magic numbers and types ought to go. - No documentation. I'm happy to add to the relevant docs as appropriate. I'd appreciate advice on how to proceed from here. Thanks, Roger. From kenneth.lundin@REDACTED Wed Jan 15 10:58:23 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 15 Jan 2014 10:58:23 +0100 Subject: [erlang-patches] Add net_kernel and epmd support for multiple simultaneous distributed transport protocols In-Reply-To: References: Message-ID: Hi Serge, See embedded comments at the end. On Thu, Jan 9, 2014 at 9:26 PM, Serge Aleynikov wrote: > Kenneth, > > Thank you for the thorough response! Your reasoning is appealing and I'd > like to engage in the discussion on how we can move on to include this > functionality in the distribution, as I believe the community will benefit > greatly from being able to run an Erlang node listening on multiple transports > concurrently. > > The changes in the patch (https://github.com/erlang/otp/pull/121) cover > the following areas: > > 1. Extension of the EPMD distributed protocol (here we can safely add new > set of commands while being fully backward compatible) > erts/doc/src/erl_dist_protocol.xml > > 2. Modification of the EPMD daemon to support the new protocol version and > to keep track of the multiple protocols/ports per node (this is also done > in a backward compatible way. Nodes supporting new protocol version > communicate using new spec, and old nodes communicate using old spec) > erts/epmd/src/epmd.h > erts/epmd/src/epmd.c > > 3. Modification of the EPMD command-line tool to talk to the local EPMD > daemon using the new protocol version (the command-line tool uses new > protocol version. This is reasonable, since it's installed together with > the version of VM supporting the new EPMD protocol features) > erts/epmd/src/epmd_cli.c > erts/epmd/src/epmd_cli.c > erts/epmd/src/epmd_int.h > erts/epmd/src/epmd_srv.c > > 4. Updates of the UDS distribution example code. I believe the example in > the current release is outdated (I was unable to compile it), but I > patched it anyway to illustrate the usage of the new protocol) > lib/kernel/examples/uds_dist/src/dist_selector.erl > lib/kernel/examples/uds_dist/src/uds_dist.erl > lib/kernel/examples/uds_dist/src/uds_server.erl > > 5. Change of the net_kernel transport pluggable architecture to allow > support of the new EPMD protocol. > 5.1 Net_kernel support for the new protocol. > 5.2 TCPv4 support of the new protocol > 5.3 TCPv6 support of the new protocol > 5.4 TLS support of the new protocol > lib/kernel/src/net_kernel.erl > lib/kernel/src/dist_util.erl > lib/kernel/src/inet6_tcp_dist.erl > lib/kernel/src/inet_tcp_dist.erl > lib/kernel/src/net_kernel.erl > lib/ssl/src/inet_tls_dist.erl > lib/ssl/src/ssl_tls_dist_proxy.erl > lib/kernel/doc/src/net_kernel.xml > > It seems to me that we could roll it out in two phases: > > 1. Implement 1,2,3 in the first phase. This would allow to deploy a > version with EPMD supporting old and new protocols. > 2. Implement changes to net_kernel and transports (4,5) to be able to talk > to new EPMDs > > If agreed, I can break up my patch in two, corresponding to this plan. > > What do you think? > I think it is a good idea to roll out this in 2 or more phases but I think we need think a bit more about this before we can give a more feedback on exactly what to include in the different phases. Will be back with more comments/suggestions soon. Regards Kenneth > > Serge > > > > On Thu, Jan 9, 2014 at 10:53 AM, Kenneth Lundin wrote: > >> On Fri, Jan 3, 2014 at 4:30 PM, Serge Aleynikov wrote: >> >>> I'd like to inquire the status of the following pull request: >>> https://github.com/erlang/otp/pull/121 >>> >>> Has it been reviewed? >>> >>> Thanks! >>> >>> Serge >>> >>> Hi Serge, >> >> We have discussed your contribution at the OTP technical board and here >> are the results: >> >> Inclusion in OTP >> ----------------------- >> >> Your patch touches many source files which are central for the Erlang >> distribution and we feel it would require quite a lot of work from our side >> as well to assure that nothing in the current distribution gets broken or >> incompatible. It would also require quite deep involvement from us giving >> more detailed feedback regarding interfaces, semantics etc. We can not >> prioritize this at the moment so we will not include your contribution now >> (which means REJECT for now). >> >> But we really want to add this kind of functionality and want to >> encourage you (and others) to continue the good work in this area for >> possible inclusion in OTP at a later stage. See more info and thoughts >> below. >> >> >> General thoughts >> ----------------------- >> >> Enhancing/extending the Erlang distribution to support heterogenous >> communication protocols is something we have discussed many times and it is >> something that we really would like to have. >> >> 1) We would like a plugin architecture where different transport >> protocols can be easily plugged in without having to change the basic >> Erlang distribution or the VM. >> >> 2) It should be possible to run different protocols towards different >> nodes >> >> 3) should be possible to have different timeouts (NET_TICK_TIME) per >> connection >> >> 4) interesting protocols would be UDS, TCP, TLS over TCP, SCTP, ... >> >> 5) it should be possible to look up nodes in different ways and maybe not >> only via contacting epmd on the host name which is part of the node name. >> I.e having the hostname as part of the node name is not always what you >> want, depending on protocol to use. >> >> .... >> >> Your specific contribution >> ----------------------------------- >> In your pull request you have implemented fully or partly 1,2, 4, and we >> see it as a good start. >> >> A general comment is that the diffs are showing differences on many >> places in the code where you actually haven't changed anything except tabs, >> line breaks and spaces. This makes it more difficult to sort out what you >> have changed and added. We would like a clean diff without unnecessary >> touches lines which has no relevance for the new function. If a formatting >> change is needed or suggested it should be a separate commit/pull request. >> >> Regarding details in your code we have not had the time to take a deeper >> look but from a quick glance it looks good. The questionmarks are more >> about how to introduce this new functionality in a safe way and what more >> is needed that you have not addressed so far. >> >> >> Suggested way forward >> ------------------------------ >> >> I think that one approach that would make it easier to include this kind >> of functionality soon would be to make minimal changes to the existing >> distribution code and only add or change so that it is possible to support >> heterogenous protocols with code that initially can live as a separate >> extension that don't need to be part of the OTP distro. >> In this way the functionality can be further developed and used together >> with an ordinary OTP distro (unpatched) and can easily be included later >> (hopefully within a year). >> >> Maybe you think that you already have done those minimal changes, but I >> suggest you take another look and see if it is possible to find a way to >> make minimal or now changes to net_kernel and epmd etc. which we could >> include and then have the rest as a separate "application"/extension >> project at github that can be included later. >> >> Just some thoughts: >> Maybe let the old distribution work as before and let the user choose >> "new_distro" in some way and will only then get to run the new code which >> allows heterogenous protocols another new EPMD or an EPMD written in Erlang >> or allow for plugins of different EPMD implementations that can run in >> parallell. The communication towards EPMD maybe needs to be secure as well >> and then it might be much easier to implement in Erlang. >> >> I (we) are more than willing to discuss more about how to find this >> minimal patch which we think we can "safely" include and which makes it >> possible to develop and use the rest as pure extensions to OTP in a first >> step. >> >> Regards Kenneth, Erlang/OTP Ericsson >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom@REDACTED Wed Jan 15 14:05:42 2014 From: tom@REDACTED (Tom Wright) Date: Wed, 15 Jan 2014 04:05:42 -0900 Subject: [erlang-patches] supervisor has wrong type annotation for sup_name Message-ID: Error checking mail for tatwrightgambit@REDACTED Details Dismiss [image: Available]Aaron Sokoloski[image: Idle (video enabled)]Adam Kelly I'm not here right now[image: Idle]ben1[image: Idle (video enabled)]Daniele Varrazzo[image: Idle]Gustavo Carneiro[image: Idle]John Aldis[image: Idle] Tethys[image: Idle]Tomer Chachamu[image: Offline]David Lankester[image: Offline]Joseph Buckley == Symptom == Dialyzer complains whenever you use 'via' with a supervisor despite it being supported (both in practice and according to the docs). http://www.erlang.org/doc/man/supervisor.html: If SupName={via,Module,Name}the supervisor is registered as Name using the registry represented by Module This is still a problem as of release 25237481ccccd3ddfa74582dc267632ad618ba30 at https://github.com/erlang/otp.git === Patch === Replace: -type sup_name() :: {'local', Name :: atom()} | {'global', Name :: atom()}. with -type sup_name() :: {'local', Name :: atom()} | {'global', Name :: atom()} | {'via', Module :: atom(), Name :: any() }. or similar. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Wed Jan 15 19:57:37 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 15 Jan 2014 13:57:37 -0500 Subject: [erlang-patches] remove deprecated driver_async_cancel function Message-ID: The driver_async_cancel function has been deprecated for some time, with the current documentation indicating that it's slated for removal in R17. This patch removes the function and associated tests and docs, increments the driver interface version to 3.0, and fixes the driver test suite to handle 3.0 properly where needed. https://github.com/erlang/otp/pull/194 --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From rzezeski@REDACTED Wed Jan 15 23:32:38 2014 From: rzezeski@REDACTED (Ryan Zezeski) Date: Wed, 15 Jan 2014 17:32:38 -0500 Subject: [erlang-patches] Fix DTrace build on Illumos In-Reply-To: <52A71690.7000808@erlang.org> References: <52A71690.7000808@erlang.org> Message-ID: Any news? Would be nice if R17 worked with DTrace on latest Illumos kernel. On Tue, Dec 10, 2013 at 8:26 AM, Henrik Nord wrote: > Thank you for your contribution ! > > patch has been assigned to be reviewed > > > > On 2013-12-07 22:00, Ryan Zezeski wrote: > > https://github.com/erlang/otp/pull/156 > > This patch fixes the configure and Makefile scripts to work with newer > DTrace. This applies to all Illumos derivatives including OpenIndiana, > SmartOS and OmnioOS. I've copied the commit message here verbatim. > > --- SNIP --- > > Fix DTrace build on Illumos > > DTrace was recently patched in Illumos to fail to create an object > file if no probes are found. > > * https://www.illumos.org/issues/4248 > * > https://github.com/illumos/illumos-gate/commit/54a20ab41aadcb81c53e72fc65886e964e9add59 > > This patch fixes two issues: > > * Modify the configure script to pass an object file to `dtrace -G` > that actually invokes a probe. > > * Remove creation of `dtrace_user.o` from the dyntrace Makefile. In a > previous commit [1] Scott Fritchie relocated all the user probes > into the VM proper due to difficulties with DTrace probes in shared > libraries. The `dtrace_user.d` file is now empty and generates a > header file with nothing in it. There is no longer any reason to > generate `dtrace_user.o` because all the probes are in the VM. Thus > all the steps for building `dtrace_user.o` have been removed. > > [1]: > https://github.com/erlang/otp/commit/75552bd3bb4e7f3cf4dab81a5c81cf73b1d3fb99 > > --- END SNIP --- > > -Z > > > _______________________________________________ > erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches > > > -- > /Henrik Nord Erlang/OTP > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Thu Jan 16 05:52:45 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 15 Jan 2014 23:52:45 -0500 Subject: [erlang-patches] fix system_flag warning message Message-ID: Passing certain arguments to erlang:system_flag/2 results in an error report containing a deprecation warning saying the arguments will be removed in R16. Since that release is already out, keep the warning message but change the target removal release to Erlang 18. https://github.com/erlang/otp/pull/195 I already ran this by Rickard, and he suggested 18 as the target version. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Thu Jan 16 11:25:17 2014 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 16 Jan 2014 11:25:17 +0100 Subject: [erlang-patches] Fix DTrace build on Illumos In-Reply-To: References: <52A71690.7000808@erlang.org> Message-ID: <52D7B38D.2090707@erlang.org> Hello, We are working on a way to verify this on our test machines. We intend to have this fix merged before the upcoming release. Lukas On 15/01/14 23:32, Ryan Zezeski wrote: > Any news? Would be nice if R17 worked with DTrace on latest Illumos > kernel. > > > On Tue, Dec 10, 2013 at 8:26 AM, Henrik Nord > wrote: > > Thank you for your contribution ! > > patch has been assigned to be reviewed > > > > On 2013-12-07 22:00, Ryan Zezeski wrote: >> https://github.com/erlang/otp/pull/156 >> >> This patch fixes the configure and Makefile scripts to work with >> newer DTrace. This applies to all Illumos derivatives including >> OpenIndiana, SmartOS and OmnioOS. I've copied the commit message >> here verbatim. >> >> --- SNIP --- >> >> Fix DTrace build on Illumos >> >> DTrace was recently patched in Illumos to fail to create an >> object >> file if no probes are found. >> >> * https://www.illumos.org/issues/4248 >> * >> https://github.com/illumos/illumos-gate/commit/54a20ab41aadcb81c53e72fc65886e964e9add59 >> >> This patch fixes two issues: >> >> * Modify the configure script to pass an object file to >> `dtrace -G` >> that actually invokes a probe. >> >> * Remove creation of `dtrace_user.o` from the dyntrace >> Makefile. In a >> previous commit [1] Scott Fritchie relocated all the user >> probes >> into the VM proper due to difficulties with DTrace probes >> in shared >> libraries. The `dtrace_user.d` file is now empty and >> generates a >> header file with nothing in it. There is no longer any >> reason to >> generate `dtrace_user.o` because all the probes are in the >> VM. Thus >> all the steps for building `dtrace_user.o` have been removed. >> >> [1]: >> https://github.com/erlang/otp/commit/75552bd3bb4e7f3cf4dab81a5c81cf73b1d3fb99 >> >> --- END SNIP --- >> >> -Z >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > -- > /Henrik Nord Erlang/OTP > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Jan 16 11:26:02 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 16 Jan 2014 11:26:02 +0100 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <519BD27D.8040605@gmail.com> References: <517947E4.2040504@gmail.com> <517E2012.9030009@erlang.org> <51820EFB.4060109@gmail.com> <518269DD.701@gmail.com> <5195E04A.9020408@erlang.org> <519BD27D.8040605@gmail.com> Message-ID: Hi Hans! After many and long discussions we have now decided to re-open this patch and approve it with some comments: 1. we would like the name of the function to be 'droplast'. 2. we want the simple recursive implementation with no special handling of bad arguments, i.e. we think it is ok with a function_clause error for arguments that are not non-empty proper lists. Would you mind doing these adjustments in the patch? Best Regards /siri 2013/5/21 Hans Svensson > Hello Hans, >> I've got some feedback on your patch after review: >> We have decided to reject this patch as we don't see a general need for >> the new function. >> >> Thanks for showing interest in contributing! >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> > That is sad news, and we find it a bit strange since *you* (as in the OTP > team) yourself seems use this particular function/pattern quite frequently. > We did a quick search through the OTP code base and found quite a few > places where this particular function is either implemented recursively and > used, or just uses reverse(tl(reverse(List)))). Also interesting to see is > the different names used: first, butlast, but_last and remove_last_element. > > Code implementing the "init"-function: > compiler > v3_core:first/1 > v3_kernel:first/1 > dialyzer > dialyzer_contracts:but_last/1 > dialyzer_gui:butlast/1 > hipe > hipe_icode_type:butlast/1 > orber > orber_interceptors:remove_last_element/1 > > Direct uses of reverse(tl(reverse(L))): > sasl > in systools_make:smart_guess/3 > wx_gen > in wx_gen:erl_skip_opt2/4 > ssh > in ssh_sftpd > > Any further comments on this, it is really not a "new" function it is a > missing function ;-) > > Cheers, > > Hans > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Thu Jan 16 14:54:55 2014 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 16 Jan 2014 14:54:55 +0100 (CET) Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: References: <517947E4.2040504@gmail.com> <51820EFB.4060109@gmail.com> <518269DD.701@gmail.com> <5195E04A.9020408@erlang.org> <519BD27D.8040605@gmail.com> Message-ID: <687872115.458344.1389880495470.JavaMail.zimbra@erlang-solutions.com> Shouldn't be called liat/1 instead? Just joking. Robert ----- Original Message ----- > From: "Siri Hansen" > To: "Hans Svensson" > Cc: "erlang-patches" > Sent: Thursday, 16 January, 2014 11:26:02 AM > Subject: Re: [erlang-patches] Add lists:init/1 - got tired of implementing it > Hi Hans! > After many and long discussions we have now decided to re-open this patch and > approve it with some comments: > 1. we would like the name of the function to be 'droplast'. > 2. we want the simple recursive implementation with no special handling of > bad arguments, i.e. we think it is ok with a function_clause error for > arguments that are not non-empty proper lists. > Would you mind doing these adjustments in the patch? > Best Regards > /siri > 2013/5/21 Hans Svensson < hanssv@REDACTED > > > > Hello Hans, > > > > > > I've got some feedback on your patch after review: > > > > > > We have decided to reject this patch as we don't see a general need for > > > > > > the new function. > > > > > > Thanks for showing interest in contributing! > > > > > > -- > > > > > > BR Fredrik Gustafsson > > > > > > Erlang OTP Team > > > > > That is sad news, and we find it a bit strange since *you* (as in the OTP > > team) yourself seems use this particular function/pattern quite frequently. > > We did a quick search through the OTP code base and found quite a few > > places > > where this particular function is either implemented recursively and used, > > or just uses reverse(tl(reverse(List)))). Also interesting to see is the > > different names used: first, butlast, but_last and remove_last_element. > > > Code implementing the "init"-function: > > > compiler > > > v3_core:first/1 > > > v3_kernel:first/1 > > > dialyzer > > > dialyzer_contracts:but_last/1 > > > dialyzer_gui:butlast/1 > > > hipe > > > hipe_icode_type:butlast/1 > > > orber > > > orber_interceptors:remove_ last_element/1 > > > Direct uses of reverse(tl(reverse(L))): > > > sasl > > > in systools_make:smart_guess/3 > > > wx_gen > > > in wx_gen:erl_skip_opt2/4 > > > ssh > > > in ssh_sftpd > > > Any further comments on this, it is really not a "new" function it is a > > missing function ;-) > > > Cheers, > > > Hans > > > ______________________________ _________________ > > > 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 vinoski@REDACTED Thu Jan 16 17:16:48 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 16 Jan 2014 11:16:48 -0500 Subject: [erlang-patches] emacs skeleton indentation patch Message-ID: Leo Liu and I both noticed that Emacs Erlang skeletons currently are not fully indented properly when they're inserted. This patch, written by Leo, fixes the indentation problems: https://github.com/erlang/otp/pull/197 --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Thu Jan 16 19:15:46 2014 From: sean@REDACTED (Sean Cribbs) Date: Thu, 16 Jan 2014 12:15:46 -0600 Subject: [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer Message-ID: Hi Erlangers, Ages ago, OTP shipped with a pre-built PLT for dialyzer, which was removed reasons forgotten by most of us (probably the time/cost of building it). Nowadays, because dialyzer is much improved (parallelism!) and our computers are faster and have more cores, a PLT for all of the standard library might only take a few minutes to build. We've been increasing our usage of dialyzer at Basho and I have felt that it seems extremely wasteful and unnecessary to build a partial PLT of the standard library for every single project, when that information only changes across OTP releases. I feel the Erlang/OTP build process should include building a PLT that encompasses the entire standard library. Aside from the reduced cost of building PLTs for every different app, this may encourage others to start using dialyzer on their projects. I'm offering to do the work to make this happen, but I need a little guidance on where to start. I've looked at the dialyzer Makefile from an older release where the PLT was included, but I'm concerned the project structure has changed enough that the rules there no longer apply. It seems the dialyzer runtime itself might also need to be tweaked to automatically include the prebuilt PLT. Looking forward to hearing your thoughts and direction. Cheers! -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hm@REDACTED Thu Jan 16 23:03:22 2014 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Thu, 16 Jan 2014 23:03:22 +0100 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <687872115.458344.1389880495470.JavaMail.zimbra@erlang-solutions.com> References: <517947E4.2040504@gmail.com> <51820EFB.4060109@gmail.com> <518269DD.701@gmail.com> <5195E04A.9020408@erlang.org> <519BD27D.8040605@gmail.com> <687872115.458344.1389880495470.JavaMail.zimbra@erlang-solutions.com> Message-ID: Or chop/1 to be compatible with Perl. ;-) /H?kan On Thu, Jan 16, 2014 at 2:54 PM, Robert Virding wrote: > Shouldn't be called liat/1 instead? Just joking. > > Robert > > ________________________________ > > From: "Siri Hansen" > To: "Hans Svensson" > Cc: "erlang-patches" > Sent: Thursday, 16 January, 2014 11:26:02 AM > Subject: Re: [erlang-patches] Add lists:init/1 - got tired of implementing > it > > > Hi Hans! > > After many and long discussions we have now decided to re-open this patch > and approve it with some comments: > > 1. we would like the name of the function to be 'droplast'. > 2. we want the simple recursive implementation with no special handling of > bad arguments, i.e. we think it is ok with a function_clause error for > arguments that are not non-empty proper lists. > > Would you mind doing these adjustments in the patch? > > Best Regards > /siri > > > 2013/5/21 Hans Svensson >>> >>> Hello Hans, >>> I've got some feedback on your patch after review: >>> We have decided to reject this patch as we don't see a general need for >>> the new function. >>> >>> Thanks for showing interest in contributing! >>> >>> -- >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >> >> That is sad news, and we find it a bit strange since *you* (as in the OTP >> team) yourself seems use this particular function/pattern quite frequently. >> We did a quick search through the OTP code base and found quite a few places >> where this particular function is either implemented recursively and used, >> or just uses reverse(tl(reverse(List)))). Also interesting to see is the >> different names used: first, butlast, but_last and remove_last_element. >> >> Code implementing the "init"-function: >> compiler >> v3_core:first/1 >> v3_kernel:first/1 >> dialyzer >> dialyzer_contracts:but_last/1 >> dialyzer_gui:butlast/1 >> hipe >> hipe_icode_type:butlast/1 >> orber >> orber_interceptors:remove_last_element/1 >> >> Direct uses of reverse(tl(reverse(L))): >> sasl >> in systools_make:smart_guess/3 >> wx_gen >> in wx_gen:erl_skip_opt2/4 >> ssh >> in ssh_sftpd >> >> Any further comments on this, it is really not a "new" function it is a >> missing function ;-) >> >> Cheers, >> >> Hans >> >> _______________________________________________ >> 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 > From henrik@REDACTED Fri Jan 17 09:52:26 2014 From: henrik@REDACTED (Henrik Nord) Date: Fri, 17 Jan 2014 09:52:26 +0100 Subject: [erlang-patches] emacs skeleton indentation patch In-Reply-To: References: Message-ID: <52D8EF4A.6040005@erlang.org> Thanks Patch assigned and under review On 2014-01-16 17:16, Steve Vinoski wrote: > Leo Liu and I both noticed that Emacs Erlang skeletons currently are > not fully indented properly when they're inserted. This patch, written > by Leo, fixes the indentation problems: > > https://github.com/erlang/otp/pull/197 > > --steve > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Fri Jan 17 09:59:52 2014 From: henrik@REDACTED (Henrik Nord) Date: Fri, 17 Jan 2014 09:59:52 +0100 Subject: [erlang-patches] remove deprecated driver_async_cancel function In-Reply-To: References: Message-ID: <52D8F108.50509@erlang.org> Thanks! Patch under review. On 2014-01-15 19:57, Steve Vinoski wrote: > The driver_async_cancel function has been deprecated for some time, > with the current documentation indicating that it's slated for removal > in R17. This patch removes the function and associated tests and docs, > increments the driver interface version to 3.0, and fixes the driver > test suite to handle 3.0 properly where needed. > > https://github.com/erlang/otp/pull/194 > > --steve > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Fri Jan 17 10:00:45 2014 From: henrik@REDACTED (Henrik Nord) Date: Fri, 17 Jan 2014 10:00:45 +0100 Subject: [erlang-patches] fix system_flag warning message In-Reply-To: References: Message-ID: <52D8F13D.1040004@erlang.org> Thanks! Patch under review On 2014-01-16 05:52, Steve Vinoski wrote: > Passing certain arguments to erlang:system_flag/2 results in an error > report containing a deprecation warning saying the arguments will be > removed in R16. Since that release is already out, keep the warning > message but change the target removal release to Erlang 18. > > https://github.com/erlang/otp/pull/195 > > I already ran this by Rickard, and he suggested 18 as the target version. > > --steve > > > _______________________________________________ > 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 raimo+erlang-patches@REDACTED Fri Jan 17 10:44:18 2014 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Fri, 17 Jan 2014 10:44:18 +0100 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <687872115.458344.1389880495470.JavaMail.zimbra@erlang-solutions.com> References: <517947E4.2040504@gmail.com> <51820EFB.4060109@gmail.com> <518269DD.701@gmail.com> <5195E04A.9020408@erlang.org> <519BD27D.8040605@gmail.com> <687872115.458344.1389880495470.JavaMail.zimbra@erlang-solutions.com> Message-ID: <20140117094418.GA4342@erix.ericsson.se> On Thu, Jan 16, 2014 at 02:54:55PM +0100, Robert Virding wrote: > Shouldn't be called liat/1 instead? Just joking. Hey! That was my idea! / Raimo > > Robert > > ----- Original Message ----- > > > From: "Siri Hansen" > > To: "Hans Svensson" > > Cc: "erlang-patches" > > Sent: Thursday, 16 January, 2014 11:26:02 AM > > Subject: Re: [erlang-patches] Add lists:init/1 - got tired of implementing it > > > Hi Hans! > > > After many and long discussions we have now decided to re-open this patch and > > approve it with some comments: > > > 1. we would like the name of the function to be 'droplast'. > > 2. we want the simple recursive implementation with no special handling of > > bad arguments, i.e. we think it is ok with a function_clause error for > > arguments that are not non-empty proper lists. > > > Would you mind doing these adjustments in the patch? > > > Best Regards > > /siri > > > 2013/5/21 Hans Svensson < hanssv@REDACTED > > > > > > Hello Hans, > > > > > > > > > I've got some feedback on your patch after review: > > > > > > > > > We have decided to reject this patch as we don't see a general need for > > > > > > > > > the new function. > > > > > > > > > > Thanks for showing interest in contributing! > > > > > > > > > > -- > > > > > > > > > > BR Fredrik Gustafsson > > > > > > > > > Erlang OTP Team > > > > > > > > > That is sad news, and we find it a bit strange since *you* (as in the OTP > > > team) yourself seems use this particular function/pattern quite frequently. > > > We did a quick search through the OTP code base and found quite a few > > > places > > > where this particular function is either implemented recursively and used, > > > or just uses reverse(tl(reverse(List)))). Also interesting to see is the > > > different names used: first, butlast, but_last and remove_last_element. > > > > > > Code implementing the "init"-function: > > > > > compiler > > > > > v3_core:first/1 > > > > > v3_kernel:first/1 > > > > > dialyzer > > > > > dialyzer_contracts:but_last/1 > > > > > dialyzer_gui:butlast/1 > > > > > hipe > > > > > hipe_icode_type:butlast/1 > > > > > orber > > > > > orber_interceptors:remove_ last_element/1 > > > > > > Direct uses of reverse(tl(reverse(L))): > > > > > sasl > > > > > in systools_make:smart_guess/3 > > > > > wx_gen > > > > > in wx_gen:erl_skip_opt2/4 > > > > > ssh > > > > > in ssh_sftpd > > > > > > Any further comments on this, it is really not a "new" function it is a > > > missing function ;-) > > > > > > Cheers, > > > > > > Hans > > > > > > ______________________________ _________________ > > > > > 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 -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From roger@REDACTED Fri Jan 17 15:30:35 2014 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 17 Jan 2014 14:30:35 +0000 Subject: [erlang-patches] Make SSL max plaintext size configurable Message-ID: We've discovered that the SSL/TLS application in Erlang assumes a max plaintext size of 2^14 (16384) bytes. We're communicating with an embedded device that, due to constrained resources, can't handle plaintext fragments larger than ~2Kb. In OpenSSL, the maximum plaintext fragment size can be configured by using the (barely documented) SSL_CTRL_SET_MAX_SEND_FRAGMENT control. We're converting our back-end server to Erlang, and we'd like to be able to do the same from Erlang. I asked about this here: http://stackoverflow.com/q/19276598/8446, where it was also suggested that we look at implementing the relevant section of RFC 6066, which defines a mechanism for negotiating this parameter. We've discarded that option because (a) RFC 6066 only allows for a limited set of values for this parameter; and (b) our embedded device currently only supports TLS 1.1, and RFC 6066 is an extension to TLS 1.2. I have a patch that implements this functionality, from the server side, at least: https://github.com/rlipscombe/otp/tree/rl-ssl-fragment-size To use this feature, simply specify {max_plain_text_length, N} in the Options passed to ssl:listen/2, as follows: {ok, LSock} = ssl:listen(17120, [{max_plain_text_length, 2000}, {certfile, "server.crt"}, {keyfile, "server.key"}]). If you don't specify the option, it defaults to 2^14. I've tested this with Wireshark, and can clearly see that the SSL message is broken into roughly 2Kb-sized fragments (allowing for some overhead). I'd like to: (a) get some comments on how it can be improved. (b) see if I can shepherd this patch upstream into a future release of Erlang/OTP. Things I am aware of: - Too many magic numbers. I attempted to put these values in ssl_record.hrl, but then discovered that not everything that needed the magic number included this file. In particular, I ended up needing it in ssl_internal.hrl. I'd appreciate suggestions for where the definitions of the magic numbers and types ought to go. - No documentation. I'm happy to add to the relevant docs as appropriate. I'd appreciate advice on how to proceed from here. Thanks, Roger. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Jan 17 22:16:22 2014 From: erlang@REDACTED (Andreas Stenius) Date: Fri, 17 Jan 2014 22:16:22 +0100 Subject: [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer In-Reply-To: References: Message-ID: +1. 2014/1/16 Sean Cribbs > Hi Erlangers, > > Ages ago, OTP shipped with a pre-built PLT for dialyzer, which was removed > reasons forgotten by most of us (probably the time/cost of building it). > Nowadays, because dialyzer is much improved (parallelism!) and our > computers are faster and have more cores, a PLT for all of the standard > library might only take a few minutes to build. > > We've been increasing our usage of dialyzer at Basho and I have felt that > it seems extremely wasteful and unnecessary to build a partial PLT of the > standard library for every single project, when that information only > changes across OTP releases. I feel the Erlang/OTP build process should > include building a PLT that encompasses the entire standard library. Aside > from the reduced cost of building PLTs for every different app, this may > encourage others to start using dialyzer on their projects. > > I'm offering to do the work to make this happen, but I need a little > guidance on where to start. I've looked at the dialyzer Makefile from an > older release where the PLT was included, but I'm concerned the project > structure has changed enough that the rules there no longer apply. It seems > the dialyzer runtime itself might also need to be tweaked to automatically > include the prebuilt PLT. > > Looking forward to hearing your thoughts and direction. Cheers! > > -- > 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 sean@REDACTED Sat Jan 18 18:31:39 2014 From: sean@REDACTED (Sean Cribbs) Date: Sat, 18 Jan 2014 11:31:39 -0600 Subject: [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer In-Reply-To: <52DAA3C8.4050903@gmail.com> References: <52DAA3C8.4050903@gmail.com> Message-ID: Sure, but my point is that there _is no global PLT_. OTP should have one shipped in its standard library. On Sat, Jan 18, 2014 at 9:54 AM, Ignas Vy?niauskas wrote: > On 01/16/2014 07:15 PM, Sean Cribbs wrote: > > We've been increasing our usage of dialyzer at Basho and I have felt > > that it seems extremely wasteful and unnecessary to build a partial > > PLT of the standard library for every single project, when that > > information only changes across OTP releases. > > +1 also, but doesn't the `--add_to_plt` flag resolve the problem you > describe of having to build the PLT for every single project? > > You build once the "global" / OTP plt, and then just append the needed > things from specific projects from that to obtain new PLTs. > > -- > Ignas > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From baliulia@REDACTED Sat Jan 18 16:54:48 2014 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Sat, 18 Jan 2014 16:54:48 +0100 Subject: [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer In-Reply-To: References: Message-ID: <52DAA3C8.4050903@gmail.com> On 01/16/2014 07:15 PM, Sean Cribbs wrote: > We've been increasing our usage of dialyzer at Basho and I have felt > that it seems extremely wasteful and unnecessary to build a partial > PLT of the standard library for every single project, when that > information only changes across OTP releases. +1 also, but doesn't the `--add_to_plt` flag resolve the problem you describe of having to build the PLT for every single project? You build once the "global" / OTP plt, and then just append the needed things from specific projects from that to obtain new PLTs. -- Ignas From hanssv@REDACTED Sun Jan 19 19:15:52 2014 From: hanssv@REDACTED (Hans Svensson) Date: Sun, 19 Jan 2014 19:15:52 +0100 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: References: <517947E4.2040504@gmail.com> <517E2012.9030009@erlang.org> <51820EFB.4060109@gmail.com> <518269DD.701@gmail.com> <5195E04A.9020408@erlang.org> <519BD27D.8040605@gmail.com> Message-ID: <52DC1658.8020104@gmail.com> Great! I'll fix that! I happened to re-implement this function again the other day, and thought about how sad it was that the function wasn't there ;-) Would you like me to actually use the function (in the places mentioned below) as well, our would you prefer that to be a separate patch? /Hans On 2014-01-16 11:26, Siri Hansen wrote: > Hi Hans! > > After many and long discussions we have now decided to re-open this > patch and approve it with some comments: > > 1. we would like the name of the function to be 'droplast'. > 2. we want the simple recursive implementation with no special handling > of bad arguments, i.e. we think it is ok with a function_clause error > for arguments that are not non-empty proper lists. > > Would you mind doing these adjustments in the patch? > > Best Regards > /siri > > > 2013/5/21 Hans Svensson > > > Hello Hans, > I've got some feedback on your patch after review: > We have decided to reject this patch as we don't see a general > need for > the new function. > > Thanks for showing interest in contributing! > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > > That is sad news, and we find it a bit strange since *you* (as in > the OTP team) yourself seems use this particular function/pattern > quite frequently. We did a quick search through the OTP code base > and found quite a few places where this particular function is > either implemented recursively and used, or just uses > reverse(tl(reverse(List)))). Also interesting to see is the > different names used: first, butlast, but_last and remove_last_element. > > Code implementing the "init"-function: > compiler > v3_core:first/1 > v3_kernel:first/1 > dialyzer > dialyzer_contracts:but_last/1 > dialyzer_gui:butlast/1 > hipe > hipe_icode_type:butlast/1 > orber > orber_interceptors:remove___last_element/1 > > Direct uses of reverse(tl(reverse(L))): > sasl > in systools_make:smart_guess/3 > wx_gen > in wx_gen:erl_skip_opt2/4 > ssh > in ssh_sftpd > > Any further comments on this, it is really not a "new" function it > is a missing function ;-) > > Cheers, > > Hans > > _________________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/__listinfo/erlang-patches > > > From dangud@REDACTED Sun Jan 19 20:25:33 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Sun, 19 Jan 2014 20:25:33 +0100 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <52DC1658.8020104@gmail.com> References: <517947E4.2040504@gmail.com> <517E2012.9030009@erlang.org> <51820EFB.4060109@gmail.com> <518269DD.701@gmail.com> <5195E04A.9020408@erlang.org> <519BD27D.8040605@gmail.com> <52DC1658.8020104@gmail.com> Message-ID: Separate patch with separate commits one for each application, please. On Sun, Jan 19, 2014 at 7:15 PM, Hans Svensson wrote: > Great! I'll fix that! I happened to re-implement this function again the > other day, and thought about how sad it was that the function wasn't there > ;-) > > Would you like me to actually use the function (in the places mentioned > below) as well, our would you prefer that to be a separate patch? > > /Hans > > > On 2014-01-16 11:26, Siri Hansen wrote: > >> Hi Hans! >> >> After many and long discussions we have now decided to re-open this >> patch and approve it with some comments: >> >> 1. we would like the name of the function to be 'droplast'. >> 2. we want the simple recursive implementation with no special handling >> of bad arguments, i.e. we think it is ok with a function_clause error >> for arguments that are not non-empty proper lists. >> >> Would you mind doing these adjustments in the patch? >> >> Best Regards >> /siri >> >> >> 2013/5/21 Hans Svensson > >> >> >> Hello Hans, >> I've got some feedback on your patch after review: >> We have decided to reject this patch as we don't see a general >> need for >> the new function. >> >> Thanks for showing interest in contributing! >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> >> That is sad news, and we find it a bit strange since *you* (as in >> the OTP team) yourself seems use this particular function/pattern >> quite frequently. We did a quick search through the OTP code base >> and found quite a few places where this particular function is >> either implemented recursively and used, or just uses >> reverse(tl(reverse(List)))). Also interesting to see is the >> different names used: first, butlast, but_last and >> remove_last_element. >> >> Code implementing the "init"-function: >> compiler >> v3_core:first/1 >> v3_kernel:first/1 >> dialyzer >> dialyzer_contracts:but_last/1 >> dialyzer_gui:butlast/1 >> hipe >> hipe_icode_type:butlast/1 >> orber >> orber_interceptors:remove___last_element/1 >> >> >> Direct uses of reverse(tl(reverse(L))): >> sasl >> in systools_make:smart_guess/3 >> wx_gen >> in wx_gen:erl_skip_opt2/4 >> ssh >> in ssh_sftpd >> >> Any further comments on this, it is really not a "new" function it >> is a missing function ;-) >> >> Cheers, >> >> Hans >> >> _________________________________________________ >> 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 andrew@REDACTED Tue Jan 21 23:26:52 2014 From: andrew@REDACTED (Andrew Thompson) Date: Tue, 21 Jan 2014 17:26:52 -0500 Subject: [erlang-patches] Various improvements to CRL handling In-Reply-To: <20131010063754.GW9818@hijacked.us> References: <20131010063754.GW9818@hijacked.us> Message-ID: <20140121222652.GD30461@hijacked.us> On Thu, Oct 10, 2013 at 02:37:54AM -0400, Andrew Thompson wrote: > https://github.com/erlang/otp/pull/97 I have updated this PR with some more comments, and updated the supporting tool I used to test it. I'm now able to validate the CRL chain for every HTTPS site I could think of to test, including twitter and myspace (which I could previously not get to validate, I think because they use 'teletextstrings', which I've never even heard of). I think this PR really moves the state of CRL handling in Erlang solidly into the real of 'possible', and as Basho will be shipping this patch with Riak 2.0. I'd *really* like to see it land in R17. Thanks, Andrew From andrew@REDACTED Tue Jan 21 23:28:15 2014 From: andrew@REDACTED (Andrew Thompson) Date: Tue, 21 Jan 2014 17:28:15 -0500 Subject: [erlang-patches] Implement 'honor_cipher_order' SSL server-side option In-Reply-To: <20131022033217.GH9818@hijacked.us> References: <20131022033217.GH9818@hijacked.us> Message-ID: <20140121222815.GE30461@hijacked.us> On Mon, Oct 21, 2013 at 11:32:17PM -0400, Andrew Thompson wrote: > https://github.com/erlang/otp/pull/111 I've integrated Andreas' refactor and test suite and rebased this off of master (Steve Vinoski told me to) and would like to see this in R17. The new PR is at: https://github.com/erlang/otp/pull/201 Andrew From roger@REDACTED Wed Jan 22 10:41:54 2014 From: roger@REDACTED (Roger Lipscombe) Date: Wed, 22 Jan 2014 09:41:54 +0000 Subject: [erlang-patches] Make SSL max plaintext size configurable In-Reply-To: References: Message-ID: On 17 January 2014 14:30, Roger Lipscombe wrote: > [snip] > > I'd like to: > > (a) get some comments on how it can be improved. > (b) see if I can shepherd this patch upstream into a future release of > Erlang/OTP. > > I'd appreciate advice on how to proceed from here. Please consider this a gentle prod. I really don't want to maintain my own fork of OTP, so I'd like to learn what I'm missing in terms of getting this patch reviewed and accepted into upstream... Thanks, Roger. From hanssv@REDACTED Wed Jan 22 23:14:23 2014 From: hanssv@REDACTED (Hans Svensson) Date: Wed, 22 Jan 2014 23:14:23 +0100 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: References: <517947E4.2040504@gmail.com> <517E2012.9030009@erlang.org> <51820EFB.4060109@gmail.com> <518269DD.701@gmail.com> <5195E04A.9020408@erlang.org> <519BD27D.8040605@gmail.com> Message-ID: <52E042BF.4020800@gmail.com> Finally got around to do the fixes. Screwed up my git branch, so the lists:droplast/1 is now in a differently named branch: git fetch git://github.com/hanssv/otp.git add_droplast_to_lists https://github.com/hanssv/otp/compare/erlang:maint...add_droplast_to_lists https://github.com/hanssv/otp/compare/erlang:maint...add_droplast_to_lists.patch A separate patch with usage will follow as soon as I can find the time for it! Cheers, Hans On 2014-01-16 11:26, Siri Hansen wrote: > Hi Hans! > > After many and long discussions we have now decided to re-open this > patch and approve it with some comments: > > 1. we would like the name of the function to be 'droplast'. > 2. we want the simple recursive implementation with no special handling > of bad arguments, i.e. we think it is ok with a function_clause error > for arguments that are not non-empty proper lists. > > Would you mind doing these adjustments in the patch? > > Best Regards > /siri > > > 2013/5/21 Hans Svensson > > > Hello Hans, > I've got some feedback on your patch after review: > We have decided to reject this patch as we don't see a general > need for > the new function. > > Thanks for showing interest in contributing! > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > > That is sad news, and we find it a bit strange since *you* (as in > the OTP team) yourself seems use this particular function/pattern > quite frequently. We did a quick search through the OTP code base > and found quite a few places where this particular function is > either implemented recursively and used, or just uses > reverse(tl(reverse(List)))). Also interesting to see is the > different names used: first, butlast, but_last and remove_last_element. > > Code implementing the "init"-function: > compiler > v3_core:first/1 > v3_kernel:first/1 > dialyzer > dialyzer_contracts:but_last/1 > dialyzer_gui:butlast/1 > hipe > hipe_icode_type:butlast/1 > orber > orber_interceptors:remove___last_element/1 > > Direct uses of reverse(tl(reverse(L))): > sasl > in systools_make:smart_guess/3 > wx_gen > in wx_gen:erl_skip_opt2/4 > ssh > in ssh_sftpd > > Any further comments on this, it is really not a "new" function it > is a missing function ;-) > > Cheers, > > Hans > > _________________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/__listinfo/erlang-patches > > > From henrik@REDACTED Thu Jan 23 08:58:02 2014 From: henrik@REDACTED (Henrik Nord) Date: Thu, 23 Jan 2014 08:58:02 +0100 Subject: [erlang-patches] Various improvements to CRL handling In-Reply-To: <20140121222652.GD30461@hijacked.us> References: <20131010063754.GW9818@hijacked.us> <20140121222652.GD30461@hijacked.us> Message-ID: <52E0CB8A.6070107@erlang.org> Hi I have sent it along for a review. Thank you for your contributions! On 2014-01-21 23:26, Andrew Thompson wrote: > On Thu, Oct 10, 2013 at 02:37:54AM -0400, Andrew Thompson wrote: >> https://github.com/erlang/otp/pull/97 > I have updated this PR with some more comments, and updated the > supporting tool I used to test it. I'm now able to validate the CRL > chain for every HTTPS site I could think of to test, including twitter > and myspace (which I could previously not get to validate, I think > because they use 'teletextstrings', which I've never even heard of). > > I think this PR really moves the state of CRL handling in Erlang solidly > into the real of 'possible', and as Basho will be shipping this patch with > Riak 2.0. I'd *really* like to see it land in R17. > > Thanks, > > Andrew > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Thu Jan 23 08:59:36 2014 From: henrik@REDACTED (Henrik Nord) Date: Thu, 23 Jan 2014 08:59:36 +0100 Subject: [erlang-patches] Implement 'honor_cipher_order' SSL server-side option In-Reply-To: <20140121222815.GE30461@hijacked.us> References: <20131022033217.GH9818@hijacked.us> <20140121222815.GE30461@hijacked.us> Message-ID: <52E0CBE8.5060404@erlang.org> Hi I have updated your branches in our system so that Ingela can have a look at this. Thank you for your contributions! On 2014-01-21 23:28, Andrew Thompson wrote: > On Mon, Oct 21, 2013 at 11:32:17PM -0400, Andrew Thompson wrote: >> https://github.com/erlang/otp/pull/111 > I've integrated Andreas' refactor and test suite and rebased this off of > master (Steve Vinoski told me to) and would like to see this in R17. The > new PR is at: > > https://github.com/erlang/otp/pull/201 > > Andrew > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Thu Jan 23 09:39:03 2014 From: henrik@REDACTED (Henrik Nord) Date: Thu, 23 Jan 2014 09:39:03 +0100 Subject: [erlang-patches] supervisor has wrong type annotation for sup_name In-Reply-To: References: Message-ID: <52E0D527.50304@erlang.org> HI I consider this more of a bug report than a actual patch. I will pass it along to the appropriate developers. if anyone is willing, and or patching similar things, feel free to include this. Thank you for your contribution! On 2014-01-15 14:05, Tom Wright wrote: > Error checking mail for tatwrightgambit@REDACTED > . Details Dismiss > Available Aaron Sokoloski > Idle (video enabled) Adam Kelly > > I'm not here right now > Idle ben1 > Idle (video enabled) Daniele Varrazzo > Idle Gustavo Carneiro > Idle John Aldis > Idle Tethys > Idle Tomer Chachamu > Offline David Lankester > Offline Joseph Buckle > > == Symptom == > > Dialyzer complains whenever you use 'via' with a supervisor despite it > being supported (both in practice and according to the docs). > > http://www.erlang.org/doc/man/supervisor.html: If > SupName={via,Module,Name} the supervisor is registered as Name using > the registry represented by Module > > This is still a problem as of release > 25237481ccccd3ddfa74582dc267632ad618ba30 at > https://github.com/erlang/otp.git > > === Patch === > > Replace: > -type sup_name() :: {'local', Name :: atom()} | {'global', Name :: > atom()}. > > with > > -type sup_name() :: {'local', Name :: atom()} | {'global', Name :: > atom()} | {'via', Module :: atom(), Name :: any() }. > > or similar. > > Thanks, > Tom > > > > > _______________________________________________ > 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 hanssv@REDACTED Thu Jan 23 10:50:56 2014 From: hanssv@REDACTED (Hans Svensson) Date: Thu, 23 Jan 2014 10:50:56 +0100 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <52E042BF.4020800@gmail.com> References: <517947E4.2040504@gmail.com> <517E2012.9030009@erlang.org> <51820EFB.4060109@gmail.com> <518269DD.701@gmail.com> <5195E04A.9020408@erlang.org> <519BD27D.8040605@gmail.com> <52E042BF.4020800@gmail.com> Message-ID: <52E0E600.3010002@gmail.com> And a few usages of this function introduced as well. Note, HiPE uses its own utiity function hipe_bb:butlast/1 which could/should be replaced by droplast as well. But that change looked a bit too invasive so I left it as an exercise ;-) I made this branch on top of the branch with lists:droplast/1, I hope I got it right! git fetch git://github.com/hanssv/otp.git using_lists_droplast https://github.com/hanssv/otp/compare/add_droplast_to_lists...using_lists_droplast https://github.com/hanssv/otp/compare/add_droplast_to_lists...using_lists_droplast.patch Cheers, /Hans On 2014-01-22 23:14, Hans Svensson wrote: > Finally got around to do the fixes. Screwed up my git branch, so the > lists:droplast/1 is now in a differently named branch: > > git fetch git://github.com/hanssv/otp.git add_droplast_to_lists > > https://github.com/hanssv/otp/compare/erlang:maint...add_droplast_to_lists > > https://github.com/hanssv/otp/compare/erlang:maint...add_droplast_to_lists.patch > > > A separate patch with usage will follow as soon as I can find the time > for it! > > Cheers, > > Hans > > On 2014-01-16 11:26, Siri Hansen wrote: >> Hi Hans! >> >> After many and long discussions we have now decided to re-open this >> patch and approve it with some comments: >> >> 1. we would like the name of the function to be 'droplast'. >> 2. we want the simple recursive implementation with no special handling >> of bad arguments, i.e. we think it is ok with a function_clause error >> for arguments that are not non-empty proper lists. >> >> Would you mind doing these adjustments in the patch? >> >> Best Regards >> /siri >> >> >> 2013/5/21 Hans Svensson > >> >> Hello Hans, >> I've got some feedback on your patch after review: >> We have decided to reject this patch as we don't see a general >> need for >> the new function. >> >> Thanks for showing interest in contributing! >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> >> That is sad news, and we find it a bit strange since *you* (as in >> the OTP team) yourself seems use this particular function/pattern >> quite frequently. We did a quick search through the OTP code base >> and found quite a few places where this particular function is >> either implemented recursively and used, or just uses >> reverse(tl(reverse(List)))). Also interesting to see is the >> different names used: first, butlast, but_last and >> remove_last_element. >> >> Code implementing the "init"-function: >> compiler >> v3_core:first/1 >> v3_kernel:first/1 >> dialyzer >> dialyzer_contracts:but_last/1 >> dialyzer_gui:butlast/1 >> hipe >> hipe_icode_type:butlast/1 >> orber >> orber_interceptors:remove___last_element/1 >> >> Direct uses of reverse(tl(reverse(L))): >> sasl >> in systools_make:smart_guess/3 >> wx_gen >> in wx_gen:erl_skip_opt2/4 >> ssh >> in ssh_sftpd >> >> Any further comments on this, it is really not a "new" function it >> is a missing function ;-) >> >> Cheers, >> >> Hans >> >> _________________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/__listinfo/erlang-patches >> >> >> > From alex.demidenko@REDACTED Thu Jan 23 09:49:13 2014 From: alex.demidenko@REDACTED (Alexander Demidenko) Date: Thu, 23 Jan 2014 15:49:13 +0700 Subject: [erlang-patches] ssh-3.0, ssh_connection_handler.erl Incorrect processing shutdown Message-ID: Hello, friends! ssh-3.0 (and below) has the following bug: If we have a lot of SSH sessions, we will be much more timeout. (4 seconds per each instance). When trying to complete the ssh-application, process, was created by a call ssh_connection_handler:init/1, receives a message of the form {'EXIT', Pid, shutdown}. After receiving this message, will been completed a series of calls ssh_connetion_handler:terminate, which ends the call ssh_connetion_handler:terminate_subsystem/1->ssh_system_sup:stop_subsystem/2 . At the end of the chain calls the supervisor:which_children (SystemSup). In this place there is a deadlock, because SystemSup process awaits the completion message. Since SystemSup not receive the completion message, it completes them forcibly by timeout (after 4 second) How can I see, in the ssh_connection_handler.erl module, invalid method terminate by initiative supervisor. In case of shutdown, we must not call terminate_subsytem/1 Suggest a patch that fixes this problem : --- src/ssh_connection_handler.erl +++ src/ssh_connection_handler.erl @@ -904,26 +904,31 @@ socket = Socket}) -> terminate_subsytem(Connection), (catch Transport:close(Socket)), ok; %% Terminated by supervisor -terminate(shutdown, StateName, #state{ssh_params = Ssh0} = State) -> +terminate(shutdown, _StateName, #state{ssh_params = Ssh0, + transport_cb = Transport, + socket = Socket} = State) -> DisconnectMsg = #ssh_msg_disconnect{code = ?SSH_DISCONNECT_BY_APPLICATION, description = "Application shutdown", language = "en"}, - {SshPacket, Ssh} = ssh_transport:ssh_packet(DisconnectMsg, Ssh0), + {SshPacket, _Ssh} = ssh_transport:ssh_packet(DisconnectMsg, Ssh0), send_msg(SshPacket, State), - terminate(normal, StateName, State#state{ssh_params = Ssh}); + (catch Transport:close(Socket)), + ok; terminate({shutdown, #ssh_msg_disconnect{} = Msg}, StateName, #state{ssh_params = Ssh0} = State) -> {SshPacket, Ssh} = ssh_transport:ssh_packet(Msg, Ssh0), send_msg(SshPacket, State), -- --------------------------------------------- With best regards, Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh_3.patch Type: text/x-patch Size: 1126 bytes Desc: not available URL: From henrik@REDACTED Thu Jan 23 11:20:17 2014 From: henrik@REDACTED (Henrik Nord) Date: Thu, 23 Jan 2014 11:20:17 +0100 Subject: [erlang-patches] erlang.el fixes In-Reply-To: References: Message-ID: <52E0ECE1.2080301@erlang.org> Thanks! We have bunched your emacs patches into one branch that we aim to get into 17.0 On 2014-01-08 05:38, Steve Vinoski wrote: > In the #erlang room on IRC, user leo2007 suggested some changes to the > emacs file erlang.el to prevent some errors. Details are in this pull > request: > > https://github.com/erlang/otp/pull/189 > > --steve > > > _______________________________________________ > 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 tuncer.ayaz@REDACTED Thu Jan 23 16:18:59 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 23 Jan 2014 16:18:59 +0100 Subject: [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer In-Reply-To: References: Message-ID: On Thu, Jan 16, 2014 at 7:15 PM, Sean Cribbs wrote: > Hi Erlangers, > > Ages ago, OTP shipped with a pre-built PLT for dialyzer, which was > removed reasons forgotten by most of us (probably the time/cost of > building it). Nowadays, because dialyzer is much improved > (parallelism!) and our computers are faster and have more cores, a > PLT for all of the standard library might only take a few minutes to > build. > > We've been increasing our usage of dialyzer at Basho and I have felt > that it seems extremely wasteful and unnecessary to build a partial > PLT of the standard library for every single project, when that > information only changes across OTP releases. I feel the Erlang/OTP > build process should include building a PLT that encompasses the > entire standard library. Aside from the reduced cost of building > PLTs for every different app, this may encourage others to start > using dialyzer on their projects. How do you define the standard library? I mean, why not include all libs/apps? I usually build a comprehensive PLT for each OTP release and unfortunately that uncovers type errors which should not be shipped in a release :(. > I'm offering to do the work to make this happen, but I need a little > guidance on where to start. I've looked at the dialyzer Makefile > from an older release where the PLT was included, but I'm concerned > the project structure has changed enough that the rules there no > longer apply. It seems the dialyzer runtime itself might also need > to be tweaked to automatically include the prebuilt PLT. > > Looking forward to hearing your thoughts and direction. Cheers! >From what I recall, a PLT references the beam files with absolute filenames. This might pose a problem you'd have to solve first. From sean@REDACTED Thu Jan 23 16:31:59 2014 From: sean@REDACTED (Sean Cribbs) Date: Thu, 23 Jan 2014 09:31:59 -0600 Subject: [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer In-Reply-To: References: Message-ID: On Thu, Jan 23, 2014 at 9:18 AM, Tuncer Ayaz wrote: > > How do you define the standard library? I mean, why not include > all libs/apps? > Yes, that is exactly what I mean. Anything that ships with OTP and is not explicitly disabled or skipped by the build process should be included. > > I usually build a comprehensive PLT for each OTP release and > unfortunately that uncovers type errors which should not be shipped in > a release :(. > > And we should be fixing those! :D > From what I recall, a PLT references the beam files with absolute > filenames. This might pose a problem you'd have to solve first. > Thank you for pointing that out. I'll look into that. -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Thu Jan 23 16:56:43 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 23 Jan 2014 16:56:43 +0100 Subject: [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer In-Reply-To: References: Message-ID: On Thu, Jan 23, 2014 at 4:31 PM, Sean Cribbs wrote: > On Thu, Jan 23, 2014 at 9:18 AM, Tuncer Ayaz wrote: >> >> >> How do you define the standard library? I mean, why not include all >> libs/apps? > > > Yes, that is exactly what I mean. Anything that ships with OTP and > is not explicitly disabled or skipped by the build process should be > included. > >> >> >> I usually build a comprehensive PLT for each OTP release and >> unfortunately that uncovers type errors which should not be shipped >> in a release :(. >> > > And we should be fixing those! :D See https://github.com/erlang/otp/pull/166. Unfortunately the one issue that needs discussion and decision-making by the OTP team has been reported and gone unfixed for a couple releases. See http://erlang.org/pipermail/erlang-bugs/2013-September/003765.html >> From what I recall, a PLT references the beam files with absolute >> filenames. This might pose a problem you'd have to solve first. > > > Thank you for pointing that out. I'll look into that. BTW, assuming this gets off the ground, would you suggest distributing the PLT with the tarball or in the git tree? I think the src tarball and maybe a separate tarball make more sense. For reference, my local R16B03 PLT is 4MB. This would also be in line with other generated files like configure scripts (what's generated vs what's edited). In the git tree it would only make sense to be included in a tagged tree, but that may be confusing, so release tarballs make the most sense to me. From sean@REDACTED Thu Jan 23 17:19:39 2014 From: sean@REDACTED (Sean Cribbs) Date: Thu, 23 Jan 2014 10:19:39 -0600 Subject: [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer In-Reply-To: References: Message-ID: On Thu, Jan 23, 2014 at 9:56 AM, Tuncer Ayaz wrote: > BTW, assuming this gets off the ground, would you suggest distributing > the PLT with the tarball or in the git tree? I think the src tarball > and maybe a separate tarball make more sense. For reference, my local > R16B03 PLT is 4MB. This would also be in line with other generated > files like configure scripts (what's generated vs what's edited). In > the git tree it would only make sense to be included in a tagged tree, > but that may be confusing, so release tarballs make the most sense to > me. > Neither. If you build OTP from source, it would be built during the normal build/install process. If you download a prebuilt binary package (Windows or something from ESL or a distribution maintainer), the PLT should be included in that package. -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Thu Jan 23 17:34:15 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 23 Jan 2014 17:34:15 +0100 Subject: [erlang-patches] Proposal: reinstate pre-built PLT for Dialyzer In-Reply-To: References: Message-ID: On Thu, Jan 23, 2014 at 5:19 PM, Sean Cribbs wrote: > On Thu, Jan 23, 2014 at 9:56 AM, Tuncer Ayaz wrote: >> >> BTW, assuming this gets off the ground, would you suggest >> distributing the PLT with the tarball or in the git tree? I think >> the src tarball and maybe a separate tarball make more sense. For >> reference, my local R16B03 PLT is 4MB. This would also be in line >> with other generated files like configure scripts (what's generated >> vs what's edited). In the git tree it would only make sense to be >> included in a tagged tree, but that may be confusing, so release >> tarballs make the most sense to me. > > > Neither. If you build OTP from source, it would be built during the > normal build/install process. If you download a prebuilt binary > package (Windows or something from ESL or a distribution > maintainer), the PLT should be included in that package. That sounds good to me. From henrik@REDACTED Fri Jan 24 15:55:07 2014 From: henrik@REDACTED (Henrik Nord) Date: Fri, 24 Jan 2014 15:55:07 +0100 Subject: [erlang-patches] [erlang-bugs] erlang.el indenter In-Reply-To: References: <5034B0F9.2000007@erlang.org> Message-ID: <52E27ECB.4060801@erlang.org> Ping?! Any update regarding this? On 2012-08-22 19:10, Tuncer Ayaz wrote: > On Wed, Aug 22, 2012 at 12:14 PM, Fredrik wrote: >> Hello Tomas, >> We have included this patch in the 'pu' branch. >> Thank you for the contribution! > A quick test revealed that erlang.el from 'pu' erroneously > re-indents the already correctly indented rebar:option_spec_list/0 > and also rebar:commands/0. Can you reproduce the regression? > >> On 08/21/2012 11:00 PM, Tomas Abrahamsson wrote: >>> On Mon, Aug 6, 2012 at 7:42 PM, Tuncer Ayaz wrote: >>>> There seems to be a bug in the indenter that mis-indents >>>> rebar.erl:commands/0, if it's indented as part of a larger region. >>>> The multi-line binary string seems to be the problem. >>>> >>>> rebar.erl:commands/0: >>>> https://github.com/basho/rebar/blob/491d52298e2/src/rebar.erl#L275-311 >>>> >>>> It works correctly when indenting the function itself with C-c C-q. >>> Hi, >>> >>> Here is a patch for indenting of multi-line strings, like the >>> one previously reported by Tuncer Ayaz. >>> >>> git fetch git://github.com/tomas-abrahamsson/otp.git >>> emacs-indent-multi-line-string >>> >>> >>> https://github.com/tomas-abrahamsson/otp/compare/emacs-indent-multi-line-string >>> >>> https://github.com/tomas-abrahamsson/otp/compare/emacs-indent-multi-line-string.patch >>> >>> Here's an illustration of what the patch does, >>> excerpt from the commit msg: >>> >>> Previously, typing C-M-\ or M-x indent-region RET on the following: >>> >>> somefunction() -> >>> S =<<" >>> text1 somemore1 >>> text2 somemore2 >>> ">>, >>> io:put_chars(S). >>> >>> resulted in this (note the "text2" line): >>> >>> somefunction() -> >>> S =<<" >>> text1 somemore1 >>> text2 somemore2 >>> ">>, >>> io:put_chars(S). >>> >>> Now, the indentation inside the multi-line string is left unchanged. >>> This is in line with how the Emacs C and Lisp mode treats multi-line >>> strings when indenting regions. >>> >>> >>> BRs >>> Tomas > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From tuncer.ayaz@REDACTED Fri Jan 24 17:49:53 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 24 Jan 2014 17:49:53 +0100 Subject: [erlang-patches] [erlang-bugs] erlang.el indenter In-Reply-To: <52E27ECB.4060801@erlang.org> References: <5034B0F9.2000007@erlang.org> <52E27ECB.4060801@erlang.org> Message-ID: On Fri, Jan 24, 2014 at 3:55 PM, Henrik Nord wrote: > Ping?! > > Any update regarding this? Fredrik's patch introduced a regression, so should not be merged, but the bugs in the indenter are still there. Steve Vinoski also analyzed the issues a couple days ago, and he has a more complete understanding of the Elisp code. Steve, can you summarize what's broken? > On 2012-08-22 19:10, Tuncer Ayaz wrote: >> >> On Wed, Aug 22, 2012 at 12:14 PM, Fredrik wrote: >>> >>> Hello Tomas, >>> We have included this patch in the 'pu' branch. >>> Thank you for the contribution! >> >> A quick test revealed that erlang.el from 'pu' erroneously >> re-indents the already correctly indented rebar:option_spec_list/0 >> and also rebar:commands/0. Can you reproduce the regression? >> >>> On 08/21/2012 11:00 PM, Tomas Abrahamsson wrote: >>>> >>>> On Mon, Aug 6, 2012 at 7:42 PM, Tuncer Ayaz wrote: >>>>> >>>>> There seems to be a bug in the indenter that mis-indents >>>>> rebar.erl:commands/0, if it's indented as part of a larger region. >>>>> The multi-line binary string seems to be the problem. >>>>> >>>>> rebar.erl:commands/0: >>>>> https://github.com/basho/rebar/blob/491d52298e2/src/rebar.erl#L275-311 >>>>> >>>>> It works correctly when indenting the function itself with C-c C-q. >>>> >>>> Hi, >>>> >>>> Here is a patch for indenting of multi-line strings, like the >>>> one previously reported by Tuncer Ayaz. >>>> >>>> git fetch git://github.com/tomas-abrahamsson/otp.git >>>> emacs-indent-multi-line-string >>>> >>>> >>>> >>>> https://github.com/tomas-abrahamsson/otp/compare/emacs-indent-multi-line-string >>>> >>>> >>>> https://github.com/tomas-abrahamsson/otp/compare/emacs-indent-multi-line-string.patch >>>> >>>> Here's an illustration of what the patch does, >>>> excerpt from the commit msg: >>>> >>>> Previously, typing C-M-\ or M-x indent-region RET on the >>>> following: >>>> >>>> somefunction() -> >>>> S =<<" >>>> text1 somemore1 >>>> text2 somemore2 >>>> ">>, >>>> io:put_chars(S). >>>> >>>> resulted in this (note the "text2" line): >>>> >>>> somefunction() -> >>>> S =<<" >>>> text1 somemore1 >>>> text2 somemore2 >>>> ">>, >>>> io:put_chars(S). >>>> >>>> Now, the indentation inside the multi-line string is left >>>> unchanged. >>>> This is in line with how the Emacs C and Lisp mode treats >>>> multi-line >>>> strings when indenting regions. From tuncer.ayaz@REDACTED Fri Jan 24 17:52:56 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 24 Jan 2014 17:52:56 +0100 Subject: [erlang-patches] [erlang-bugs] erlang.el indenter In-Reply-To: References: <5034B0F9.2000007@erlang.org> <52E27ECB.4060801@erlang.org> Message-ID: On Fri, Jan 24, 2014 at 5:49 PM, Tuncer Ayaz wrote: > On Fri, Jan 24, 2014 at 3:55 PM, Henrik Nord wrote: >> Ping?! >> >> Any update regarding this? > > Fredrik's patch introduced a regression, so should not be merged, but Sorry, that should have said Thomas (not Fredrik). > the bugs in the indenter are still there. > > Steve Vinoski also analyzed the issues a couple days ago, and he has > a more complete understanding of the Elisp code. Steve, can you > summarize what's broken? > >> On 2012-08-22 19:10, Tuncer Ayaz wrote: >>> >>> On Wed, Aug 22, 2012 at 12:14 PM, Fredrik wrote: >>>> >>>> Hello Tomas, >>>> We have included this patch in the 'pu' branch. >>>> Thank you for the contribution! >>> >>> A quick test revealed that erlang.el from 'pu' erroneously >>> re-indents the already correctly indented rebar:option_spec_list/0 >>> and also rebar:commands/0. Can you reproduce the regression? >>> >>>> On 08/21/2012 11:00 PM, Tomas Abrahamsson wrote: >>>>> >>>>> On Mon, Aug 6, 2012 at 7:42 PM, Tuncer Ayaz wrote: >>>>>> >>>>>> There seems to be a bug in the indenter that mis-indents >>>>>> rebar.erl:commands/0, if it's indented as part of a larger region. >>>>>> The multi-line binary string seems to be the problem. >>>>>> >>>>>> rebar.erl:commands/0: >>>>>> https://github.com/basho/rebar/blob/491d52298e2/src/rebar.erl#L275-311 >>>>>> >>>>>> It works correctly when indenting the function itself with C-c C-q. >>>>> >>>>> Hi, >>>>> >>>>> Here is a patch for indenting of multi-line strings, like the >>>>> one previously reported by Tuncer Ayaz. >>>>> >>>>> git fetch git://github.com/tomas-abrahamsson/otp.git >>>>> emacs-indent-multi-line-string >>>>> >>>>> >>>>> >>>>> https://github.com/tomas-abrahamsson/otp/compare/emacs-indent-multi-line-string >>>>> >>>>> >>>>> https://github.com/tomas-abrahamsson/otp/compare/emacs-indent-multi-line-string.patch >>>>> >>>>> Here's an illustration of what the patch does, >>>>> excerpt from the commit msg: >>>>> >>>>> Previously, typing C-M-\ or M-x indent-region RET on the >>>>> following: >>>>> >>>>> somefunction() -> >>>>> S =<<" >>>>> text1 somemore1 >>>>> text2 somemore2 >>>>> ">>, >>>>> io:put_chars(S). >>>>> >>>>> resulted in this (note the "text2" line): >>>>> >>>>> somefunction() -> >>>>> S =<<" >>>>> text1 somemore1 >>>>> text2 somemore2 >>>>> ">>, >>>>> io:put_chars(S). >>>>> >>>>> Now, the indentation inside the multi-line string is left >>>>> unchanged. >>>>> This is in line with how the Emacs C and Lisp mode treats >>>>> multi-line >>>>> strings when indenting regions. From tomas.abrahamsson@REDACTED Fri Jan 24 21:29:48 2014 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Fri, 24 Jan 2014 21:29:48 +0100 Subject: [erlang-patches] [erlang-bugs] erlang.el indenter In-Reply-To: References: <5034B0F9.2000007@erlang.org> <52E27ECB.4060801@erlang.org> Message-ID: On Fri, Jan 24, 2014 at 5:52 PM, Tuncer Ayaz wrote: > On Fri, Jan 24, 2014 at 5:49 PM, Tuncer Ayaz wrote: > > On Fri, Jan 24, 2014 at 3:55 PM, Henrik Nord wrote: > >> Ping?! > >> > >> Any update regarding this? > > > > Fredrik's patch introduced a regression, so should not be merged, but > > Sorry, that should have said Thomas (not Fredrik). Hehe, that should have said Tomas (not Thomas) :) Anyway, I agree this patch shouldn't be included. Thanks for noticing. I do not have any improvement to it, and don't think I will have for the near future . Best woul be to just forget about the patch. Or even better would of course if someone (Steve?) makes a better patch BRs Tomas > > the bugs in the indenter are still there. > > > > Steve Vinoski also analyzed the issues a couple days ago, and he has > > a more complete understanding of the Elisp code. Steve, can you > > summarize what's broken? > > > >> On 2012-08-22 19:10, Tuncer Ayaz wrote: > >>> > >>> On Wed, Aug 22, 2012 at 12:14 PM, Fredrik wrote: > >>>> > >>>> Hello Tomas, > >>>> We have included this patch in the 'pu' branch. > >>>> Thank you for the contribution! > >>> > >>> A quick test revealed that erlang.el from 'pu' erroneously > >>> re-indents the already correctly indented rebar:option_spec_list/0 > >>> and also rebar:commands/0. Can you reproduce the regression? > >>> > >>>> On 08/21/2012 11:00 PM, Tomas Abrahamsson wrote: > >>>>> > >>>>> On Mon, Aug 6, 2012 at 7:42 PM, Tuncer Ayaz wrote: > >>>>>> > >>>>>> There seems to be a bug in the indenter that mis-indents > >>>>>> rebar.erl:commands/0, if it's indented as part of a larger region. > >>>>>> The multi-line binary string seems to be the problem. > >>>>>> > >>>>>> rebar.erl:commands/0: > >>>>>> https://github.com/basho/rebar/blob/491d52298e2/src/rebar.erl#L275-311 > >>>>>> > >>>>>> It works correctly when indenting the function itself with C-c C-q. > >>>>> > >>>>> Hi, > >>>>> > >>>>> Here is a patch for indenting of multi-line strings, like the > >>>>> one previously reported by Tuncer Ayaz. > >>>>> > >>>>> git fetch git://github.com/tomas-abrahamsson/otp.git > >>>>> emacs-indent-multi-line-string > >>>>> > >>>>> > >>>>> > >>>>> https://github.com/tomas-abrahamsson/otp/compare/emacs-indent-multi-line-string > >>>>> > >>>>> > >>>>> https://github.com/tomas-abrahamsson/otp/compare/emacs-indent-multi-line-string.patch > >>>>> > >>>>> Here's an illustration of what the patch does, > >>>>> excerpt from the commit msg: > >>>>> > >>>>> Previously, typing C-M-\ or M-x indent-region RET on the > >>>>> following: > >>>>> > >>>>> somefunction() -> > >>>>> S =<<" > >>>>> text1 somemore1 > >>>>> text2 somemore2 > >>>>> ">>, > >>>>> io:put_chars(S). > >>>>> > >>>>> resulted in this (note the "text2" line): > >>>>> > >>>>> somefunction() -> > >>>>> S =<<" > >>>>> text1 somemore1 > >>>>> text2 somemore2 > >>>>> ">>, > >>>>> io:put_chars(S). > >>>>> > >>>>> Now, the indentation inside the multi-line string is left > >>>>> unchanged. > >>>>> This is in line with how the Emacs C and Lisp mode treats > >>>>> multi-line > >>>>> strings when indenting regions. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From n.oxyde@REDACTED Sun Jan 26 16:10:38 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 26 Jan 2014 16:10:38 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: References: <50F52480.9040100@erlang.org> <50F5325B.4010005@erlang.org> <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> <50FE512C.8020905@erlang.org> <185EEAD8-2C06-4BCB-8863-B6F8CC79460D@gmail.com> <5195E2BE.4060104@erlang.org> <406DB238-CBC1-4CCD-9AFF-1AC9DBFDA62B@gmail.com> <637F7FCA-3360-4F81-AFB1-C3D41A6E4139@gmail.com> <5199D1BA.6010206@erlang.org> <5B7E1490-0301-4BF7-B6E4-FBD792B3ECD1@gmail.com> <8BBBCFB9-8917-456D-B21B-558C163D09C8@gmail.com> <5! 236CAA6.7050609@erlang.org> <7ED437FD-45EA-4079-A381-AFC9F566F89E@gmail.com> <9587CB66-B48E-42EC-AEB2-7EA8B383714D@gmail.com> <5783C96C-164E-470D-AD84-45EDF2DC5B4E@gmail.com> <52544B0D.50501@cs.ntua.gr> <4C753C85-31F5-46E3-B91A-73356C815A7D@gmail.com> Message-ID: <2BC1A5AA-6C12-4D62-94AD-818EAC3F0936@gmail.com> Kostis, ping? -- Anthony Ramine Le 14 oct. 2013 ? 13:07, Anthony Ramine a ?crit : > Err, > > t2() -> fun identity/1. > > -- > Anthony Ramine > >> Le 14 oct. 2013 ? 12:45, Anthony Ramine a ?crit : >> >> Hello Kostis, >> >> To reproduce the crash, compile the following module with +native with my rm-reverse-eta-conversion branch: >> >> -module(t). >> -export([t1/0,t2/0]). >> >> t1() -> fun identity/1. >> t2() -> fun identity/2. >> >> identity(X) -> X. >> >> Loading this module compiled with HiPE on my branch will make HiPE crash in patch_funentries. Commenting the t2/0 function out makes the crash disappear. That shows that the cause of the crash is multiple references to the same local function. >> >> Regards, >> >> -- >> Anthony Ramine >> >>> Le 8 oct. 2013 ? 20:12, Kostis Sagonas a ?crit : >>> >>> Anyway, I am not sure how to contribute here and it will take me quite some time to investigate this from scratch, time which sadly I do not have these days. I can spend some time on this if I feel like hacking again one of the nights to come, but only if you minimize this and send me a self-contained module that shows the problem when you generate BEAM code with the changed compiler, but not with the vanilla. >> From vinoski@REDACTED Mon Jan 27 00:25:31 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Sun, 26 Jan 2014 18:25:31 -0500 Subject: [erlang-patches] [erlang-bugs] erlang.el indenter In-Reply-To: References: <5034B0F9.2000007@erlang.org> <52E27ECB.4060801@erlang.org> Message-ID: On Fri, Jan 24, 2014 at 11:49 AM, Tuncer Ayaz wrote: > On Fri, Jan 24, 2014 at 3:55 PM, Henrik Nord wrote: > > Ping?! > > > > Any update regarding this? > > Fredrik's patch introduced a regression, so should not be merged, but > the bugs in the indenter are still there. > > Steve Vinoski also analyzed the issues a couple days ago, and he has > a more complete understanding of the Elisp code. Steve, can you > summarize what's broken? In August 2013 Magnus Henoch posted a suggestion to use emacs syntax properties to solve these kinds of issues: http://erlang.org/pipermail/erlang-bugs/2013-August/003729.html I agree that's the right way to go, but I don't think it's a small amount of work. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Tue Jan 28 16:37:40 2014 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 28 Jan 2014 16:37:40 +0100 Subject: [erlang-patches] Fix DTrace build on Illumos In-Reply-To: References: <52A71690.7000808@erlang.org> Message-ID: <52E7CEC4.6050100@erlang.org> patch has been merged to master. Thank you for your contribution. Lukas On 15/01/14 23:32, Ryan Zezeski wrote: > Any news? Would be nice if R17 worked with DTrace on latest Illumos > kernel. > > > On Tue, Dec 10, 2013 at 8:26 AM, Henrik Nord > wrote: > > Thank you for your contribution ! > > patch has been assigned to be reviewed > > > > On 2013-12-07 22:00, Ryan Zezeski wrote: >> https://github.com/erlang/otp/pull/156 >> >> This patch fixes the configure and Makefile scripts to work with >> newer DTrace. This applies to all Illumos derivatives including >> OpenIndiana, SmartOS and OmnioOS. I've copied the commit message >> here verbatim. >> >> --- SNIP --- >> >> Fix DTrace build on Illumos >> >> DTrace was recently patched in Illumos to fail to create an >> object >> file if no probes are found. >> >> * https://www.illumos.org/issues/4248 >> * >> https://github.com/illumos/illumos-gate/commit/54a20ab41aadcb81c53e72fc65886e964e9add59 >> >> This patch fixes two issues: >> >> * Modify the configure script to pass an object file to >> `dtrace -G` >> that actually invokes a probe. >> >> * Remove creation of `dtrace_user.o` from the dyntrace >> Makefile. In a >> previous commit [1] Scott Fritchie relocated all the user >> probes >> into the VM proper due to difficulties with DTrace probes >> in shared >> libraries. The `dtrace_user.d` file is now empty and >> generates a >> header file with nothing in it. There is no longer any >> reason to >> generate `dtrace_user.o` because all the probes are in the >> VM. Thus >> all the steps for building `dtrace_user.o` have been removed. >> >> [1]: >> https://github.com/erlang/otp/commit/75552bd3bb4e7f3cf4dab81a5c81cf73b1d3fb99 >> >> --- END SNIP --- >> >> -Z >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > -- > /Henrik Nord Erlang/OTP > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Jan 30 18:26:39 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 30 Jan 2014 18:26:39 +0100 Subject: [erlang-patches] supervisor has wrong type annotation for sup_name In-Reply-To: <52E0D527.50304@erlang.org> References: <52E0D527.50304@erlang.org> Message-ID: There is a ticket for this. It is rather high up in our backlog, so hopefully it will be included in OTP 17. /siri 2014/1/23 Henrik Nord > HI > > I consider this more of a bug report than a actual patch. > I will pass it along to the appropriate developers. > > if anyone is willing, and or patching similar things, feel free to include > this. > > Thank you for your contribution! > > > On 2014-01-15 14:05, Tom Wright wrote: > > Error checking mail for tatwrightgambit@REDACTED Details Dismiss > [image: Available] Aaron Sokoloski [image: Idle (video > enabled)] Adam Kelly > I'm not here right now [image: Idle] ben1 [image: Idle (video enabled)] Daniele > Varrazzo [image: Idle] Gustavo Carneiro [image: Idle] John Aldis [image: > Idle] Tethys [image: Idle] Tomer Chachamu [image: Offline] David > Lankester [image: Offline] Joseph Buckle > == Symptom == > > Dialyzer complains whenever you use 'via' with a supervisor despite it > being supported (both in practice and according to the docs). > > http://www.erlang.org/doc/man/supervisor.html: If > SupName={via,Module,Name} the supervisor is registered as Name using the > registry represented by Module > > This is still a problem as of release > 25237481ccccd3ddfa74582dc267632ad618ba30 at > https://github.com/erlang/otp.git > > === Patch === > > Replace: > -type sup_name() :: {'local', Name :: atom()} | {'global', Name :: atom()}. > > with > > -type sup_name() :: {'local', Name :: atom()} | {'global', Name :: atom()} > | {'via', Module :: atom(), Name :: any() }. > > or similar. > > Thanks, > Tom > > > > > > _______________________________________________ > erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches > > > -- > /Henrik Nord Erlang/OTP > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: