From igor.clark@REDACTED Fri Mar 1 11:26:14 2019 From: igor.clark@REDACTED (Igor Clark) Date: Fri, 1 Mar 2019 10:26:14 +0000 Subject: [erlang-questions] Elixir from Erlang Message-ID: Hi folks, Seeing a lot of interesting stuff coming out of CodeBeam SF talking about Elixir and how it can leverage the Erlang platform and libraries. There are some really interesting Elixir projects there, and loads elsewhere. I haven?t looked into it much but from what I can tell Elixir takes full advantage of BEAM - there?s no special runtime or VM stuff happening, and the compiler just creates standard beam files, right? - and Elixir can use Erlang deps without any particular effort, just pull in via ?mix? - but there?s been no obvious mechanism created to expose Elixir back to Erlang, so there's no *obvious* way to pull in Elixir deps in an Erlang project. Meaning any new Erlang code can immediately be used in Elixir projects, but the reverse isn?t true; Erlang projects can?t easily get access to any of the heaps of new Elixir libraries being written. Is that right, or am I missing something? Is there a way to do this? Are there language-level reasons or extensions which mean this isn?t possible anyway? If not, what would be involved? Would it be possible for rebar3 to support this, so that erlang projects could just include elixir libraries as deps? Perhaps via a plugin that (for example) calls out to the Elixir compiler in the way the port compiler does for C code? How complex would that be? Thanks! Igor From justin.k.wood@REDACTED Fri Mar 1 13:39:41 2019 From: justin.k.wood@REDACTED (Justin Wood) Date: Fri, 01 Mar 2019 12:39:41 +0000 Subject: [erlang-questions] Elixir from Erlang In-Reply-To: References: Message-ID: Hi Igor, Tristan has already done some work around this. You will want to checkout https://github.com/tsloughter/rebar_mix. Justin Sent with ProtonMail Secure Email. ??????? Original Message ??????? On Friday, 1 March 2019 05:26, Igor Clark wrote: > Hi folks, > > Seeing a lot of interesting stuff coming out of CodeBeam SF talking about Elixir and how it can leverage the Erlang platform and libraries. There are some really interesting Elixir projects there, and loads elsewhere. > > I haven?t looked into it much but from what I can tell Elixir takes full advantage of BEAM - there?s no special runtime or VM stuff happening, and the compiler just creates standard beam files, right? - and Elixir can use Erlang deps without any particular effort, just pull in via ?mix? - but there?s been no obvious mechanism created to expose Elixir back to Erlang, so there's no obvious way to pull in Elixir deps in an Erlang project. Meaning any new Erlang code can immediately be used in Elixir projects, but the reverse isn?t true; Erlang projects can?t easily get access to any of the heaps of new Elixir libraries being written. > > Is that right, or am I missing something? Is there a way to do this? Are there language-level reasons or extensions which mean this isn?t possible anyway? If not, what would be involved? Would it be possible for rebar3 to support this, so that erlang projects could just include elixir libraries as deps? Perhaps via a plugin that (for example) calls out to the Elixir compiler in the way the port compiler does for C code? How complex would that be? > > Thanks! > Igor > > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From igor.clark@REDACTED Fri Mar 1 14:23:50 2019 From: igor.clark@REDACTED (Igor Clark) Date: Fri, 1 Mar 2019 13:23:50 +0000 Subject: [erlang-questions] Elixir from Erlang In-Reply-To: References: Message-ID: <51309CBC-0F11-4AC0-BFAA-1500AFFDA30C@gmail.com> Oh cool, I didn?t know about that, thanks (& thanks Tristan)! I?ll try it out. Cheers :-) > On 1 Mar 2019, at 12:39, Justin Wood wrote: > > Hi Igor, > > Tristan has already done some work around this. You will want to checkout https://github.com/tsloughter/rebar_mix. > > Justin > > > Sent with ProtonMail Secure Email. > > ??????? Original Message ??????? >> On Friday, 1 March 2019 05:26, Igor Clark wrote: >> >> Hi folks, >> >> Seeing a lot of interesting stuff coming out of CodeBeam SF talking about Elixir and how it can leverage the Erlang platform and libraries. There are some really interesting Elixir projects there, and loads elsewhere. >> >> I haven?t looked into it much but from what I can tell Elixir takes full advantage of BEAM - there?s no special runtime or VM stuff happening, and the compiler just creates standard beam files, right? - and Elixir can use Erlang deps without any particular effort, just pull in via ?mix? - but there?s been no obvious mechanism created to expose Elixir back to Erlang, so there's no obvious way to pull in Elixir deps in an Erlang project. Meaning any new Erlang code can immediately be used in Elixir projects, but the reverse isn?t true; Erlang projects can?t easily get access to any of the heaps of new Elixir libraries being written. >> >> Is that right, or am I missing something? Is there a way to do this? Are there language-level reasons or extensions which mean this isn?t possible anyway? If not, what would be involved? Would it be possible for rebar3 to support this, so that erlang projects could just include elixir libraries as deps? Perhaps via a plugin that (for example) calls out to the Elixir compiler in the way the port compiler does for C code? How complex would that be? >> >> Thanks! >> Igor >> >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From roger@REDACTED Fri Mar 1 15:18:42 2019 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 1 Mar 2019 14:18:42 +0000 Subject: [erlang-questions] Elixir from Erlang In-Reply-To: References: Message-ID: On Fri, 1 Mar 2019 at 10:26, Igor Clark wrote: > Is that right, or am I missing something? Is there a way to do this? Are there language-level reasons or extensions which mean this isn?t possible anyway? If not, what would be involved? Would it be possible for rebar3 to support this, so that erlang projects could just include elixir libraries as deps? Or you could use mix for compiling your Erlang project, at which point you get access to both sets of deps. Note, however, that there's an outstanding problem with running eunit tests from mix that we never managed to nail down properly. Or or you could compile your project with erlang.mk, which also supports hex.pm dependencies and can compile Elixir with a plugin. From Oliver.Korpilla@REDACTED Fri Mar 1 15:49:27 2019 From: Oliver.Korpilla@REDACTED (Oliver Korpilla) Date: Fri, 1 Mar 2019 15:49:27 +0100 Subject: [erlang-questions] Elixir from Erlang In-Reply-To: References: Message-ID: Hi. In our project we use mix as the central build tool, pulling in both Erlang and elixir dependencies. Experience is generally good with just a rather minor gripes: * It looks like some step has to always be redone for our rebar3 dependencies. syn and ibrowse are always listed as being rebuilt but always finish quickly. * It was tricky to use dependencies from local share and building without connecting to the internet. (Not allowed in our build process for reproducibility reasons.) So, our configuration based on mix/hex/distillery has been great for delivering a packaged release but I won't deny it has a few quirks of its own. Since we use asn1ct, syn, and ibrowse we have plenty of pure Erlang code in the mix (pardon the pun) and I could imagine using the same for a pure Erlang project, too. Oliver Gesendet:?Freitag, 01. M?rz 2019 um 15:18 Uhr Von:?"Roger Lipscombe" An:?"Igor Clark" Cc:?erlang-questions Betreff:?Re: [erlang-questions] Elixir from Erlang On Fri, 1 Mar 2019 at 10:26, Igor Clark wrote: > Is that right, or am I missing something? Is there a way to do this? Are there language-level reasons or extensions which mean this isn?t possible anyway? If not, what would be involved? Would it be possible for rebar3 to support this, so that erlang projects could just include elixir libraries as deps? Or you could use mix for compiling your Erlang project, at which point you get access to both sets of deps. Note, however, that there's an outstanding problem with running eunit tests from mix that we never managed to nail down properly. Or or you could compile your project with erlang.mk, which also supports hex.pm dependencies and can compile Elixir with a plugin. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From igor.clark@REDACTED Fri Mar 1 15:54:06 2019 From: igor.clark@REDACTED (Igor Clark) Date: Fri, 1 Mar 2019 14:54:06 +0000 Subject: [erlang-questions] Elixir from Erlang In-Reply-To: References: Message-ID: Thanks Roger. I have quite a lot of rebar3 projects and have got used to using it - I'd like to try to continue using that to build if possible. Will try mix or erlang.mk if I can't get anywhere with that. > On 1 Mar 2019, at 14:18, Roger Lipscombe wrote: > > On Fri, 1 Mar 2019 at 10:26, Igor Clark wrote: >> Is that right, or am I missing something? Is there a way to do this? Are there language-level reasons or extensions which mean this isn?t possible anyway? If not, what would be involved? Would it be possible for rebar3 to support this, so that erlang projects could just include elixir libraries as deps? > > Or you could use mix for compiling your Erlang project, at which point > you get access to both sets of deps. Note, however, that there's an > outstanding problem with running eunit tests from mix that we never > managed to nail down properly. > > Or or you could compile your project with erlang.mk, which also > supports hex.pm dependencies and can compile Elixir with a plugin. From Catenacci@REDACTED Fri Mar 1 16:45:40 2019 From: Catenacci@REDACTED (Onorio Catenacci) Date: Fri, 1 Mar 2019 10:45:40 -0500 Subject: [erlang-questions] Calling Elixir From Erlang In-Reply-To: References: Message-ID: > > > Message: 2 > Date: Fri, 1 Mar 2019 10:26:14 +0000 > From: Igor Clark > To: erlang-questions@REDACTED > Subject: [erlang-questions] Elixir from Erlang > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Hi folks, > > Seeing a lot of interesting stuff coming out of CodeBeam SF talking about > Elixir and how it can leverage the Erlang platform and libraries. There are > some really interesting Elixir projects there, and loads elsewhere. > > I haven?t looked into it much but from what I can tell Elixir takes full > advantage of BEAM - there?s no special runtime or VM stuff happening, and > the compiler just creates standard beam files, right? - and Elixir can use > Erlang deps without any particular effort, just pull in via ?mix? - but > there?s been no obvious mechanism created to expose Elixir back to Erlang, > so there's no *obvious* way to pull in Elixir deps in an Erlang project. > Meaning any new Erlang code can immediately be used in Elixir projects, but > the reverse isn?t true; Erlang projects can?t easily get access to any of > the heaps of new Elixir libraries being written. > > Is that right, or am I missing something? Is there a way to do this? Are > there language-level reasons or extensions which mean this isn?t possible > anyway? If not, what would be involved? Would it be possible for rebar3 to > support this, so that erlang projects could just include elixir libraries > as deps? Perhaps via a plugin that (for example) calls out to the Elixir > compiler in the way the port compiler does for C code? How complex would > that be? > > You might find this helpful to read: https://joearms.github.io/published/2017-12-18-Calling-Elixir-From-Erlang.html -- Onorio Catenacci http://onor.io https://twitter.com/OldDutchCap -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric@REDACTED Fri Mar 1 16:20:35 2019 From: eric@REDACTED (eric@REDACTED) Date: Fri, 01 Mar 2019 09:20:35 -0600 Subject: [erlang-questions] Looking for the Secure Coding Guide Message-ID: I reviewed the docs page on the Erlang site (http://www.erlang.org/docs) and searched elsewhere and cannot find a secure coding guide (yes, I did find some secure coding recommendations - like "do not program defensively" - http://www.erlang.se/doc/programming_rules.shtml#HDR11, but didn't find the advice compelling). So, does a secure coding guide exist exist and if so, could I get a copy of it? If one does not exist, is there something in development and when will it be available? Also, does anyone know if there is any type of static code assessment tool that exists to test for or verify adherence to the secure coding guide practices (again, presuming one exists)? Thanks for your help. Eric From juanmartinguillen@REDACTED Fri Mar 1 17:30:34 2019 From: juanmartinguillen@REDACTED (=?UTF-8?Q?Juan_Mart=C3=ADn_Guill=C3=A9n?=) Date: Fri, 1 Mar 2019 16:30:34 +0000 (UTC) Subject: [erlang-questions] Looking for the Secure Coding Guide In-Reply-To: References: Message-ID: <1531004690.7657180.1551457834872@mail.yahoo.com> Hi Eric, I am sure you would find these links useful: https://github.com/inaka/erlang_guidelines http://erlang.org/doc/man/dialyzer.html Juan Mart?n. El viernes, 1 de marzo de 2019 13:13:03 ART, eric@REDACTED escribi?: I reviewed the docs page on the Erlang site (http://www.erlang.org/docs) and searched elsewhere and cannot find a secure coding guide (yes, I did find some secure coding recommendations - like "do not program defensively" - http://www.erlang.se/doc/programming_rules.shtml#HDR11, but didn't find the advice compelling). So, does a secure coding guide exist exist and if so, could I get a copy of it? If one does not exist, is there something in development and when will it be available? Also, does anyone know if there is any type of static code assessment tool that exists to test for or verify adherence to the secure coding guide practices (again, presuming one exists)? Thanks for your help. Eric _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.clark@REDACTED Fri Mar 1 17:41:50 2019 From: igor.clark@REDACTED (Igor Clark) Date: Fri, 1 Mar 2019 16:41:50 +0000 Subject: [erlang-questions] Calling Elixir From Erlang In-Reply-To: References: Message-ID: <9CB08234-4584-4100-A679-5FB651ECC964@gmail.com> Thanks Onorio, yes I looked at that. I?m really looking for tooling that will do this at a project level, adding code paths in code seems a bit brittle for that. Following up, I haven?t got anywhere far with the rebar3 mix plugin, it seems sub-dependencies of elixir deps are a problem, and various libraries have problems not finding ?prod.exs?, which I guess is something to do with envs but haven?t really got time to dig into. Had a look at erlang.mk which seems to handle it much more, but I don?t know that I want to switch everything to using makefiles like that, I like rebar3. At some point if it becomes urgent I?ll look into just using mix for everything but for now as it was just curiousity I?m going to move on - if I could just add an elixir dep and start using it that?d be great but it definitely doesn?t seem that simple at the moment. Cheers and thanks for the responses, Igor On 1 Mar 2019, at 15:45, Onorio Catenacci wrote: >> >> Message: 2 >> Date: Fri, 1 Mar 2019 10:26:14 +0000 >> From: Igor Clark >> To: erlang-questions@REDACTED >> Subject: [erlang-questions] Elixir from Erlang >> Message-ID: >> Content-Type: text/plain; charset=utf-8 >> >> Hi folks, >> >> Seeing a lot of interesting stuff coming out of CodeBeam SF talking about Elixir and how it can leverage the Erlang platform and libraries. There are some really interesting Elixir projects there, and loads elsewhere. >> >> I haven?t looked into it much but from what I can tell Elixir takes full advantage of BEAM - there?s no special runtime or VM stuff happening, and the compiler just creates standard beam files, right? - and Elixir can use Erlang deps without any particular effort, just pull in via ?mix? - but there?s been no obvious mechanism created to expose Elixir back to Erlang, so there's no *obvious* way to pull in Elixir deps in an Erlang project. Meaning any new Erlang code can immediately be used in Elixir projects, but the reverse isn?t true; Erlang projects can?t easily get access to any of the heaps of new Elixir libraries being written. >> >> Is that right, or am I missing something? Is there a way to do this? Are there language-level reasons or extensions which mean this isn?t possible anyway? If not, what would be involved? Would it be possible for rebar3 to support this, so that erlang projects could just include elixir libraries as deps? Perhaps via a plugin that (for example) calls out to the Elixir compiler in the way the port compiler does for C code? How complex would that be? >> > > You might find this helpful to read: > > https://joearms.github.io/published/2017-12-18-Calling-Elixir-From-Erlang.html > > -- > Onorio Catenacci > http://onor.io > https://twitter.com/OldDutchCap > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From t6sn7gt@REDACTED Sat Mar 2 01:36:18 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Fri, 1 Mar 2019 19:36:18 -0500 Subject: [erlang-questions] Dummy question Message-ID: (LOL) I want to initiate a function parameter in the calling code to 0, as in: myfun(0, ....) -> The parameter won't be used the first time through the? function, so if I give it a name, as in: myfun(Param1, ...) -> something; myfun(Param1, ....) -> ??? myfun(value). I get a warning that Param1 wasn't used. If I do: myfun(Param1, ...) -> something; myfun(Param1, ....) -> ??? Param1 = value, ??? myfun(Param1). I get the usual immutable error. How do I do this? From eric.pailleau@REDACTED Sat Mar 2 09:38:47 2019 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 2 Mar 2019 09:38:47 +0100 Subject: [erlang-questions] Dummy question In-Reply-To: References: Message-ID: <64b062a2-e191-5248-5da7-c8ac6987f206@wanadoo.fr> Hello, either use '_' variable . myfun(Param1, ...) -> something; myfun(_, ....) -> myfun(value). or directly the param you want to match myfun(Param1, ...) -> something; myfun(0, ....) -> myfun(value). Le 02/03/2019 ? 01:36, Donald Steven a ?crit?: > myfun(Param1, ...) -> something; > myfun(Param1, ....) -> > > ??? myfun(value). From thomas.elsgaard@REDACTED Sat Mar 2 09:49:21 2019 From: thomas.elsgaard@REDACTED (Thomas Elsgaard) Date: Sat, 2 Mar 2019 09:49:21 +0100 Subject: [erlang-questions] Docker enviroment variables in releases ? Message-ID: Hi list! Any good solutions for using Docker enviroment variables in an Erlang release running i Docker ? Like it would be really cool to override default sys.config settings when starting the container with -e SOME_SYS_CONFIG_SETTING=1234 Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Sat Mar 2 10:00:21 2019 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Sat, 2 Mar 2019 11:00:21 +0200 Subject: [erlang-questions] Docker enviroment variables in releases ? In-Reply-To: References: Message-ID: Hello, I?ve built a simple wrapper over application:env and os:get_env for this type of purpose. https://github.com/fogfish/feta/blob/master/src/opts.erl In sys.config you define ``` {myapp, [ {port, {env, "CONFIG_MYAPP_PORT", "8080?}} ... ``` In erlang code: ``` Port = opts:val(port, myapp) ``` Then this function would check value of CONFIG_MYAPP_PORT variable and return it. The default value is return if env is not defined. If any one finds this feature useful for other projects, I can think of evolving this feature further on. Best Regards, Dmitry > On 2 Mar 2019, at 10.49, Thomas Elsgaard wrote: > > Hi list! > > Any good solutions for using Docker enviroment variables in an Erlang release running i Docker ? > > Like it would be really cool to override default sys.config settings when starting the container with -e SOME_SYS_CONFIG_SETTING=1234 > > Thomas > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From eric@REDACTED Fri Mar 1 18:04:30 2019 From: eric@REDACTED (eric@REDACTED) Date: Fri, 01 Mar 2019 11:04:30 -0600 Subject: [erlang-questions] Looking for the Secure Coding Guide In-Reply-To: <1531004690.7657180.1551457834872@mail.yahoo.com> References: <1531004690.7657180.1551457834872@mail.yahoo.com> Message-ID: <6df3692484a97b4b929ced6357b4fcb2@svetcov.com> Hi Juan, Thanks for the links - I guess I'm trying to find something that operationalizes specifically for Erlang the OWASP guidance found here (Yes, I'm aware that not all of this applies to Erlang, but where it does apply, is there guidance around how it should be operationalized in Erlang development?) - https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf The documents you linked to touch on security while focusing on operational results (in my opinion) as did the document I linked to below; however, they don't focus on security. I'm looking for something that focuses specifically on security regardless of whether it makes coding easier or more difficult. In other words, Regarding Dialyzer, I'm not sure that Dialyzer would call out something that is syntactically correct; however, unadvisable as it introduces risk to the information. It is syntactically correct to receive input without any input validation (this would not throw an error in the application); however, would Dialyzer provide an alert that input validation was not present (just a for instance)? Thanks again, Eric Svetcov On 01.03.2019 10:30, Juan Mart?n Guill?n wrote: > Hi Eric, > > I am sure you would find these links useful: > > https://github.com/inaka/erlang_guidelines > > http://erlang.org/doc/man/dialyzer.html > > Juan Mart?n. > > El viernes, 1 de marzo de 2019 13:13:03 ART, eric@REDACTED > escribi?: > > I reviewed the docs page on the Erlang site > (http://www.erlang.org/docs) > > and searched elsewhere and cannot find a secure coding guide (yes, I > did > > find some secure coding recommendations - like "do not program > > defensively" - http://www.erlang.se/doc/programming_rules.shtml#HDR11, > [1] > > but didn't find the advice compelling). So, does a secure coding guide > > > exist exist and if so, could I get a copy of it? If one does not > exist, > > is there something in development and when will it be available? > > Also, does anyone know if there is any type of static code assessment > > tool that exists to test for or verify adherence to the secure coding > > guide practices (again, presuming one exists)? > > Thanks for your help. > > Eric > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > Links: > ------ > [1] http://www.erlang.se/doc/programming_rules.shtml#HDR11, From juanmartinguillen@REDACTED Fri Mar 1 18:46:01 2019 From: juanmartinguillen@REDACTED (=?UTF-8?Q?Juan_Mart=C3=ADn_Guill=C3=A9n?=) Date: Fri, 1 Mar 2019 17:46:01 +0000 (UTC) Subject: [erlang-questions] Looking for the Secure Coding Guide In-Reply-To: <6df3692484a97b4b929ced6357b4fcb2@svetcov.com> References: <1531004690.7657180.1551457834872@mail.yahoo.com> <6df3692484a97b4b929ced6357b4fcb2@svetcov.com> Message-ID: <1034514136.7702670.1551462361696@mail.yahoo.com> Hi Eric, Now I see what you are looking for. You are right; Dialyzer, or any similar tool, would make a semantic static analysis on the source code and won't complain about input validations or that sort of things. A tool that makes a security analysis similar to the link you sent would be something very different from that. In fact, it would be something a software tool could only do partially IMHO. Anyway, I don't know about any tool that does what you are needing, I'm sorry. Juan Mart?n. El viernes, 1 de marzo de 2019 14:04:31 ART, eric@REDACTED escribi?: Hi Juan, Thanks for the links - I guess I'm trying to find something that operationalizes specifically for Erlang the OWASP guidance found here (Yes, I'm aware that not all of this applies to Erlang, but where it does apply, is there guidance around how it should be operationalized in Erlang development?) - https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf The documents you linked to touch on security while focusing on operational results (in my opinion) as did the document I linked to below; however, they don't focus on security. I'm looking for something that focuses specifically on security regardless of whether it makes coding easier or more difficult. In other words, Regarding Dialyzer, I'm not sure that Dialyzer would call out something that is syntactically correct; however, unadvisable as it introduces risk to the information. It is syntactically correct to receive input without any input validation (this would not throw an error in the application); however, would Dialyzer provide an alert that input validation was not present (just a for instance)? Thanks again, Eric Svetcov On 01.03.2019 10:30, Juan Mart?n Guill?n wrote: > Hi Eric, > > I am sure you would find these links useful: > > https://github.com/inaka/erlang_guidelines > > http://erlang.org/doc/man/dialyzer.html > > Juan Mart?n. > > El viernes, 1 de marzo de 2019 13:13:03 ART, eric@REDACTED > escribi?: > > I reviewed the docs page on the Erlang site > (http://www.erlang.org/docs) > > and searched elsewhere and cannot find a secure coding guide (yes, I > did > > find some secure coding recommendations - like "do not program > > defensively" - http://www.erlang.se/doc/programming_rules.shtml#HDR11, > [1] > > but didn't find the advice compelling). So, does a secure coding guide > > > exist exist and if so, could I get a copy of it? If one does not > exist, > > is there something in development and when will it be available? > > Also, does anyone know if there is any type of static code assessment > > tool that exists to test for or verify adherence to the secure coding > > guide practices (again, presuming one exists)? > > Thanks for your help. > > Eric > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > Links: > ------ > [1] http://www.erlang.se/doc/programming_rules.shtml#HDR11, -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric@REDACTED Fri Mar 1 19:14:10 2019 From: eric@REDACTED (eric@REDACTED) Date: Fri, 01 Mar 2019 12:14:10 -0600 Subject: [erlang-questions] Looking for the Secure Coding Guide In-Reply-To: <1034514136.7702670.1551462361696@mail.yahoo.com> References: <1531004690.7657180.1551457834872@mail.yahoo.com> <6df3692484a97b4b929ced6357b4fcb2@svetcov.com> <1034514136.7702670.1551462361696@mail.yahoo.com> Message-ID: Hi Juan, Thanks again for your response. I agree that no static code analysis tool is perfect. Anything that can partially mitigate a risk is better than no mitigation at all. Other than PEST and Dialyzer, I'm not finding anything specific for Erlang. I will see if there is anything at RSA next week (I'm not hopeful). Regarding a document for secure coding techniques that addresses much of what is in the OWASP guidance would be helpful. I haven't found anything around that yet. Just the documents you mentioned below as well as a few others have little bits of security, but nothing comprehensive. Thanks again for your help. Knowing that something isn't available is almost as good as having the document. At least I can now spend time figuring out how to address this and not try to look for something that doesn't exist. Thanks this has been helpful, Eric Svetcov On 01.03.2019 11:46, Juan Mart?n Guill?n wrote: > Hi Eric, > > Now I see what you are looking for. > > You are right; Dialyzer, or any similar tool, would make a semantic > static analysis on the source code and won't complain about input > validations or that sort of things. > > A tool that makes a security analysis similar to the link you sent > would be something very different from that. > > In fact, it would be something a software tool could only do partially > IMHO. > > Anyway, I don't know about any tool that does what you are needing, > I'm sorry. > > Juan Mart?n. > > El viernes, 1 de marzo de 2019 14:04:31 ART, eric@REDACTED > escribi?: > > Hi Juan, > > Thanks for the links - I guess I'm trying to find something that > operationalizes specifically for Erlang the OWASP guidance found here > (Yes, I'm aware that not all of this applies to Erlang, but where it > does apply, is there guidance around how it should be operationalized > in > Erlang development?) - > https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf > > The documents you linked to touch on security while focusing on > operational results (in my opinion) as did the document I linked to > below; however, they don't focus on security. I'm looking for > something > that focuses specifically on security regardless of whether it makes > coding easier or more difficult. In other words, > > Regarding Dialyzer, I'm not sure that Dialyzer would call out > something > that is syntactically correct; however, unadvisable as it introduces > risk to the information. It is syntactically correct to receive input > without any input validation (this would not throw an error in the > application); however, would Dialyzer provide an alert that input > validation was not present (just a for instance)? > > Thanks again, > Eric Svetcov > > On 01.03.2019 10:30, Juan Mart?n Guill?n wrote: >> Hi Eric, >> >> I am sure you would find these links useful: >> >> https://github.com/inaka/erlang_guidelines >> >> http://erlang.org/doc/man/dialyzer.html >> >> Juan Mart?n. >> >> El viernes, 1 de marzo de 2019 13:13:03 ART, eric@REDACTED >> escribi?: >> >> I reviewed the docs page on the Erlang site >> (http://www.erlang.org/docs) >> >> and searched elsewhere and cannot find a secure coding guide (yes, I >> did >> >> find some secure coding recommendations - like "do not program >> >> defensively" - > http://www.erlang.se/doc/programming_rules.shtml#HDR11, >> [1] >> >> but didn't find the advice compelling). So, does a secure coding > guide >> >> >> exist exist and if so, could I get a copy of it? If one does not >> exist, >> >> is there something in development and when will it be available? >> >> Also, does anyone know if there is any type of static code > assessment >> >> tool that exists to test for or verify adherence to the secure > coding >> >> guide practices (again, presuming one exists)? >> >> Thanks for your help. >> >> Eric >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> Links: >> ------ >> [1] http://www.erlang.se/doc/programming_rules.shtml#HDR11, From roger@REDACTED Sat Mar 2 16:02:37 2019 From: roger@REDACTED (Roger Lipscombe) Date: Sat, 2 Mar 2019 15:02:37 +0000 Subject: [erlang-questions] Docker enviroment variables in releases ? In-Reply-To: References: Message-ID: If you're using relx (and if you're using rebar3 or erlang.mk, you probably are), it already supports simple environment substitution. Use ${VAR} in "sys.config.src". On Sat, 2 Mar 2019 at 08:49, Thomas Elsgaard wrote: > > Hi list! > > Any good solutions for using Docker enviroment variables in an Erlang release running i Docker ? > > Like it would be really cool to override default sys.config settings when starting the container with -e SOME_SYS_CONFIG_SETTING=1234 > > Thomas > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From thomas.elsgaard@REDACTED Sat Mar 2 16:10:49 2019 From: thomas.elsgaard@REDACTED (Thomas Elsgaard) Date: Sat, 2 Mar 2019 16:10:49 +0100 Subject: [erlang-questions] Docker enviroment variables in releases ? In-Reply-To: References: Message-ID: Thanks to Dmitry and Roger, very useful ... I will look into it.. Thomas On Sat, 2 Mar 2019 at 16:02 Roger Lipscombe wrote: > If you're using relx (and if you're using rebar3 or erlang.mk, you > probably are), it already supports simple environment substitution. > Use ${VAR} in "sys.config.src". > > On Sat, 2 Mar 2019 at 08:49, Thomas Elsgaard > wrote: > > > > Hi list! > > > > Any good solutions for using Docker enviroment variables in an Erlang > release running i Docker ? > > > > Like it would be really cool to override default sys.config settings > when starting the container with -e SOME_SYS_CONFIG_SETTING=1234 > > > > Thomas > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobgus@REDACTED Sun Mar 3 05:44:33 2019 From: bobgus@REDACTED (Bob Gustafson) Date: Sat, 2 Mar 2019 22:44:33 -0600 Subject: [erlang-questions] Looking for the Secure Coding Guide In-Reply-To: References: <1531004690.7657180.1551457834872@mail.yahoo.com> <6df3692484a97b4b929ced6357b4fcb2@svetcov.com> <1034514136.7702670.1551462361696@mail.yahoo.com> Message-ID: <0a05c761-ca4b-cd94-6f0b-75fa7d545f63@chidig.com> I was reading the article "https://spectrum.ieee.org/computing/software/mayhem-the-machine-that-finds-software-vulnerabilities-then-patches-them" when your email came up. The article talks about the prize winner in the DARPA Cyber Grand Challenge of 2016. They won $2m for their automated bug finder and patcher. 6 other challengers did pretty well too. Perhaps it was not written in Erlang and perhaps the challenge problems were not so asynchronous, but it is a good story and represents a milestone in automated bug finding. No source code necessary. Bob G On 3/1/19 12:14 PM, eric@REDACTED wrote: > Hi Juan, > > Thanks again for your response. I agree that no static code analysis > tool is perfect. Anything that can partially mitigate a risk is better > than no mitigation at all. Other than PEST and Dialyzer, I'm not > finding anything specific for Erlang. I will see if there is anything > at RSA next week (I'm not hopeful). > > Regarding a document for secure coding techniques that addresses much > of what is in the OWASP guidance would be helpful. I haven't found > anything around that yet. Just the documents you mentioned below as > well as a few others have little bits of security, but nothing > comprehensive. > > Thanks again for your help. Knowing that something isn't available is > almost as good as having the document. At least I can now spend time > figuring out how to address this and not try to look for something > that doesn't exist. > > Thanks this has been helpful, > Eric Svetcov > > On 01.03.2019 11:46, Juan Mart?n Guill?n wrote: >> Hi Eric, >> >> Now I see what you are looking for. >> >> You are right; Dialyzer, or any similar tool, would make a semantic >> static analysis on the source code and won't complain about input >> validations or that sort of things. >> >> A tool that makes a security analysis similar to the link you sent >> would be something very different from that. >> >> In fact, it would be something a software tool could only do partially >> IMHO. >> >> Anyway, I don't know about any tool that does what you are needing, >> I'm sorry. >> >> Juan Mart?n. >> >> El viernes, 1 de marzo de 2019 14:04:31 ART, eric@REDACTED >> escribi?: >> >> Hi Juan, >> >> Thanks for the links - I guess I'm trying to find something that >> operationalizes specifically for Erlang the OWASP guidance found here >> (Yes, I'm aware that not all of this applies to Erlang, but where it >> does apply, is there guidance around how it should be operationalized >> in >> Erlang development?) - >> https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf >> >> The documents you linked to touch on security while focusing on >> operational results (in my opinion) as did the document I linked to >> below; however, they don't focus on security. I'm looking for >> something >> that focuses specifically on security regardless of whether it makes >> coding easier or more difficult. In other words, >> >> Regarding Dialyzer, I'm not sure that Dialyzer would call out >> something >> that is syntactically correct; however, unadvisable as it introduces >> risk to the information. It is syntactically correct to receive input >> without any input validation (this would not throw an error in the >> application); however, would Dialyzer provide an alert that input >> validation was not present (just a for instance)? >> >> Thanks again, >> Eric Svetcov >> >> On 01.03.2019 10:30, Juan Mart?n Guill?n wrote: >>> Hi Eric, >>> >>> I am sure you would find these links useful: >>> >>> https://github.com/inaka/erlang_guidelines >>> >>> http://erlang.org/doc/man/dialyzer.html >>> >>> Juan Mart?n. >>> >>> El viernes, 1 de marzo de 2019 13:13:03 ART, eric@REDACTED >>> escribi?: >>> >>> I reviewed the docs page on the Erlang site >>> (http://www.erlang.org/docs) >>> >>> and searched elsewhere and cannot find a secure coding guide (yes, I >>> did >>> >>> find some secure coding recommendations - like "do not program >>> >>> defensively" - >> http://www.erlang.se/doc/programming_rules.shtml#HDR11, >>> [1] >>> >>> but didn't find the advice compelling). So, does a secure coding >> guide >>> >>> >>> exist exist and if so, could I get a copy of it? If one does not >>> exist, >>> >>> is there something in development and when will it be available? >>> >>> Also, does anyone know if there is any type of static code >> assessment >>> >>> tool that exists to test for or verify adherence to the secure >> coding >>> >>> guide practices (again, presuming one exists)? >>> >>> Thanks for your help. >>> >>> Eric >>> >>> _______________________________________________ >>> >>> erlang-questions mailing list >>> >>> erlang-questions@REDACTED >>> >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> Links: >>> ------ >>> [1] http://www.erlang.se/doc/programming_rules.shtml#HDR11, > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From t6sn7gt@REDACTED Sun Mar 3 13:55:43 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Sun, 3 Mar 2019 07:55:43 -0500 Subject: [erlang-questions] array:set Message-ID: <2f252c49-0f30-ca44-80b7-2dea2e667a17@aim.com> Apparently, array:set can only be used on one index at a time, as in:? array:set(?TRACK1, Track1, Sounds), I'd like to do the equivalent of (I made up the syntax): array:set(?TRACK1, Track1; ?TRACK2, Track2, ...; Sounds), Is my only option a recursive function making 2 lists and then going through them using hd(), tl()? From jesper.louis.andersen@REDACTED Sun Mar 3 14:22:41 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 3 Mar 2019 14:22:41 +0100 Subject: [erlang-questions] Looking for the Secure Coding Guide In-Reply-To: References: Message-ID: > > (yes, I did > find some secure coding recommendations - like "do not program > defensively" - http://www.erlang.se/doc/programming_rules.shtml#HDR11, > but didn't find the advice compelling). So, does a secure coding guide > exist exist and if so, could I get a copy of it? If one does not exist, > is there something in development and when will it be available? > > While I do recognize we should have a commented version of the OWASP guide in the view of Erlang, and other functional programming languages such as Haskell or Ocaml, the above requires some elaboration as to why it is a guideline. There are two kinds of input validation in a system for a given function. One is when you have an untrusted source (colloquially known as "the enemy"), the other is when the source is trusted. For the case where the enemy provides data, it should usually be validated with a function looking something like: -spec validate(Input :: term()) -> {ok, Canonicalized :: term()} | {error, validation}. This also generally holds true for library design. An application boundary should generally behave somewhat nicely and be able to return errors as values so one can match on them and act accordingly. The rule is that you should punt decisions to the caller of the library, though it does have its exceptions. However, this is not what the coding guidelines suggest. They pertain to the case of trusted input. In that case, writing protective routines (i.e., defensive code), is usually a mistake in an Erlang system. There is a supervision tree ready to handle this problem if it occurs, and you cannot always fully reflect on each and every possible failure scenario. In fact, trying to mitigate a failure you have not seen in the wild might introduce bugs into the program when it does happen. So defensive code is not a priori a safer option. For trusted sources, it is better to program for the happy path only, and let the errors be logged so they can be handled properly by rewiring of code. In general, catching all mistakes, trying to mitigate them, and then propagate the error upwards in the call stack is not always a desirable thing. You might not have thought about the particular failure scenario, so it is impossible to mitigate the error before having seen it in the wild. Or you might have assumed that the particular scenario never occurs in practice, in which case the error report is a subtle hint and teaching moment. I often hedge by leaving out some error handling early on, and then provoke the error cases to install the correct handling for the ones that do occur in the real world. There are some reasons this approach is good: * Writing for the happy path first allows a much faster time-to-market for a given feature. Some languages force you to envision a lot of defensive additional code before the code is marketable. And as laid out above, that code is rarely executed. Hence, if it contains a bug, you might not know early on. * If an error occur in the production system, you don't have to handle the error immediately if it rare in occurrence. By construction, a crashing process cannot tie up resources in the system (caveats: ETS, disk storage resources, etc). So you can often leave the error in there until the next service window or deploy. This is particularly strong in the modern world where people continuously deploy code, because you can deploy code and then hotfix the code for the missing corner cases subsequently. This leads to a much faster development cycle overall. * In a concurrent system, there are certain failure scenarios you might want to detect rather than handle. Detection is often far easier than properly mitigating. So if the occurrence is rare, you can just restart the program and try again. Finally, there are some overarching security considerations: * The atom table is limited to about a million atoms. Do not let the enemy create arbitrary atoms (see: e.g., erlang:binary_to_existing_atom(..) for a mitigation technique). * ETS is not garbage collected, so make sure to clean up. Having a janitor process doing the cleanup and using the concept of monitors to manage the lifetime of other processes storing data in ETS can help a lot. * The security boundary is the distributed erlang cluster, not an individual node. Once a node is breached, the whole cluster is lost. * You can mark processes as containing sensitive information, which makes them unable to be inspected by accident by an operator. This is useful if a process contains the current table of law enforcement wiretaps. There are ways around it, but the idea is that you don't accidentally stumble into information that is sensitive. * The gen_server callback Module:format_status(..) can be used to devour password information in error logs. * Erlang is a generally memory safe language, so many errors pertaining to bounds checks are not possible. Something like Heartbleed cannot occur, though something like the Bleichenbacher attacks can. * However do put sensible resource limits on enemies. Don't let them create a binary of 2 gigabyte of size in memory. Load regulate heavy-weight computation in the node and only allow a limited number of those processes. * Integer overflow/underflow doesn't occur in the language since integers have arbitrary size. But when writing them out into a fixed size integer, care must be taken as it will wrap around there. * And finally, do not use the dynamic features of the system to let the enemy execute arbitrary code on your end. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fly@REDACTED Sun Mar 3 14:24:45 2019 From: fly@REDACTED (Fred Youhanaie) Date: Sun, 3 Mar 2019 13:24:45 +0000 Subject: [erlang-questions] array:set In-Reply-To: <2f252c49-0f30-ca44-80b7-2dea2e667a17@aim.com> References: <2f252c49-0f30-ca44-80b7-2dea2e667a17@aim.com> Message-ID: <2fb9a5e5-f680-b569-6ebc-4f782ab0e2bc@anydata.co.uk> If your intention is to set the entire contents of the array, then you can use array:from_list/2, see the man page for details. On 03/03/2019 12:55, Donald Steven wrote: > Apparently, array:set can only be used on one index at a time, as in: array:set(?TRACK1, Track1, Sounds), > > > I'd like to do the equivalent of (I made up the syntax): array:set(?TRACK1, Track1; ?TRACK2, Track2, ...; Sounds), > > > Is my only option a recursive function making 2 lists and then going through them using hd(), tl()? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From t6sn7gt@REDACTED Sun Mar 3 14:33:04 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Sun, 3 Mar 2019 08:33:04 -0500 Subject: [erlang-questions] array:set In-Reply-To: <2fb9a5e5-f680-b569-6ebc-4f782ab0e2bc@anydata.co.uk> References: <2f252c49-0f30-ca44-80b7-2dea2e667a17@aim.com> <2fb9a5e5-f680-b569-6ebc-4f782ab0e2bc@anydata.co.uk> Message-ID: <0abd28c6-18dd-1bf8-90e7-f9ff3592f25c@aim.com> Perfect!? Thanks Fred. On 3/3/2019 8:24 AM, Fred Youhanaie wrote: > If your intention is to set the entire contents of the array, then you > can use array:from_list/2, see the man page for details. > > On 03/03/2019 12:55, Donald Steven wrote: >> Apparently, array:set can only be used on one index at a time, as in: >> array:set(?TRACK1, Track1, Sounds), >> >> >> I'd like to do the equivalent of (I made up the syntax): >> array:set(?TRACK1, Track1; ?TRACK2, Track2, ...; Sounds), >> >> >> Is my only option a recursive function making 2 lists and then going >> through them using hd(), tl()? >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From gergo.nyiro@REDACTED Mon Mar 4 08:50:48 2019 From: gergo.nyiro@REDACTED (=?UTF-8?B?TnlpcsWRIEdlcmfFkQ==?=) Date: Mon, 4 Mar 2019 08:50:48 +0100 Subject: [erlang-questions] trending json rpc library In-Reply-To: References: Message-ID: Finally I choose jsonrpc2-erlang with cowboy. I created a simple json-rpc service which exposes the inet_res:resolve function: https://github.com/nyirog/erdns. On Tue, Feb 26, 2019 at 1:11 PM Nyir? Gerg? wrote: > > Dear List, > > I would like to write a small service in Erlang with json-rpc interface. > The goal would be to introduce Erlang at my company so the > dependencies and configuration of the service should be kept on minimum. > > At my first search I found three projects: > - https://github.com/zuiderkwast/jsonrpc2-erlang.git > - https://github.com/tonyg/erlang-rfc4627.git > - https://github.com/alavrik/piqi-erlang.git > > Erlang-rfc4627 seems good for me, but I struggle with the debugging of > the json service. > > Could you give me some advice which json-rpc is mainstream nowadays? > > Cheers, > Gerg? From albin.stigo@REDACTED Mon Mar 4 12:41:55 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Mon, 4 Mar 2019 12:41:55 +0100 Subject: [erlang-questions] WebRTC peer library Message-ID: Hi, Is anyone aware of a WebRTC peer library/application for Erlang, or an effort to write one (_not_ a signalling server)? Like this one https://github.com/pions/webrtc but Erlang. Googling hasn't really turned anything up... --Albin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard@REDACTED Mon Mar 4 22:56:40 2019 From: gerhard@REDACTED (Gerhard Lazu) Date: Mon, 4 Mar 2019 21:56:40 +0000 Subject: [erlang-questions] How we run a Phoenix app in production, 2019 edition Message-ID: Hi, We have a Phoenix app that has been keeping users happy since 2016. We have updated the setup for 2019 and did a write-up on how it all works: https://changelog.com/posts/the-new-changelog-setup-for-2019 Post has diagrams and screenshots if you are in a rush. All code is open-source, MIT license. Happy to discuss, Gerhard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Tue Mar 5 12:13:47 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Tue, 5 Mar 2019 12:13:47 +0100 Subject: [erlang-questions] WebRTC peer library In-Reply-To: References: Message-ID: > Most tricky was to recompile Firefox several times to understand that implementation differs from standard. That doesn't sound very encouraging... :-) I've spent two days wrapping my head around the WebRTC backronym soup. At least it seems it could be nicely separated into smaller components that would be individually useful... I will have a go at it and see if I can come up with something interesting. --Albin On Tue, Mar 5, 2019 at 9:58 AM Max Lapshin wrote: > > I promised to opensource our implementation couple of years ago, but stil haven't done it because too tight integration inside flussonic. > > We have took dtls4srtp code floating around, srtp from Lemekov, implemented the rest: sdp, websocket, etc. > > Most tricky was to recompile Firefox several times to understand that implementation differs from standard. > > From frank.muller.erl@REDACTED Tue Mar 5 16:52:04 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Tue, 5 Mar 2019 16:52:04 +0100 Subject: [erlang-questions] A Docker image for my Erlang release Message-ID: Hi guys Any pointer(s) on how to build a Docker images for Erlang release? Ideally, I would like to be able to build Erlang using KERL and not use any prebuilt Erlang version. /Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Tue Mar 5 17:53:34 2019 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Tue, 5 Mar 2019 17:53:34 +0100 Subject: [erlang-questions] A Docker image for my Erlang release In-Reply-To: References: Message-ID: Taking a look at kerl?s CI should help ;) If you have any questions ask a way. On Tue 5 Mar 2019 at 16:52, Frank Muller wrote: > Hi guys > > Any pointer(s) on how to build a Docker images for Erlang release? > > Ideally, I would like to be able to build Erlang using KERL and not use > any prebuilt Erlang version. > > > /Frank _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Cheers, -- Pierre Fenoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.safarov@REDACTED Tue Mar 5 18:29:00 2019 From: s.safarov@REDACTED (Sergey Safarov) Date: Tue, 5 Mar 2019 20:29:00 +0300 Subject: [erlang-questions] A Docker image for my Erlang release In-Reply-To: References: Message-ID: I also have skills on docker image creation I can help create using alpine dist and using hooks. ??, 5 ???. 2019 ?. ? 19:53, Pierre Fenoll : > Taking a look at kerl?s CI should help ;) > If you have any questions ask a way. > > On Tue 5 Mar 2019 at 16:52, Frank Muller > wrote: > >> Hi guys >> >> Any pointer(s) on how to build a Docker images for Erlang release? >> >> Ideally, I would like to be able to build Erlang using KERL and not use >> any prebuilt Erlang version. >> >> >> /Frank _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- > > Cheers, > -- > Pierre Fenoll > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.casilli@REDACTED Tue Mar 5 18:49:23 2019 From: christopher.casilli@REDACTED (chris casilli) Date: Tue, 5 Mar 2019 12:49:23 -0500 Subject: [erlang-questions] How to unset or remove the proxy option on Erlang httpc client default profile once set? Message-ID: <6C5AF2D0-6C00-4BB2-8595-6AEDF16CCF7A@gmail.com> Hello, I?m trying to figure out how to remove the proxy option settings once they?ve been set. The proxy originally is not set and shown as undefined: httpc:get_options(all). {ok,[{proxy,{undefined,[]}}, {https_proxy,{undefined,[]}}, {pipeline_timeout,0}, {max_pipeline_length,2}, {max_keep_alive_length,5}, {keep_alive_timeout,120000}, {max_sessions,2}, {cookies,disabled}, {verbose,false}, {ipfamily,inet}, {ip,default}, {port,default}, {socket_opts,[]}, {unix_socket,undefined}]} I'm able to set the proxy option without problem: httpc:set_options([{proxy, {{"www-proxy.mycompany.com", 8000},["localhost"]}}]). How do you unset the proxy back not undefined (or no proxy) when it is not needed? I tried: httpc:set_options([{proxy,{undefined, []}}]). But it throws an exception: ** exception throw: {error,{bad_option,proxy,{undefined,[]}}} in function httpc:bad_option/2 (httpc.erl, line 1102) in call from httpc:validate_options/2 (httpc.erl, line 932) in call from httpc:validate_options/1 (httpc.erl, line 922) in call from httpc:set_options/2 (httpc.erl, line 236) What am I doing wrong? Thanks, Chris Casilli -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex@REDACTED Tue Mar 5 20:09:46 2019 From: alex@REDACTED (alex@REDACTED) Date: Tue, 5 Mar 2019 14:09:46 -0500 Subject: [erlang-questions] wxWidgets 3.1.2 Message-ID: Has anyone encountered this same problem... the configuration for v21.2.6 doesn't seem to find the installation of the most recent version (3.1.2) of wxWidgets. Although the README file under lib/wx identifies wxWidgets 2.8.* as target, version 3.0.* seem to have been working. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Tue Mar 5 20:40:49 2019 From: comptekki@REDACTED (Wes James) Date: Tue, 5 Mar 2019 12:40:49 -0700 Subject: [erlang-questions] wxWidgets 3.1.2 In-Reply-To: References: Message-ID: On ubuntu I install what is available in the standard libs and it works. libwxgtk3.0-dev. In the past I've toyed with later versions (compile source), but erlang didn't seem to like it. For awhile the working lib was 2.8, now it's 3.0. -wes On Tue, Mar 5, 2019 at 12:09 PM alex@REDACTED wrote: > Has anyone encountered this same problem... the configuration for v21.2.6 > doesn't seem to find the installation of the most recent version (3.1.2) of > wxWidgets. Although the README file under lib/wx identifies wxWidgets > 2.8.* as target, version 3.0.* seem to have been working. > > Thanks, > Alex > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex@REDACTED Tue Mar 5 23:37:42 2019 From: alex@REDACTED (alex@REDACTED) Date: Tue, 5 Mar 2019 17:37:42 -0500 Subject: [erlang-questions] wxWidgets 3.1.2 In-Reply-To: References: Message-ID: <4840145d2bb1dc3286a9d0de74c0e430@smtp.hushmail.com> Thanks for you feedback!? Really appreciate it.? Went back and realized that I didn't have the wxStyledTextControl enabled (--enable-stc) for the wxWidgets configuration, plus I could also enable compatibility with version 2.8.x, which doesn't hurt.? The configuration I ended up using, if it might help anyone out there is... ./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --enable-mediactrl --with-opengl --enable-graphics_ctx --with-gtk=3 --enable-unicode --enable-compat28 --enable-plugins --enable-stc? --enable-shared --enable-stl --enable-webkit --enable-webview After recompiling (and packaging) everything, things seem to be working fine now... 1> l(wx). 2> wx:new(). {wx_ref,0,wx,[]} Thanks, Alex On 3/5/19 2:40 PM, Wes James wrote: > On ubuntu I install what is available in the standard libs and it > works.??libwxgtk3.0-dev.? In the past I've toyed with later versions > (compile source), but erlang didn't seem to like it.? For awhile the > working lib was 2.8, now it's 3.0. > > -wes > > On Tue, Mar 5, 2019 at 12:09 PM alex@REDACTED > > > wrote: > > Has anyone encountered this same problem... the configuration for > v21.2.6 doesn't seem to find the installation of the most recent > version (3.1.2) of wxWidgets.? Although the README file under > lib/wx identifies wxWidgets 2.8.* as target, version 3.0.* seem to > have been working. > > Thanks, > Alex > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom@REDACTED Wed Mar 6 02:42:36 2019 From: tom@REDACTED (Thomas Cioppettini) Date: Tue, 5 Mar 2019 20:42:36 -0500 Subject: [erlang-questions] Release Notes Github Message-ID: Is there any possibility to include the link to the corresponding README on erlang.org whenever a new version is released? Every time I update erlang I have to hunt this page down to see what new features or changes have been made. Most projects nowadays include either a changelog or include the information in the releases panel in github. The notes are usually excellent, just extremely difficult to find. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Wed Mar 6 07:51:46 2019 From: dangud@REDACTED (Dan Gudmundsson) Date: Wed, 6 Mar 2019 07:51:46 +0100 Subject: [erlang-questions] wxWidgets 3.1.2 In-Reply-To: <4840145d2bb1dc3286a9d0de74c0e430@smtp.hushmail.com> References: <4840145d2bb1dc3286a9d0de74c0e430@smtp.hushmail.com> Message-ID: wx still uses the 2.8-api so you need to explicit enable that in 3.1.2 with --enable-compat28 On Tue, Mar 5, 2019 at 11:37 PM alex@REDACTED wrote: > Thanks for you feedback! Really appreciate it. Went back and realized > that I didn't have the wxStyledTextControl enabled (--enable-stc) for the > wxWidgets configuration, plus I could also enable compatibility with > version 2.8.x, which doesn't hurt. The configuration I ended up using, if > it might help anyone out there is... > > ./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc > --enable-mediactrl --with-opengl --enable-graphics_ctx --with-gtk=3 > --enable-unicode --enable-compat28 --enable-plugins --enable-stc > --enable-shared --enable-stl --enable-webkit --enable-webview > > After recompiling (and packaging) everything, things seem to be working > fine now... > > 1> l(wx). > 2> wx:new(). > {wx_ref,0,wx,[]} > > Thanks, > Alex > > > On 3/5/19 2:40 PM, Wes James wrote: > > On ubuntu I install what is available in the standard libs and it > works. libwxgtk3.0-dev. In the past I've toyed with later versions > (compile source), but erlang didn't seem to like it. For awhile the > working lib was 2.8, now it's 3.0. > > -wes > > On Tue, Mar 5, 2019 at 12:09 PM alex@REDACTED wrote: > >> Has anyone encountered this same problem... the configuration for v21.2.6 >> doesn't seem to find the installation of the most recent version (3.1.2) of >> wxWidgets. Although the README file under lib/wx identifies wxWidgets >> 2.8.* as target, version 3.0.* seem to have been working. >> >> Thanks, >> Alex >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Wed Mar 6 17:10:28 2019 From: otp@REDACTED (Erlang/OTP) Date: Wed, 6 Mar 2019 17:10:28 +0100 Subject: [erlang-questions] Patch Package OTP 21.2.7 Released Message-ID: <20190306161028.GA27428@erix.ericsson.se> Patch Package: OTP 21.2.7 Git Tag: OTP-21.2.7 Date: 2019-03-06 Trouble Report Id: OTP-15551, OTP-15651, OTP-15652 Seq num: ERIERL-304 System: OTP Release: 21 Application: erts-10.2.5, kernel-6.2.1 Predecessor: OTP 21.2.6 Check out the git tag OTP-21.2.7, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- OTP-21.2.7 ------------------------------------------------------ --------------------------------------------------------------------- --- Fixed Bugs and Malfunctions --- OTP-15551 Application(s): erts, otp Fixes of install/release phase in build system. -- The source tree was modified when installing/releasing and/or applying a patch. -- Some files were installed with wrong access rights. -- If applying a patch (using otp_patch_apply) as another user (except root) than the user that built the source, the documentation was not properly updated. --------------------------------------------------------------------- --- erts-10.2.5 ----------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.2.5 application can *not* be applied independently of other applications on an arbitrary OTP 21 installation. On a full OTP 21 installation, also the following runtime dependencies have to be satisfied: -- kernel-6.1 (first satisfied in OTP 21.1) -- sasl-3.3 (first satisfied in OTP 21.2) --- Fixed Bugs and Malfunctions --- OTP-15551 Application(s): erts, otp Fixes of install/release phase in build system. -- The source tree was modified when installing/releasing and/or applying a patch. -- Some files were installed with wrong access rights. -- If applying a patch (using otp_patch_apply) as another user (except root) than the user that built the source, the documentation was not properly updated. OTP-15651 Application(s): erts, kernel Related Id(s): ERIERL-304 Setting the recbuf size of an inet socket the buffer is also automatically increased. Fix a bug where the auto adjustment of inet buffer size would be triggered even if an explicit inet buffer size had already been set. OTP-15652 Application(s): erts Related Id(s): ERIERL-304 Reading from UDP using active true or active N mode has been optimized when more packets than specified by read_packets are available on the socket. Full runtime dependencies of erts-10.2.5: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- kernel-6.2.1 ---------------------------------------------------- --------------------------------------------------------------------- Note! The kernel-6.2.1 application can *not* be applied independently of other applications on an arbitrary OTP 21 installation. On a full OTP 21 installation, also the following runtime dependency has to be satisfied: -- erts-10.2.5 (first satisfied in OTP 21.2.7) --- Fixed Bugs and Malfunctions --- OTP-15651 Application(s): erts, kernel Related Id(s): ERIERL-304 Setting the recbuf size of an inet socket the buffer is also automatically increased. Fix a bug where the auto adjustment of inet buffer size would be triggered even if an explicit inet buffer size had already been set. Full runtime dependencies of kernel-6.2.1: erts-10.2.5, sasl-3.0, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From alex@REDACTED Wed Mar 6 18:16:21 2019 From: alex@REDACTED (alex@REDACTED) Date: Wed, 6 Mar 2019 12:16:21 -0500 Subject: [erlang-questions] wxWidgets 3.1.2 In-Reply-To: References: <4840145d2bb1dc3286a9d0de74c0e430@smtp.hushmail.com> Message-ID: <20bcec1fd5c5de4fd92f83e3afd7ba18@smtp.hushmail.com> I imagined that to be the case, but thanks for clearing that out! Cheers, Alex On 3/6/19 1:51 AM, Dan Gudmundsson wrote: > wx still uses the 2.8-api so you need to explicit enable that in 3.1.2 > with ?--enable-compat28 > > On Tue, Mar 5, 2019 at 11:37 PM alex@REDACTED > > > wrote: > > Thanks for you feedback!? Really appreciate it.? Went back and > realized that I didn't have the wxStyledTextControl enabled > (--enable-stc) for the wxWidgets configuration, plus I could also > enable compatibility with version 2.8.x, which doesn't hurt.? The > configuration I ended up using, if it might help anyone out there > is... > > ./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc > --enable-mediactrl --with-opengl --enable-graphics_ctx > --with-gtk=3 --enable-unicode --enable-compat28 --enable-plugins > --enable-stc --enable-shared --enable-stl --enable-webkit > --enable-webview > > After recompiling (and packaging) everything, things seem to be > working fine now... > > 1> l(wx). > 2> wx:new(). > {wx_ref,0,wx,[]} > > Thanks, > Alex > > > On 3/5/19 2:40 PM, Wes James wrote: >> On ubuntu I install what is available in the standard libs and it >> works.??libwxgtk3.0-dev.? In the past I've toyed with later >> versions (compile source), but erlang didn't seem to like it.? >> For awhile the working lib was 2.8, now it's 3.0. >> >> -wes >> >> On Tue, Mar 5, 2019 at 12:09 PM alex@REDACTED >> > > wrote: >> >> Has anyone encountered this same problem... the configuration >> for v21.2.6 doesn't seem to find the installation of the most >> recent version (3.1.2) of wxWidgets.? Although the README >> file under lib/wx identifies wxWidgets 2.8.* as target, >> version 3.0.* seem to have been working. >> >> Thanks, >> Alex >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andras.Bekes@REDACTED Thu Mar 7 10:13:08 2019 From: Andras.Bekes@REDACTED (Bekes, Andras G) Date: Thu, 7 Mar 2019 09:13:08 +0000 Subject: [erlang-questions] {error,closed} vs. {error,econnreset} Message-ID: Hi Lukas, All, Was there any progress in this? You mentioned a major rewrite of gen_tcp below, possibly breaking backwards compatibility. Where can I find more info about the plans and progress? Thanks, Andras From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Bekes, Andras G Sent: Friday, August 31, 2018 12:43 PM To: Lukas Larsson Cc: Erlang Questions Subject: Re: [erlang-questions] {error,closed} vs. {error,econnreset} Note: This e-mail has been flagged because although the sender appears to be internal, the e-mail originated outside the Firm. The senders address may have been forged, which can be an indicator of malicious activity. If you have any concerns about the content or sender of this e-mail, please report it immediately via the Spam Report button in Outlook or email spambutton@REDACTED Hi Lukas, All, I do not have TCP dump, but according to strace, the error is: <... writev resumed> ) = -1 ENOTCONN (Transport endpoint is not connected) The error indeed happens on a write, and on the Erlang side this is reported as a normal close, at the next gen_tcp:recv call. Let us not go into discussing what can cause this error on a socket (unix domain BTW). It is irrelevant here. The important here is that this socket error, and any other socket error shall not be confused with an orderly shutdown of the socket. I support the below mentioned proposal of making the default behavior report all errors, and the masking behavior explicitly selected with an option. Regards, Andras From: Lukas Larsson [mailto:lukas@REDACTED] Sent: Thursday, August 16, 2018 2:37 PM To: Bekes, Andras G (IST) Cc: Erlang Questions Subject: Re: [erlang-questions] {error,closed} vs. {error,econnreset} Hello, On Mon, 6 Aug 2018, 10:49 Bekes, Andras G, > wrote: Hi All, Reviving this old thread again, because I am getting more and more convinced that we need further changes. We're still observing connection close events when an error should be reported to gen_tcp level. It can be a reset error somehow still not reported as 'econnreset', but I suspect it must be some other error. I suppose that you have not managed to catch the error in a tcp dump as Rory asked for? I checked the code in inet_drv.c. The function static int tcp_recv(tcp_descriptor* desc, int request_len) seems to work properly -- a reset is either reported as closed or econnreset, depending on show_econnreset, all other errors are reported as errors. However, the function static int tcp_send_or_shutdown_error(tcp_descriptor* desc, int err) hides errors. Connection reset errors are properly handled (either reported as closed or econnreset, depending on show_econnreset), but all other errors are just reported as closed. Active and passive modes have independent code paths, but I think both do the same: all errors are reported as normal close -- except for econnreset. There is a merge of error codes happening in tcp_send_error, so some other errors get mapped into econnreset before tcp_send_or_shutdown_error is called. Apparently I need to detect all errors. Is it possible to implement a show_errors (or show_all_errors) flag, too? Actually, this new flag could replace the current show_econnreset flag. Having two separate flags for econnreset & others requires more complex code, but having a single show_errors flag would simplify the current that provides special treatment for econnreset. I am not sure if it makes much sense to expose connection reset errors but still mask all other errors as normal close events. From a farther point of view, it seems there are network-programming tasks (there is at least one!), for which Erlang seems not suitable. This sounds rather sad. Luckily the fix doesn't seem difficult. What do you think? I agree that it should be possible to get the original error from the tcp stack. Given the discussions here https://github.com/erlang/otp/pull/731, maybe it is time to reverse the options so that returning the original error becomes the default and you have to set an option to get the backwards compatible behaviour? We are currently in the process of a major overhaul of gen_tcp and friends, so maybe this can be changed while doing that, as we are bound to break backwards compatibility in various ways during that rewrite anyways. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Fri Mar 8 11:58:09 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Fri, 8 Mar 2019 17:58:09 +0700 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) Message-ID: Hi Folks, I need your help to review my code. I create and linking 3 process manually without using recursive. And inside p1 and p2 i using IF statement to check to make sure spawning process will only once. I mean, is part code below is a good idea? 1. IsPidExists = whereis(xxx), 2. if IsPidExists =:= undefined -> 3. Pid = spawn_link(?MODULE, the_p, []), 4. register(xxx, Pid); 5. true -> true 6. end, 7. This is my code https://pastebin.com/3MXcUNUp Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.r.nohl@REDACTED Fri Mar 8 15:03:27 2019 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Fri, 8 Mar 2019 15:03:27 +0100 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: Message-ID: I Gusti Ngurah Oka Prinarjaya ezt ?rta (id?pont: 2019. m?rc. 8., P, 12:11): > > Hi Folks, > > I need your help to review my code. I create and linking 3 process manually without using recursive. And inside p1 and p2 i using IF statement to check to make sure spawning process will only once. > > I mean, is part code below is a good idea? > > IsPidExists = whereis(xxx), > if IsPidExists =:= undefined -> > Pid = spawn_link(?MODULE, the_p, []), > register(xxx, Pid); > true -> true > end, Generally this is not a good idea, there's a race condition between checking that the process is registered (the whereis/1 call) and registering the new process. A better idea is to start the process and let the process itself to register. If register fails, it means that there's already a process registered, so the just started process can terminate. So your code could look like something like this: starter() -> spawn(?MODULE, the_first_p, []). the_first_p() -> register(pidfirstp, self()), spawn_link(?MODULE, the_second_p, []), ... the_first_p(). Actually if the register call fails, it throws a badarg and the process dies automatically, simplifying the code. From Michael.K.Schmidt@REDACTED Fri Mar 8 16:55:20 2019 From: Michael.K.Schmidt@REDACTED (Michael Schmidt) Date: Fri, 8 Mar 2019 15:55:20 +0000 Subject: [erlang-questions] Running OTP Tests Message-ID: I'm trying to add test coverage to my PR: https://github.com/erlang/otp/pull/2114 Are there any tips for running specific OTP tests? I found this, but it acts like I have to generate a new release everytime I modify a .erl file: https://github.com/erlang/otp/wiki/Running-tests I can successfully run "ts:run(stdlib, beam_lib_SUITE, [batch])", but I can't seem to make any fixes/changes/etc My goal is to be able to run beam_lib_SUITE.erl after I modify beam_lib.erl rapidly Thanks! Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.K.Schmidt@REDACTED Fri Mar 8 17:01:28 2019 From: Michael.K.Schmidt@REDACTED (Michael Schmidt) Date: Fri, 8 Mar 2019 16:01:28 +0000 Subject: [erlang-questions] Running OTP Tests Message-ID: I'm trying to add test coverage to my PR: https://github.com/erlang/otp/pull/2114 Are there any tips for running specific OTP tests? I found this, but it acts like I have to generate a new release everytime I modify a .erl file: https://github.com/erlang/otp/wiki/Running-tests I can successfully run "ts:run(stdlib, beam_lib_SUITE, [batch])", but I can't seem to make any fixes/changes/etc My goal is to be able to run beam_lib_SUITE.erl after I modify beam_lib.erl rapidly Thanks! Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Fri Mar 8 19:39:36 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Fri, 8 Mar 2019 19:39:36 +0100 Subject: [erlang-questions] Running OTP Tests In-Reply-To: References: Message-ID: On Fri, Mar 8, 2019 at 5:01 PM Michael Schmidt wrote: > I?m trying to add test coverage to my PR: > > https://github.com/erlang/otp/pull/2114 > > > > > Are there any tips for running specific OTP tests? > > > > I found this, but it acts like I have to generate a new release everytime > I modify a .erl file: > > https://github.com/erlang/otp/wiki/Running-tests > > > > > I can successfully run ?ts:run(stdlib, beam_lib_SUITE, [batch])?, but I > can?t seem to make any fixes/changes/etc > See HOWTO/TESTING.md, especially the notes about ERL_TOP and PATH. I regularly use these instructions to perform regression testing around changes to Erlang/OTP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hpwei01@REDACTED Sat Mar 9 01:24:42 2019 From: hpwei01@REDACTED (HP Wei) Date: Fri, 8 Mar 2019 19:24:42 -0500 Subject: [erlang-questions] trying to compile erlang 19.0 on two solaris-on-sparc Message-ID: I am seeking advice on how to solve an issue. I try to build erlang from otp_src_19.0 on two solaris on sparc machines. They both have SunOS 5.11 (11.3) sun4u sparc They both have gcc build by Sun?s cc using Sun?s ld and as. [ I would think that these two machines are exactly the same.] However, On the first machine, the building went OK. NOTE: configure ?prefix=/a/path make ON the other one, the ?make? process went into lib/hipe/misc, and then ERLC ../ebin/hipe_consttab.beam Failed to create main carrier for binary_alloc ?> the building failed. ??????????? Since the erl run successfully on the first machine, I copied it to the 2nd machine and tried to run it (erl). But it failed with the same error message: Failed to create main carrier for binary_alloc Abort ---------------------------------------- Anyone has any idea on how I can find the problem? Something in the system on the 2nd machine must have been set up differently. Thanks HP PS: I first tried to compile version 21.0 But that process failed on both machines with apparently different issues. I was surprised that I got version 19.0 compiled on one machine. From okaprinarjaya@REDACTED Sat Mar 9 14:41:01 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sat, 9 Mar 2019 20:41:01 +0700 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: Message-ID: Hi Attila Rajmund Nohl, After i implement your suggestion, i get error when execute any of function call_the_*_p() for example: 3> newbie:starter(). <0.112.0> 4> newbie:call_the_second(). =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === Error in process <0.113.0> with exit value: {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, {newbie,the_second_p,0, [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, {line,17}]}]} {<0.113.0>,"the_second_p()","Halo second p!"} This is my new modified code https://pastebin.com/iYCxkkuz Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl < attila.r.nohl@REDACTED> menulis: > I Gusti Ngurah Oka Prinarjaya ezt ?rta > (id?pont: 2019. m?rc. 8., P, 12:11): > > > > Hi Folks, > > > > I need your help to review my code. I create and linking 3 process > manually without using recursive. And inside p1 and p2 i using IF statement > to check to make sure spawning process will only once. > > > > I mean, is part code below is a good idea? > > > > IsPidExists = whereis(xxx), > > if IsPidExists =:= undefined -> > > Pid = spawn_link(?MODULE, the_p, []), > > register(xxx, Pid); > > true -> true > > end, > > Generally this is not a good idea, there's a race condition between > checking that the process is registered (the whereis/1 call) and > registering the new process. A better idea is to start the process and > let the process itself to register. If register fails, it means that > there's already a process registered, so the just started process can > terminate. So your code could look like something like this: > > starter() -> > spawn(?MODULE, the_first_p, []). > > the_first_p() -> > register(pidfirstp, self()), > spawn_link(?MODULE, the_second_p, []), > ... > the_first_p(). > > Actually if the register call fails, it throws a badarg and the > process dies automatically, simplifying the code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cean.ebengt@REDACTED Sat Mar 9 23:23:48 2019 From: cean.ebengt@REDACTED (bengt) Date: Sat, 9 Mar 2019 23:23:48 +0100 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: Message-ID: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> Greetings, The error happens the second time any of the three processes call erlang:register/2. They already registered themselves the first time. If you want this structure, but not the error, you have to do the register before starting the loop. Eg, split the functions into two. One that do the register and then calls the second that does the loop. bengt > On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya wrote: > > Hi Attila Rajmund Nohl, > > After i implement your suggestion, i get error when execute any of function call_the_*_p() > for example: > > 3> newbie:starter(). > <0.112.0> > 4> newbie:call_the_second(). > =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === > Error in process <0.113.0> with exit value: > {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, > {newbie,the_second_p,0, > [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, > {line,17}]}]} > > {<0.113.0>,"the_second_p()","Halo second p!"} > > This is my new modified code https://pastebin.com/iYCxkkuz > > > Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl > menulis: > I Gusti Ngurah Oka Prinarjaya > ezt ?rta > (id?pont: 2019. m?rc. 8., P, 12:11): > > > > Hi Folks, > > > > I need your help to review my code. I create and linking 3 process manually without using recursive. And inside p1 and p2 i using IF statement to check to make sure spawning process will only once. > > > > I mean, is part code below is a good idea? > > > > IsPidExists = whereis(xxx), > > if IsPidExists =:= undefined -> > > Pid = spawn_link(?MODULE, the_p, []), > > register(xxx, Pid); > > true -> true > > end, > > Generally this is not a good idea, there's a race condition between > checking that the process is registered (the whereis/1 call) and > registering the new process. A better idea is to start the process and > let the process itself to register. If register fails, it means that > there's already a process registered, so the just started process can > terminate. So your code could look like something like this: > > starter() -> > spawn(?MODULE, the_first_p, []). > > the_first_p() -> > register(pidfirstp, self()), > spawn_link(?MODULE, the_second_p, []), > ... > the_first_p(). > > Actually if the register call fails, it throws a badarg and the > process dies automatically, simplifying the code. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Sun Mar 10 04:57:43 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sun, 10 Mar 2019 10:57:43 +0700 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> Message-ID: Hi Bengt, Thank you for the idea, I've implement your idea, from performance side, i think using two version of function will have better performance because there's no need to checking using IF statement. I worry at first to implement this idea, because i think different version of function will have different PID, hahaha it turns out exactly have same PID. this is my new code https://pastebin.com/ECf3jhZ2 . Please review if there's any improvement needs. Thank you Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt menulis: > Greetings, > > The error happens the second time any of the three processes call > erlang:register/2. They already registered themselves the first time. If > you want this structure, but not the error, you have to do the register > before starting the loop. Eg, split the functions into two. One that do the > register and then calls the second that does the loop. > > bengt > > On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya < > okaprinarjaya@REDACTED> wrote: > > Hi Attila Rajmund Nohl, > > After i implement your suggestion, i get error when execute any of > function call_the_*_p() > for example: > > 3> newbie:starter(). > <0.112.0> > 4> newbie:call_the_second(). > =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === > Error in process <0.113.0> with exit value: > {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, > {newbie,the_second_p,0, > > [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, > {line,17}]}]} > > {<0.113.0>,"the_second_p()","Halo second p!"} > > This is my new modified code https://pastebin.com/iYCxkkuz > > > Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl < > attila.r.nohl@REDACTED> menulis: > >> I Gusti Ngurah Oka Prinarjaya ezt ?rta >> (id?pont: 2019. m?rc. 8., P, 12:11): >> > >> > Hi Folks, >> > >> > I need your help to review my code. I create and linking 3 process >> manually without using recursive. And inside p1 and p2 i using IF statement >> to check to make sure spawning process will only once. >> > >> > I mean, is part code below is a good idea? >> > >> > IsPidExists = whereis(xxx), >> > if IsPidExists =:= undefined -> >> > Pid = spawn_link(?MODULE, the_p, []), >> > register(xxx, Pid); >> > true -> true >> > end, >> >> Generally this is not a good idea, there's a race condition between >> checking that the process is registered (the whereis/1 call) and >> registering the new process. A better idea is to start the process and >> let the process itself to register. If register fails, it means that >> there's already a process registered, so the just started process can >> terminate. So your code could look like something like this: >> >> starter() -> >> spawn(?MODULE, the_first_p, []). >> >> the_first_p() -> >> register(pidfirstp, self()), >> spawn_link(?MODULE, the_second_p, []), >> ... >> the_first_p(). >> >> Actually if the register call fails, it throws a badarg and the >> process dies automatically, simplifying the code. >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cean.ebengt@REDACTED Sun Mar 10 08:48:55 2019 From: cean.ebengt@REDACTED (bengt) Date: Sun, 10 Mar 2019 08:48:55 +0100 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> Message-ID: <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> Conflating the function (or even more often, module) and the process is a common mistake in the beginning. When my fellow programmers are experienced, but not used to process oriented programming, I have found that it helps to put the code that is run in different process in different modules. Ex: one module with the interface functions to a gen_server and one module for the gen_server callbacks. Seasoned Erlang programmers will tell you this is not the OTP way, or a waste of modules. So only do this until you have a better understanding. bengt > On 10 Mar 2019, at 04:57, I Gusti Ngurah Oka Prinarjaya wrote: > > Hi Bengt, > > Thank you for the idea, > > I've implement your idea, from performance side, i think using two version of function will have better performance because there's no need to checking using IF statement. > > I worry at first to implement this idea, because i think different version of function will have different PID, hahaha it turns out exactly have same PID. > this is my new code https://pastebin.com/ECf3jhZ2 . Please review if there's any improvement needs. > > Thank you > > > > > > > > Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt > menulis: > Greetings, > > The error happens the second time any of the three processes call erlang:register/2. They already registered themselves the first time. If you want this structure, but not the error, you have to do the register before starting the loop. Eg, split the functions into two. One that do the register and then calls the second that does the loop. > > bengt > >> On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya > wrote: >> >> Hi Attila Rajmund Nohl, >> >> After i implement your suggestion, i get error when execute any of function call_the_*_p() >> for example: >> >> 3> newbie:starter(). >> <0.112.0> >> 4> newbie:call_the_second(). >> =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === >> Error in process <0.113.0> with exit value: >> {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, >> {newbie,the_second_p,0, >> [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, >> {line,17}]}]} >> >> {<0.113.0>,"the_second_p()","Halo second p!"} >> >> This is my new modified code https://pastebin.com/iYCxkkuz >> >> >> Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl > menulis: >> I Gusti Ngurah Oka Prinarjaya > ezt ?rta >> (id?pont: 2019. m?rc. 8., P, 12:11): >> > >> > Hi Folks, >> > >> > I need your help to review my code. I create and linking 3 process manually without using recursive. And inside p1 and p2 i using IF statement to check to make sure spawning process will only once. >> > >> > I mean, is part code below is a good idea? >> > >> > IsPidExists = whereis(xxx), >> > if IsPidExists =:= undefined -> >> > Pid = spawn_link(?MODULE, the_p, []), >> > register(xxx, Pid); >> > true -> true >> > end, >> >> Generally this is not a good idea, there's a race condition between >> checking that the process is registered (the whereis/1 call) and >> registering the new process. A better idea is to start the process and >> let the process itself to register. If register fails, it means that >> there's already a process registered, so the just started process can >> terminate. So your code could look like something like this: >> >> starter() -> >> spawn(?MODULE, the_first_p, []). >> >> the_first_p() -> >> register(pidfirstp, self()), >> spawn_link(?MODULE, the_second_p, []), >> ... >> the_first_p(). >> >> Actually if the register call fails, it throws a badarg and the >> process dies automatically, simplifying the code. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Sun Mar 10 11:11:58 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sun, 10 Mar 2019 17:11:58 +0700 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> Message-ID: Hi Bengt, Thank you for your review :) I don't quite understand with some of your thought. Then i hope you not mind to give more explanation. >> Seasoned Erlang programmers will tell you this is not the OTP way, or a waste of modules Did you mean my code here: https://pastebin.com/ECf3jhZ2 wasn't the OTP way? I learn from here: https://learnyousomeerlang.com/errors-and-processes and i do really a beginner at programming with erlang. >> So only do this until you have a better understanding. What is that? Did you mean *doing one module with the interface functions to a gen_server and one module for the gen_server callbacks.?* or what? >> Conflating the function (or even more often, module) and the process is a common mistake in the beginning. When my fellow programmers are experienced, but not used >> to process oriented programming. Any tutorials / reference for me to avoid this mistake ? Thank you :) Pada tanggal Min, 10 Mar 2019 pukul 14.49 bengt menulis: > Conflating the function (or even more often, module) and the process is a > common mistake in the beginning. When my fellow programmers are > experienced, but not used to process oriented programming, I have found > that it helps to put the code that is run in different process in different > modules. Ex: one module with the interface functions to a gen_server and > one module for the gen_server callbacks. Seasoned Erlang programmers will > tell you this is not the OTP way, or a waste of modules. So only do this > until you have a better understanding. > > bengt > > On 10 Mar 2019, at 04:57, I Gusti Ngurah Oka Prinarjaya < > okaprinarjaya@REDACTED> wrote: > > Hi Bengt, > > Thank you for the idea, > > I've implement your idea, from performance side, i think using two version > of function will have better performance because there's no need to > checking using IF statement. > > I worry at first to implement this idea, because i think different version > of function will have different PID, hahaha it turns out exactly have same > PID. > this is my new code https://pastebin.com/ECf3jhZ2 . Please review if > there's any improvement needs. > > Thank you > > > > > > > > Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt > menulis: > >> Greetings, >> >> The error happens the second time any of the three processes call >> erlang:register/2. They already registered themselves the first time. If >> you want this structure, but not the error, you have to do the register >> before starting the loop. Eg, split the functions into two. One that do the >> register and then calls the second that does the loop. >> >> bengt >> >> On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya < >> okaprinarjaya@REDACTED> wrote: >> >> Hi Attila Rajmund Nohl, >> >> After i implement your suggestion, i get error when execute any of >> function call_the_*_p() >> for example: >> >> 3> newbie:starter(). >> <0.112.0> >> 4> newbie:call_the_second(). >> =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === >> Error in process <0.113.0> with exit value: >> {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, >> {newbie,the_second_p,0, >> >> [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, >> {line,17}]}]} >> >> {<0.113.0>,"the_second_p()","Halo second p!"} >> >> This is my new modified code https://pastebin.com/iYCxkkuz >> >> >> Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl < >> attila.r.nohl@REDACTED> menulis: >> >>> I Gusti Ngurah Oka Prinarjaya ezt ?rta >>> (id?pont: 2019. m?rc. 8., P, 12:11): >>> > >>> > Hi Folks, >>> > >>> > I need your help to review my code. I create and linking 3 process >>> manually without using recursive. And inside p1 and p2 i using IF statement >>> to check to make sure spawning process will only once. >>> > >>> > I mean, is part code below is a good idea? >>> > >>> > IsPidExists = whereis(xxx), >>> > if IsPidExists =:= undefined -> >>> > Pid = spawn_link(?MODULE, the_p, []), >>> > register(xxx, Pid); >>> > true -> true >>> > end, >>> >>> Generally this is not a good idea, there's a race condition between >>> checking that the process is registered (the whereis/1 call) and >>> registering the new process. A better idea is to start the process and >>> let the process itself to register. If register fails, it means that >>> there's already a process registered, so the just started process can >>> terminate. So your code could look like something like this: >>> >>> starter() -> >>> spawn(?MODULE, the_first_p, []). >>> >>> the_first_p() -> >>> register(pidfirstp, self()), >>> spawn_link(?MODULE, the_second_p, []), >>> ... >>> the_first_p(). >>> >>> Actually if the register call fails, it throws a badarg and the >>> process dies automatically, simplifying the code. >>> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hansihe@REDACTED Sun Mar 10 13:43:51 2019 From: hansihe@REDACTED (Hans Elias B. Josephsen) Date: Sun, 10 Mar 2019 08:43:51 -0400 Subject: [erlang-questions] Getting object code for module in on_init Message-ID: I am trying to get the object code for a module while inside the `on_init` function of that module. Normally I would use `code:get_object_code(Module)`, but it seems like the .beam file might not have been written to disk yet at that point. Yet, code in that module is running, so it must be located somewhere. Is there any way to get the object code of the module itself while in that stage? From christopher.meiklejohn@REDACTED Sun Mar 10 18:02:18 2019 From: christopher.meiklejohn@REDACTED (Christopher Meiklejohn) Date: Sun, 10 Mar 2019 13:02:18 -0400 Subject: [erlang-questions] Core Erlang: Associating Function Names to Function Bodies Message-ID: As part of a static analysis I'm writing, I'm trying to associate function names with their function bodies so I can provide information about the calling functions to users as part of the completed analysis. However, I'm running into difficulty performing this mapping. The problem I'm running into is the following: 1.) In the Core Erlang AST, named functions are defined by associating a c_var node in the form of {Function, Arity} to a subtree containing the c_fun function body. 2.) Also, in the Core Erlang AST, calls to functions are also represented as c_var nodes in the form of {Function, Arity}. The cerl_trees:fold, mapfold all perform postorder traversals. With a postorder traversal, there may be an arbitrary distance in the fold between when a function is defined and where it is given a name. With reverse postorder, my understanding is that these nodes would be directly next to each other, which would make the mapping easier. My initial approach was to attempt to, when a c_var node was found in the proper form, store a candidate name for the next function that's found and perform the association that way. The problem that arises from this approach is that there can be an arbitrary number of c_var nodes for function invocations between the definition of the function and it's actual body. The same can also happen for any functions that occur in between as well. Therefore, my analysis incorrectly associates function bodies to function names for any function that calls another function in the body -- incorrectly thinking that the nearest c_var node containing a function name is it's associated name. I assume this must have been done for a previous analysis performed on Erlang, but I haven't found anything. Would a reverse postorder traversal make this easier? Is there a better way to identify the mapping between c_var nodes and c_funs that are being assigned to them? Has this been done before? Thanks for the advice, Christopher From cean.ebengt@REDACTED Sun Mar 10 23:20:28 2019 From: cean.ebengt@REDACTED (bengt) Date: Sun, 10 Mar 2019 23:20:28 +0100 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> Message-ID: I think your code is about learning erlang. Do that first. OTP is the next step. Yes, splitting a gen_server into callback module and interface module is not the OTP way (as described in documentation), so while good for a beginner it can be considered bad style by experienced programmers. Sorry, but I have not seen any tutorial about how to avoid thinking the same function/module is always in the same process. It is a very fundamental concept (them not being) in Erlang, so just keep it in mind. One way would be to try and make all your three functions the same function, just have different arguments to the loop. Then you must think about it. > On 10 Mar 2019, at 11:11, I Gusti Ngurah Oka Prinarjaya wrote: > > Hi Bengt, > > Thank you for your review :) > > I don't quite understand with some of your thought. Then i hope you not mind to give more explanation. > > >> Seasoned Erlang programmers will tell you this is not the OTP way, or a waste of modules > Did you mean my code here: https://pastebin.com/ECf3jhZ2 wasn't the OTP way? > I learn from here: https://learnyousomeerlang.com/errors-and-processes and i do really a beginner at programming with erlang. > > >> So only do this until you have a better understanding. > What is that? Did you mean doing one module with the interface functions to a gen_server and one module for the gen_server callbacks.? > or what? > > >> Conflating the function (or even more often, module) and the process is a common mistake in the beginning. When my fellow programmers are experienced, but not used >> to process oriented programming. > Any tutorials / reference for me to avoid this mistake ? > > Thank you :) > > > > > > > > > Pada tanggal Min, 10 Mar 2019 pukul 14.49 bengt > menulis: > Conflating the function (or even more often, module) and the process is a common mistake in the beginning. When my fellow programmers are experienced, but not used to process oriented programming, I have found that it helps to put the code that is run in different process in different modules. Ex: one module with the interface functions to a gen_server and one module for the gen_server callbacks. Seasoned Erlang programmers will tell you this is not the OTP way, or a waste of modules. So only do this until you have a better understanding. > > bengt > >> On 10 Mar 2019, at 04:57, I Gusti Ngurah Oka Prinarjaya > wrote: >> >> Hi Bengt, >> >> Thank you for the idea, >> >> I've implement your idea, from performance side, i think using two version of function will have better performance because there's no need to checking using IF statement. >> >> I worry at first to implement this idea, because i think different version of function will have different PID, hahaha it turns out exactly have same PID. >> this is my new code https://pastebin.com/ECf3jhZ2 . Please review if there's any improvement needs. >> >> Thank you >> >> >> >> >> >> >> >> Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt > menulis: >> Greetings, >> >> The error happens the second time any of the three processes call erlang:register/2. They already registered themselves the first time. If you want this structure, but not the error, you have to do the register before starting the loop. Eg, split the functions into two. One that do the register and then calls the second that does the loop. >> >> bengt >> >>> On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya > wrote: >>> >>> Hi Attila Rajmund Nohl, >>> >>> After i implement your suggestion, i get error when execute any of function call_the_*_p() >>> for example: >>> >>> 3> newbie:starter(). >>> <0.112.0> >>> 4> newbie:call_the_second(). >>> =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === >>> Error in process <0.113.0> with exit value: >>> {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, >>> {newbie,the_second_p,0, >>> [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, >>> {line,17}]}]} >>> >>> {<0.113.0>,"the_second_p()","Halo second p!"} >>> >>> This is my new modified code https://pastebin.com/iYCxkkuz >>> >>> >>> Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl > menulis: >>> I Gusti Ngurah Oka Prinarjaya > ezt ?rta >>> (id?pont: 2019. m?rc. 8., P, 12:11): >>> > >>> > Hi Folks, >>> > >>> > I need your help to review my code. I create and linking 3 process manually without using recursive. And inside p1 and p2 i using IF statement to check to make sure spawning process will only once. >>> > >>> > I mean, is part code below is a good idea? >>> > >>> > IsPidExists = whereis(xxx), >>> > if IsPidExists =:= undefined -> >>> > Pid = spawn_link(?MODULE, the_p, []), >>> > register(xxx, Pid); >>> > true -> true >>> > end, >>> >>> Generally this is not a good idea, there's a race condition between >>> checking that the process is registered (the whereis/1 call) and >>> registering the new process. A better idea is to start the process and >>> let the process itself to register. If register fails, it means that >>> there's already a process registered, so the just started process can >>> terminate. So your code could look like something like this: >>> >>> starter() -> >>> spawn(?MODULE, the_first_p, []). >>> >>> the_first_p() -> >>> register(pidfirstp, self()), >>> spawn_link(?MODULE, the_second_p, []), >>> ... >>> the_first_p(). >>> >>> Actually if the register call fails, it throws a badarg and the >>> process dies automatically, simplifying the code. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Sun Mar 10 23:38:21 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Mon, 11 Mar 2019 05:38:21 +0700 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> Message-ID: Hi Bengt, Thank you very much for all of your hints and suggestions. It's clear now. Pada tanggal Sen, 11 Mar 2019 05.20, bengt menulis: > I think your code is about learning erlang. Do that first. OTP is the next > step. > > Yes, splitting a gen_server into callback module and interface module is > not the OTP way (as described in documentation), so while good for a > beginner it can be considered bad style by experienced programmers. > > Sorry, but I have not seen any tutorial about how to avoid thinking the > same function/module is always in the same process. It is a very > fundamental concept (them not being) in Erlang, so just keep it in mind. > One way would be to try and make all your three functions the same > function, just have different arguments to the loop. Then you must think > about it. > > > On 10 Mar 2019, at 11:11, I Gusti Ngurah Oka Prinarjaya < > okaprinarjaya@REDACTED> wrote: > > Hi Bengt, > > Thank you for your review :) > > I don't quite understand with some of your thought. Then i hope you not > mind to give more explanation. > > >> Seasoned Erlang programmers will tell you this is not the OTP way, or a > waste of modules > Did you mean my code here: https://pastebin.com/ECf3jhZ2 wasn't the OTP > way? > I learn from here: https://learnyousomeerlang.com/errors-and-processes > and i do really a beginner at programming with erlang. > > >> So only do this until you have a better understanding. > What is that? Did you mean *doing one module with the interface functions > to a gen_server and one module for the gen_server callbacks.?* > or what? > > >> Conflating the function (or even more often, module) and the process is > a common mistake in the beginning. When my fellow programmers are > experienced, but not used >> to process oriented programming. > Any tutorials / reference for me to avoid this mistake ? > > Thank you :) > > > > > > > > > Pada tanggal Min, 10 Mar 2019 pukul 14.49 bengt > menulis: > >> Conflating the function (or even more often, module) and the process is a >> common mistake in the beginning. When my fellow programmers are >> experienced, but not used to process oriented programming, I have found >> that it helps to put the code that is run in different process in different >> modules. Ex: one module with the interface functions to a gen_server and >> one module for the gen_server callbacks. Seasoned Erlang programmers will >> tell you this is not the OTP way, or a waste of modules. So only do this >> until you have a better understanding. >> >> bengt >> >> On 10 Mar 2019, at 04:57, I Gusti Ngurah Oka Prinarjaya < >> okaprinarjaya@REDACTED> wrote: >> >> Hi Bengt, >> >> Thank you for the idea, >> >> I've implement your idea, from performance side, i think using two >> version of function will have better performance because there's no need to >> checking using IF statement. >> >> I worry at first to implement this idea, because i think different >> version of function will have different PID, hahaha it turns out exactly >> have same PID. >> this is my new code https://pastebin.com/ECf3jhZ2 . Please review if >> there's any improvement needs. >> >> Thank you >> >> >> >> >> >> >> >> Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt >> menulis: >> >>> Greetings, >>> >>> The error happens the second time any of the three processes call >>> erlang:register/2. They already registered themselves the first time. If >>> you want this structure, but not the error, you have to do the register >>> before starting the loop. Eg, split the functions into two. One that do the >>> register and then calls the second that does the loop. >>> >>> bengt >>> >>> On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya < >>> okaprinarjaya@REDACTED> wrote: >>> >>> Hi Attila Rajmund Nohl, >>> >>> After i implement your suggestion, i get error when execute any of >>> function call_the_*_p() >>> for example: >>> >>> 3> newbie:starter(). >>> <0.112.0> >>> 4> newbie:call_the_second(). >>> =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === >>> Error in process <0.113.0> with exit value: >>> {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, >>> {newbie,the_second_p,0, >>> >>> [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, >>> {line,17}]}]} >>> >>> {<0.113.0>,"the_second_p()","Halo second p!"} >>> >>> This is my new modified code https://pastebin.com/iYCxkkuz >>> >>> >>> Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl < >>> attila.r.nohl@REDACTED> menulis: >>> >>>> I Gusti Ngurah Oka Prinarjaya ezt ?rta >>>> (id?pont: 2019. m?rc. 8., P, 12:11): >>>> > >>>> > Hi Folks, >>>> > >>>> > I need your help to review my code. I create and linking 3 process >>>> manually without using recursive. And inside p1 and p2 i using IF statement >>>> to check to make sure spawning process will only once. >>>> > >>>> > I mean, is part code below is a good idea? >>>> > >>>> > IsPidExists = whereis(xxx), >>>> > if IsPidExists =:= undefined -> >>>> > Pid = spawn_link(?MODULE, the_p, []), >>>> > register(xxx, Pid); >>>> > true -> true >>>> > end, >>>> >>>> Generally this is not a good idea, there's a race condition between >>>> checking that the process is registered (the whereis/1 call) and >>>> registering the new process. A better idea is to start the process and >>>> let the process itself to register. If register fails, it means that >>>> there's already a process registered, so the just started process can >>>> terminate. So your code could look like something like this: >>>> >>>> starter() -> >>>> spawn(?MODULE, the_first_p, []). >>>> >>>> the_first_p() -> >>>> register(pidfirstp, self()), >>>> spawn_link(?MODULE, the_second_p, []), >>>> ... >>>> the_first_p(). >>>> >>>> Actually if the register call fails, it throws a badarg and the >>>> process dies automatically, simplifying the code. >>>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Mon Mar 11 06:04:38 2019 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 11 Mar 2019 06:04:38 +0100 Subject: [erlang-questions] Getting object code for module in on_init In-Reply-To: References: Message-ID: On Sun, Mar 10, 2019 at 3:40 PM Hans Elias B. Josephsen wrote: > > I am trying to get the object code for a module while inside the `on_init` function of that module. Do you mean an `on_load` function? > Normally I would use `code:get_object_code(Module)`, but it seems like the .beam file might not have been written to disk yet at that point. Works fine for me from an `on_load` function. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From andreas.schultz@REDACTED Mon Mar 11 08:55:28 2019 From: andreas.schultz@REDACTED (Andreas Schultz) Date: Mon, 11 Mar 2019 08:55:28 +0100 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> Message-ID: You do realize that your code is still "racy" ? Invoking it like 2> procslinked:starter(), procslinked:call_the_third(). has a good chance of not producing the expected result. Most times it will simply fail with: ** exception error: bad argument in function procslinked:call_the_third/0 (procslinked.erl, line 54) The reason is that there is no guarantee that `call_the_third()` will be executed after any of the spawn has succeeded or the register was invoked. In order to get ordering guarantees you need to wait for the processes to be past the init stage. The normal way to do that is to wait for a message from the init function of you child process. BTW: this is exactly what proc_lib:init_ack does, but I guess you are trying to implement that yourself as a learning exercise. Andreas I Gusti Ngurah Oka Prinarjaya schrieb am So., 10. M?rz 2019 um 23:38 Uhr: > Hi Bengt, > > Thank you very much for all of your hints and suggestions. It's clear now. > > > > Pada tanggal Sen, 11 Mar 2019 05.20, bengt > menulis: > >> I think your code is about learning erlang. Do that first. OTP is the >> next step. >> >> Yes, splitting a gen_server into callback module and interface module is >> not the OTP way (as described in documentation), so while good for a >> beginner it can be considered bad style by experienced programmers. >> >> Sorry, but I have not seen any tutorial about how to avoid thinking the >> same function/module is always in the same process. It is a very >> fundamental concept (them not being) in Erlang, so just keep it in mind. >> One way would be to try and make all your three functions the same >> function, just have different arguments to the loop. Then you must think >> about it. >> >> >> On 10 Mar 2019, at 11:11, I Gusti Ngurah Oka Prinarjaya < >> okaprinarjaya@REDACTED> wrote: >> >> Hi Bengt, >> >> Thank you for your review :) >> >> I don't quite understand with some of your thought. Then i hope you not >> mind to give more explanation. >> >> >> Seasoned Erlang programmers will tell you this is not the OTP way, or >> a waste of modules >> Did you mean my code here: https://pastebin.com/ECf3jhZ2 wasn't the OTP >> way? >> I learn from here: https://learnyousomeerlang.com/errors-and-processes >> and i do really a beginner at programming with erlang. >> >> >> So only do this until you have a better understanding. >> What is that? Did you mean *doing one module with the interface >> functions to a gen_server and one module for the gen_server callbacks.?* >> or what? >> >> >> Conflating the function (or even more often, module) and the process >> is a common mistake in the beginning. When my fellow programmers are >> experienced, but not used >> to process oriented programming. >> Any tutorials / reference for me to avoid this mistake ? >> >> Thank you :) >> >> >> >> >> >> >> >> >> Pada tanggal Min, 10 Mar 2019 pukul 14.49 bengt >> menulis: >> >>> Conflating the function (or even more often, module) and the process is >>> a common mistake in the beginning. When my fellow programmers are >>> experienced, but not used to process oriented programming, I have found >>> that it helps to put the code that is run in different process in different >>> modules. Ex: one module with the interface functions to a gen_server and >>> one module for the gen_server callbacks. Seasoned Erlang programmers will >>> tell you this is not the OTP way, or a waste of modules. So only do this >>> until you have a better understanding. >>> >>> bengt >>> >>> On 10 Mar 2019, at 04:57, I Gusti Ngurah Oka Prinarjaya < >>> okaprinarjaya@REDACTED> wrote: >>> >>> Hi Bengt, >>> >>> Thank you for the idea, >>> >>> I've implement your idea, from performance side, i think using two >>> version of function will have better performance because there's no need to >>> checking using IF statement. >>> >>> I worry at first to implement this idea, because i think different >>> version of function will have different PID, hahaha it turns out exactly >>> have same PID. >>> this is my new code https://pastebin.com/ECf3jhZ2 . Please review if >>> there's any improvement needs. >>> >>> Thank you >>> >>> >>> >>> >>> >>> >>> >>> Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt >>> menulis: >>> >>>> Greetings, >>>> >>>> The error happens the second time any of the three processes call >>>> erlang:register/2. They already registered themselves the first time. If >>>> you want this structure, but not the error, you have to do the register >>>> before starting the loop. Eg, split the functions into two. One that do the >>>> register and then calls the second that does the loop. >>>> >>>> bengt >>>> >>>> On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya < >>>> okaprinarjaya@REDACTED> wrote: >>>> >>>> Hi Attila Rajmund Nohl, >>>> >>>> After i implement your suggestion, i get error when execute any of >>>> function call_the_*_p() >>>> for example: >>>> >>>> 3> newbie:starter(). >>>> <0.112.0> >>>> 4> newbie:call_the_second(). >>>> =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === >>>> Error in process <0.113.0> with exit value: >>>> {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, >>>> {newbie,the_second_p,0, >>>> >>>> [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, >>>> {line,17}]}]} >>>> >>>> {<0.113.0>,"the_second_p()","Halo second p!"} >>>> >>>> This is my new modified code https://pastebin.com/iYCxkkuz >>>> >>>> >>>> Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl < >>>> attila.r.nohl@REDACTED> menulis: >>>> >>>>> I Gusti Ngurah Oka Prinarjaya ezt ?rta >>>>> (id?pont: 2019. m?rc. 8., P, 12:11): >>>>> > >>>>> > Hi Folks, >>>>> > >>>>> > I need your help to review my code. I create and linking 3 process >>>>> manually without using recursive. And inside p1 and p2 i using IF statement >>>>> to check to make sure spawning process will only once. >>>>> > >>>>> > I mean, is part code below is a good idea? >>>>> > >>>>> > IsPidExists = whereis(xxx), >>>>> > if IsPidExists =:= undefined -> >>>>> > Pid = spawn_link(?MODULE, the_p, []), >>>>> > register(xxx, Pid); >>>>> > true -> true >>>>> > end, >>>>> >>>>> Generally this is not a good idea, there's a race condition between >>>>> checking that the process is registered (the whereis/1 call) and >>>>> registering the new process. A better idea is to start the process and >>>>> let the process itself to register. If register fails, it means that >>>>> there's already a process registered, so the just started process can >>>>> terminate. So your code could look like something like this: >>>>> >>>>> starter() -> >>>>> spawn(?MODULE, the_first_p, []). >>>>> >>>>> the_first_p() -> >>>>> register(pidfirstp, self()), >>>>> spawn_link(?MODULE, the_second_p, []), >>>>> ... >>>>> the_first_p(). >>>>> >>>>> Actually if the register call fails, it throws a badarg and the >>>>> process dies automatically, simplifying the code. >>>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl.-Inform. Andreas Schultz ----------------------- enabling your networks ---------------------- Travelping GmbH Phone: +49-391-81 90 99 0 Roentgenstr. 13 Fax: +49-391-81 90 99 299 39108 Magdeburg Email: info@REDACTED GERMANY Web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Mon Mar 11 12:03:19 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Mon, 11 Mar 2019 18:03:19 +0700 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> Message-ID: Hi Andreas Schultz, >> The reason is that there is no guarantee that `call_the_third()` will be executed after any of the spawn has succeeded or the register was invoked. 1. Did you mean this code? https://pastebin.com/ECf3jhZ2 2. and did you mean spawn_link/3 and register/2 is racy? 3. I've test this code many times, and never get error in each call_the_* function, even call_the_third/0 function. Here: https://learnyousomeerlang.com/the-hitchhikers-guide-to-concurrency, and here: https://learnyousomeerlang.com/more-on-multiprocessing and here: https://learnyousomeerlang.com/errors-and-processes teach me to do that. Oh My God, where in this earth i can read the best erlang process tutorial ? so i can use erlang in the right way. >> In order to get ordering guarantees you need to wait for the processes to be past the init stage. >> The normal way to do that is to wait for a message from the init function of you child process. Please give me a short pseudo-code clue to do this. I do really shocked because of this code: https://pastebin.com/ECf3jhZ2 still not correct after 2 times revision. Thank you :) Pada tanggal Sen, 11 Mar 2019 pukul 14.55 Andreas Schultz < andreas.schultz@REDACTED> menulis: > You do realize that your code is still "racy" ? > > Invoking it like > > 2> procslinked:starter(), procslinked:call_the_third(). > > has a good chance of not producing the expected result. Most times it will > simply fail with: > > ** exception error: bad argument > in function procslinked:call_the_third/0 (procslinked.erl, line > 54) > > The reason is that there is no guarantee that `call_the_third()` will be > executed after any of the spawn has succeeded or the register was invoked. > In order to get ordering guarantees you need to wait for the processes to > be past the init stage. The normal way to do that is to wait for a message > from the init function of you child process. > > BTW: this is exactly what proc_lib:init_ack does, but I guess you are > trying to implement that yourself as a learning exercise. > > Andreas > > I Gusti Ngurah Oka Prinarjaya schrieb am So., > 10. M?rz 2019 um 23:38 Uhr: > >> Hi Bengt, >> >> Thank you very much for all of your hints and suggestions. It's clear >> now. >> >> >> >> Pada tanggal Sen, 11 Mar 2019 05.20, bengt >> menulis: >> >>> I think your code is about learning erlang. Do that first. OTP is the >>> next step. >>> >>> Yes, splitting a gen_server into callback module and interface module is >>> not the OTP way (as described in documentation), so while good for a >>> beginner it can be considered bad style by experienced programmers. >>> >>> Sorry, but I have not seen any tutorial about how to avoid thinking the >>> same function/module is always in the same process. It is a very >>> fundamental concept (them not being) in Erlang, so just keep it in mind. >>> One way would be to try and make all your three functions the same >>> function, just have different arguments to the loop. Then you must think >>> about it. >>> >>> >>> On 10 Mar 2019, at 11:11, I Gusti Ngurah Oka Prinarjaya < >>> okaprinarjaya@REDACTED> wrote: >>> >>> Hi Bengt, >>> >>> Thank you for your review :) >>> >>> I don't quite understand with some of your thought. Then i hope you not >>> mind to give more explanation. >>> >>> >> Seasoned Erlang programmers will tell you this is not the OTP way, or >>> a waste of modules >>> Did you mean my code here: https://pastebin.com/ECf3jhZ2 wasn't the OTP >>> way? >>> I learn from here: https://learnyousomeerlang.com/errors-and-processes >>> and i do really a beginner at programming with erlang. >>> >>> >> So only do this until you have a better understanding. >>> What is that? Did you mean *doing one module with the interface >>> functions to a gen_server and one module for the gen_server callbacks.?* >>> or what? >>> >>> >> Conflating the function (or even more often, module) and the process >>> is a common mistake in the beginning. When my fellow programmers are >>> experienced, but not used >> to process oriented programming. >>> Any tutorials / reference for me to avoid this mistake ? >>> >>> Thank you :) >>> >>> >>> >>> >>> >>> >>> >>> >>> Pada tanggal Min, 10 Mar 2019 pukul 14.49 bengt >>> menulis: >>> >>>> Conflating the function (or even more often, module) and the process is >>>> a common mistake in the beginning. When my fellow programmers are >>>> experienced, but not used to process oriented programming, I have found >>>> that it helps to put the code that is run in different process in different >>>> modules. Ex: one module with the interface functions to a gen_server and >>>> one module for the gen_server callbacks. Seasoned Erlang programmers will >>>> tell you this is not the OTP way, or a waste of modules. So only do this >>>> until you have a better understanding. >>>> >>>> bengt >>>> >>>> On 10 Mar 2019, at 04:57, I Gusti Ngurah Oka Prinarjaya < >>>> okaprinarjaya@REDACTED> wrote: >>>> >>>> Hi Bengt, >>>> >>>> Thank you for the idea, >>>> >>>> I've implement your idea, from performance side, i think using two >>>> version of function will have better performance because there's no need to >>>> checking using IF statement. >>>> >>>> I worry at first to implement this idea, because i think different >>>> version of function will have different PID, hahaha it turns out exactly >>>> have same PID. >>>> this is my new code https://pastebin.com/ECf3jhZ2 . Please review if >>>> there's any improvement needs. >>>> >>>> Thank you >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt >>>> menulis: >>>> >>>>> Greetings, >>>>> >>>>> The error happens the second time any of the three processes call >>>>> erlang:register/2. They already registered themselves the first time. If >>>>> you want this structure, but not the error, you have to do the register >>>>> before starting the loop. Eg, split the functions into two. One that do the >>>>> register and then calls the second that does the loop. >>>>> >>>>> bengt >>>>> >>>>> On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya < >>>>> okaprinarjaya@REDACTED> wrote: >>>>> >>>>> Hi Attila Rajmund Nohl, >>>>> >>>>> After i implement your suggestion, i get error when execute any of >>>>> function call_the_*_p() >>>>> for example: >>>>> >>>>> 3> newbie:starter(). >>>>> <0.112.0> >>>>> 4> newbie:call_the_second(). >>>>> =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === >>>>> Error in process <0.113.0> with exit value: >>>>> {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, >>>>> {newbie,the_second_p,0, >>>>> >>>>> [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, >>>>> {line,17}]}]} >>>>> >>>>> {<0.113.0>,"the_second_p()","Halo second p!"} >>>>> >>>>> This is my new modified code https://pastebin.com/iYCxkkuz >>>>> >>>>> >>>>> Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl < >>>>> attila.r.nohl@REDACTED> menulis: >>>>> >>>>>> I Gusti Ngurah Oka Prinarjaya ezt ?rta >>>>>> (id?pont: 2019. m?rc. 8., P, 12:11): >>>>>> > >>>>>> > Hi Folks, >>>>>> > >>>>>> > I need your help to review my code. I create and linking 3 process >>>>>> manually without using recursive. And inside p1 and p2 i using IF statement >>>>>> to check to make sure spawning process will only once. >>>>>> > >>>>>> > I mean, is part code below is a good idea? >>>>>> > >>>>>> > IsPidExists = whereis(xxx), >>>>>> > if IsPidExists =:= undefined -> >>>>>> > Pid = spawn_link(?MODULE, the_p, []), >>>>>> > register(xxx, Pid); >>>>>> > true -> true >>>>>> > end, >>>>>> >>>>>> Generally this is not a good idea, there's a race condition between >>>>>> checking that the process is registered (the whereis/1 call) and >>>>>> registering the new process. A better idea is to start the process and >>>>>> let the process itself to register. If register fails, it means that >>>>>> there's already a process registered, so the just started process can >>>>>> terminate. So your code could look like something like this: >>>>>> >>>>>> starter() -> >>>>>> spawn(?MODULE, the_first_p, []). >>>>>> >>>>>> the_first_p() -> >>>>>> register(pidfirstp, self()), >>>>>> spawn_link(?MODULE, the_second_p, []), >>>>>> ... >>>>>> the_first_p(). >>>>>> >>>>>> Actually if the register call fails, it throws a badarg and the >>>>>> process dies automatically, simplifying the code. >>>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- > -- > Dipl.-Inform. Andreas Schultz > > ----------------------- enabling your networks ---------------------- > Travelping GmbH Phone: +49-391-81 90 99 0 > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > 39108 Magdeburg Email: info@REDACTED > GERMANY Web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > --------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.meiklejohn@REDACTED Mon Mar 11 15:49:27 2019 From: christopher.meiklejohn@REDACTED (Christopher Meiklejohn) Date: Mon, 11 Mar 2019 10:49:27 -0400 Subject: [erlang-questions] Core Erlang: Associating Function Names to Function Bodies In-Reply-To: References: Message-ID: On Sun, Mar 10, 2019 at 1:02 PM Christopher Meiklejohn wrote: > > As part of a static analysis I'm writing, I'm trying to associate > function names with their function bodies so I can provide information > about the calling functions to users as part of the completed > analysis. However, I'm running into difficulty performing this > mapping. > > The problem I'm running into is the following: > > 1.) In the Core Erlang AST, named functions are defined by associating > a c_var node in the form of {Function, Arity} to a subtree containing > the c_fun function body. > 2.) Also, in the Core Erlang AST, calls to functions are also > represented as c_var nodes in the form of {Function, Arity}. > > The cerl_trees:fold, mapfold all perform postorder traversals. With a > postorder traversal, there may be an arbitrary distance in the fold > between when a function is defined and where it is given a name. With > reverse postorder, my understanding is that these nodes would be > directly next to each other, which would make the mapping easier. > > My initial approach was to attempt to, when a c_var node was found in > the proper form, store a candidate name for the next function that's > found and perform the association that way. The problem that arises > from this approach is that there can be an arbitrary number of c_var > nodes for function invocations between the definition of the function > and it's actual body. The same can also happen for any functions that > occur in between as well. > > Therefore, my analysis incorrectly associates function bodies to > function names for any function that calls another function in the > body -- incorrectly thinking that the nearest c_var node containing a > function name is it's associated name. > > I assume this must have been done for a previous analysis performed on > Erlang, but I haven't found anything. Would a reverse postorder > traversal make this easier? Is there a better way to identify the > mapping between c_var nodes and c_funs that are being assigned to > them? Has this been done before? Just for those who are interested, I did figure out one solution to the problem which I have tried out on several models now that appears to be working so far. Here's the rough outline of my currently-working solution: Since there is no node directly connecting the c_var of a variable assignment along with the body of the function, I had to perform a traversal where I try to match function bodies that I find along with the variables they are being assigned to. To do this, I did the following: 1.) I first use cerl_trees:fold to perform a postorder traversal of the tree, building up a list of nodes to explore. 2.) I then lists:foldr over this, allowing me to perform effectively a reverse postorder traversal of the graph, where, I will encounter function bodies (c_fun) prior to encountering function variables. (c_var) 3.) I perform an analysis that allows me to match up names to bodies using the following heuristic: a.) Whenever I encounter a function body, I can determine from the node whether or not the function body is the body of an anonymous function or not. Anonymous functions are annotated with a randomly assigned label which includes the enclosing function and the line where the anonymous function was generated. This allows me to rule out the top-level functions from functions that are created from within a top-level function. When I discover one of these functions, I keep track of this in a candidate list of potential function body matches for the function variable I am assigning to. b.) Whenever I encounter a c_var in the form of {Function, Arity}, I know that I'm dealing with an application or an assignment. (Curiously, why is there not a node that directly associates the c_var to the c_fun -- this would have made things *significantly* easier, but does not exist in the Core Erlang when performing a traversal via cerl_trees.) If the function contains an annotation containing a line number of invocation, then I know it's the *application* of this function, and not the *abstraction* of this function. (Again, why does c_var treat LHS assignments the same as RHS use of the function -- if this was more specific, it would have again, made things *significantly* easier.) If I'm looking for a candidate match between body and function variable, then I perform a match based on this. c.) Otherwise, either the c_var is the use of a function or the c_fun is the creation of an anonymous function, and it's subsequently ignored by the matching procedure. On the 'analysis' branch of this, I have a prototype of this implementation that I've tested on several modules that appears to be working. If this could have been done a different, easier way, I'd appreciate knowing about it. Thanks, Christopher From cean.ebengt@REDACTED Mon Mar 11 20:13:06 2019 From: cean.ebengt@REDACTED (bengt) Date: Mon, 11 Mar 2019 20:13:06 +0100 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> Message-ID: <3463DD52-1024-4F4B-AE0E-41BF648A0783@gmail.com> Greetings, The race is that starter/0 will return before any of the three processes have started. If you add a timer:sleep( 60000 ) before the calls to register/0 you will see this even if you do call_the_first/0 manually. The pseudo code would be My_pid = erlang:self(), P = spawn(?MODULE, the_first_p, [My_pid]), receive {P, init_done} -> ok end. And then sending {erlang:self(), init_done} to My_pid (the process that started the_first_p). > On 11 Mar 2019, at 12:03, I Gusti Ngurah Oka Prinarjaya wrote: > > Hi Andreas Schultz, > > >> The reason is that there is no guarantee that `call_the_third()` will be executed after any of the spawn has succeeded or the register was invoked. > 1. Did you mean this code? https://pastebin.com/ECf3jhZ2 > 2. and did you mean spawn_link/3 and register/2 is racy? > 3. I've test this code many times, and never get error in each call_the_* function, even call_the_third/0 function. > > Here: https://learnyousomeerlang.com/the-hitchhikers-guide-to-concurrency , and here: https://learnyousomeerlang.com/more-on-multiprocessing and > here: https://learnyousomeerlang.com/errors-and-processes teach me to do that. Oh My God, where in this earth i can read the best erlang process tutorial ? so i can use erlang in the right way. > > >> In order to get ordering guarantees you need to wait for the processes to be past the init stage. > >> The normal way to do that is to wait for a message from the init function of you child process. > Please give me a short pseudo-code clue to do this. I do really shocked because of this code: https://pastebin.com/ECf3jhZ2 still not correct after 2 times revision. > > Thank you :) > > > > Pada tanggal Sen, 11 Mar 2019 pukul 14.55 Andreas Schultz > menulis: > You do realize that your code is still "racy" ? > > Invoking it like > > 2> procslinked:starter(), procslinked:call_the_third(). > > has a good chance of not producing the expected result. Most times it will simply fail with: > > ** exception error: bad argument > in function procslinked:call_the_third/0 (procslinked.erl, line 54) > > The reason is that there is no guarantee that `call_the_third()` will be executed after any of the spawn has succeeded or the register was invoked. > In order to get ordering guarantees you need to wait for the processes to be past the init stage. The normal way to do that is to wait for a message from the init function of you child process. > > BTW: this is exactly what proc_lib:init_ack does, but I guess you are trying to implement that yourself as a learning exercise. > > Andreas > > I Gusti Ngurah Oka Prinarjaya > schrieb am So., 10. M?rz 2019 um 23:38 Uhr: > Hi Bengt, > > Thank you very much for all of your hints and suggestions. It's clear now. > > > > Pada tanggal Sen, 11 Mar 2019 05.20, bengt > menulis: > I think your code is about learning erlang. Do that first. OTP is the next step. > > Yes, splitting a gen_server into callback module and interface module is not the OTP way (as described in documentation), so while good for a beginner it can be considered bad style by experienced programmers. > > Sorry, but I have not seen any tutorial about how to avoid thinking the same function/module is always in the same process. It is a very fundamental concept (them not being) in Erlang, so just keep it in mind. One way would be to try and make all your three functions the same function, just have different arguments to the loop. Then you must think about it. > > >> On 10 Mar 2019, at 11:11, I Gusti Ngurah Oka Prinarjaya > wrote: >> >> Hi Bengt, >> >> Thank you for your review :) >> >> I don't quite understand with some of your thought. Then i hope you not mind to give more explanation. >> >> >> Seasoned Erlang programmers will tell you this is not the OTP way, or a waste of modules >> Did you mean my code here: https://pastebin.com/ECf3jhZ2 wasn't the OTP way? >> I learn from here: https://learnyousomeerlang.com/errors-and-processes and i do really a beginner at programming with erlang. >> >> >> So only do this until you have a better understanding. >> What is that? Did you mean doing one module with the interface functions to a gen_server and one module for the gen_server callbacks.? >> or what? >> >> >> Conflating the function (or even more often, module) and the process is a common mistake in the beginning. When my fellow programmers are experienced, but not used >> to process oriented programming. >> Any tutorials / reference for me to avoid this mistake ? >> >> Thank you :) >> >> >> >> >> >> >> >> >> Pada tanggal Min, 10 Mar 2019 pukul 14.49 bengt > menulis: >> Conflating the function (or even more often, module) and the process is a common mistake in the beginning. When my fellow programmers are experienced, but not used to process oriented programming, I have found that it helps to put the code that is run in different process in different modules. Ex: one module with the interface functions to a gen_server and one module for the gen_server callbacks. Seasoned Erlang programmers will tell you this is not the OTP way, or a waste of modules. So only do this until you have a better understanding. >> >> bengt >> >>> On 10 Mar 2019, at 04:57, I Gusti Ngurah Oka Prinarjaya > wrote: >>> >>> Hi Bengt, >>> >>> Thank you for the idea, >>> >>> I've implement your idea, from performance side, i think using two version of function will have better performance because there's no need to checking using IF statement. >>> >>> I worry at first to implement this idea, because i think different version of function will have different PID, hahaha it turns out exactly have same PID. >>> this is my new code https://pastebin.com/ECf3jhZ2 . Please review if there's any improvement needs. >>> >>> Thank you >>> >>> >>> >>> >>> >>> >>> >>> Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt > menulis: >>> Greetings, >>> >>> The error happens the second time any of the three processes call erlang:register/2. They already registered themselves the first time. If you want this structure, but not the error, you have to do the register before starting the loop. Eg, split the functions into two. One that do the register and then calls the second that does the loop. >>> >>> bengt >>> >>>> On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya > wrote: >>>> >>>> Hi Attila Rajmund Nohl, >>>> >>>> After i implement your suggestion, i get error when execute any of function call_the_*_p() >>>> for example: >>>> >>>> 3> newbie:starter(). >>>> <0.112.0> >>>> 4> newbie:call_the_second(). >>>> =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === >>>> Error in process <0.113.0> with exit value: >>>> {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, >>>> {newbie,the_second_p,0, >>>> [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, >>>> {line,17}]}]} >>>> >>>> {<0.113.0>,"the_second_p()","Halo second p!"} >>>> >>>> This is my new modified code https://pastebin.com/iYCxkkuz >>>> >>>> >>>> Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl > menulis: >>>> I Gusti Ngurah Oka Prinarjaya > ezt ?rta >>>> (id?pont: 2019. m?rc. 8., P, 12:11): >>>> > >>>> > Hi Folks, >>>> > >>>> > I need your help to review my code. I create and linking 3 process manually without using recursive. And inside p1 and p2 i using IF statement to check to make sure spawning process will only once. >>>> > >>>> > I mean, is part code below is a good idea? >>>> > >>>> > IsPidExists = whereis(xxx), >>>> > if IsPidExists =:= undefined -> >>>> > Pid = spawn_link(?MODULE, the_p, []), >>>> > register(xxx, Pid); >>>> > true -> true >>>> > end, >>>> >>>> Generally this is not a good idea, there's a race condition between >>>> checking that the process is registered (the whereis/1 call) and >>>> registering the new process. A better idea is to start the process and >>>> let the process itself to register. If register fails, it means that >>>> there's already a process registered, so the just started process can >>>> terminate. So your code could look like something like this: >>>> >>>> starter() -> >>>> spawn(?MODULE, the_first_p, []). >>>> >>>> the_first_p() -> >>>> register(pidfirstp, self()), >>>> spawn_link(?MODULE, the_second_p, []), >>>> ... >>>> the_first_p(). >>>> >>>> Actually if the register call fails, it throws a badarg and the >>>> process dies automatically, simplifying the code. >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- > -- > Dipl.-Inform. Andreas Schultz > > ----------------------- enabling your networks ---------------------- > Travelping GmbH Phone: +49-391-81 90 99 0 > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > 39108 Magdeburg Email: info@REDACTED > GERMANY Web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.harris@REDACTED Tue Mar 12 10:44:15 2019 From: robert.harris@REDACTED (Harris, Robert) Date: Tue, 12 Mar 2019 09:44:15 +0000 Subject: [erlang-questions] trying to compile erlang 19.0 on two solaris-on-sparc In-Reply-To: References: Message-ID: <4E6365EE-7B74-469C-A0A9-459DBC2A8B50@alertlogic.com> Hi, If it helps, I believe R19.3 is delivered by the runtime/erlang package in the most recent 11.3 SRU. In the latest 11.4 SRU it's R21. Regards, Robert > On 9 Mar 2019, at 00:24, HP Wei wrote: > > I am seeking advice on how to solve an issue. > > I try to build erlang from otp_src_19.0 on two solaris on sparc machines. > > They both have SunOS 5.11 (11.3) sun4u sparc > They both have gcc build by Sun?s cc using Sun?s ld and as. > [ I would think that these two machines are exactly the same.] > > However, > > On the first machine, the building went OK. > NOTE: configure ?prefix=/a/path > make > > ON the other one, the ?make? process went into lib/hipe/misc, and then > ERLC ../ebin/hipe_consttab.beam > Failed to create main carrier for binary_alloc > > ?> the building failed. > > ??????????? > > Since the erl run successfully on the first machine, > > I copied it to the 2nd machine and tried to run it (erl). > But it failed with the same error message: > Failed to create main carrier for binary_alloc > Abort > > ---------------------------------------- > > Anyone has any idea on how I can find the problem? > Something in the system on the 2nd machine must have been set up > differently. > > Thanks > HP > > > PS: I first tried to compile version 21.0 But that process failed on both > machines with apparently different issues. I was surprised that I got > version 19.0 compiled on one machine. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > https://urldefense.proofpoint.com/v2/url?u=http-3A__erlang.org_mailman_listinfo_erlang-2Dquestions&d=DwIGaQ&c=L_h2OePR2UWWefmqrezxOsP9Uqw55rRfX5bRtw9S4KY&r=rgvWXjU_2tA1ZUQSslrg0TYOEP4F7UfuySlE3gZm1mQ&m=b2w6xZRqXUcPi_smGRsN_O5Pn97CXX3IQVbUwNKEedM&s=kvJ1xGx7O6PG3SD7PIWxjgUJTzpf8G9II2_pZjev9Rg&e= -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3565 bytes Desc: not available URL: From pablo.platt@REDACTED Tue Mar 12 13:16:43 2019 From: pablo.platt@REDACTED (pablo platt) Date: Tue, 12 Mar 2019 14:16:43 +0200 Subject: [erlang-questions] Handle incoming UDP packets in DTLS server Message-ID: Hi, I'm trying to handle DTLS with other protocols on the same port but my UDP packets are ignored by the dtls_connection pid. I'm using OTP-22.0-rc1. I'm creating a UDP socket and dtls_connection pid and pass incoming DTLS UDP packets to the pid: Pid ! {udp, Socket, IP, Port, Data} The UDP packets are ignored in dtls_connection:init/3 [2]. > init(Type, Event, State) -> > gen_handshake(?FUNCTION_NAME, Type, Event, State). > I think the packets should arrive instead to [3]. > init({call, _} = Type, Event, #state{static_env = #static_env{role = > server}, > protocol_specific = PS} = State) -> > dtls_packet.demux:dispatch/3 just sends incoming UDP packets to the connection pid as normal messages [3] so I don't understand how it's different than what I'm doing. Does dtls_packet_demux changes the gen_statem state somehow before sending the first packet? This is how I'm creating the dtls connection pid to bypass dtls_packet_demux: -include_lib("ssl/src/ssl_internal.hrl"). > listen(Socket, Options) -> > {ok, Config} = ssl:handle_options(Options, server), > #config{ssl = DTLSOpts, emulated = EmOpts} = Config, > {ok, {IP, Port}} = inet:peername(Socket), > Client = {IP, Port}, > User = self(), > ConnArgs = [server, "localhost", Port, {self(), {Client, Socket}}, > {DTLSOpts, EmOpts, dtls_listener}, User, > dtls_socket:default_cb_info()], > case dtls_connection_sup:start_child(ConnArgs) of > {ok, Pid} -> > erlang:monitor(process, Pid), > {ok, Pid}; > {error, Reason} -> > {error, Reason} > end. > > handle_info({udp, Socket, Addr, Port, Data}, #state{pid=Pid} = State) > Pid ! {udp, Socket, Addr, Port, Data}, > {noreply, State}; > [1] https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_connection.erl#L463 [2] https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_connection.erl#L454 [3] https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L203 -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik.x.nord@REDACTED Tue Mar 12 16:48:14 2019 From: henrik.x.nord@REDACTED (Henrik Nord X) Date: Tue, 12 Mar 2019 15:48:14 +0000 Subject: [erlang-questions] Patch Package OTP 21.3 Released Message-ID: <1552405693.3155.112.camel@ericsson.com> OTP 21.3 Erlang/OTP 21.3 is the third service release for the 21 major release with improvements, as well as a few features! ? Highlights Kernel: * The standard logger handler, logger_std_h, now has a new internal feature for log rotation. For full information see the documentation. SSL: *?The Reason part of the error return from the functions connect and handshake has a better and documented format. This is a potential incompatibility. See the documentation. * Refactoring of state handling has improved the TLS application data throughput and reduced CPU overhead * Code optimizations has reduced CPU load for encryption/decryption, especially for Erlang's distribution protocol over TLS * Now supports active N Erl_interface: * Support for plugin of a user supplied socket implementation has been added. OTP: * The HTML reference documentation now shows the OTP version where modules and functions were first introduced. * Versions of OTP older than R13B04 is not shown in the reference documentation For a full list of details see: http://erlang.org/download/otp_src_21.3.readme Pre built versions for Windows can be fetched here: http://erlang.org/download/otp_win32_21.3.exe http://erlang.org/download/otp_win64_21.3.exe Online documentation can be browsed here: http://erlang.org/documentation/doc-10.3/doc The Erlang/OTP source can also be found at GitHub on the official Erlang repository, Here: OTP-21.2 Please report any new issues via Erlang/OTPs public issue tracker https://bugs.erlang.org ? We want to thank all of those who sent us patches, suggestions and bug reports! ? Thank you! ? The Erlang/OTP Team at Ericsson From carlsson.richard@REDACTED Tue Mar 12 20:55:51 2019 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 12 Mar 2019 20:55:51 +0100 Subject: [erlang-questions] Core Erlang: Associating Function Names to Function Bodies In-Reply-To: References: Message-ID: The problem seems to mainly be that you would like to be able to use cerl_trees:fold() to do the traversing for you. But in general, a fold doesn't pass the operator any info about the context of each element in relation to its neighbouring elements, in the traversal order. The representation of Core Erlang syntax trees was specifically designed so that only constructs that have a meaningful semantics on their own will be nodes in the tree. So, you get nodes for literals, calls, tuples, funs, letrecs, etc. (including modules). Many of these have a simple sequence of child nodes, as for a cons cell or a tuple, and in a post-order traversal, you know that you have just seen all the child nodes when you see the tuple node itself. But for some other constructs, like a 'fun (X1,...Xn) -> Body' or a 'case Expr of end' or 'module Name [ ... ] attributes [ ... ] F1/A1 = fun ... F2/A2 = fun ... end', there is nothing that tells a fold how to separate the subgroups of child nodes, especially when they all can have varying length. To fix this, a syntax tree representation can choose to use specific grouping nodes, like {module, [{name, [...]}, {exports, [...]}, {attributes, [...]}, {definitions, [...]} ]}, so that a fold would see "aha, I just got done with a 'definitions' group". I guess that's what you wanted, Chris. It does simplify some things in traversals. The drawback, and the reason we decided to avoid all such nodes, is that it forces all code that works on those syntax trees to understand these grouping nodes, and treat them separately from meaning-carrying nodes. In our experience, that is a big pain. I guess what we should have done but never got around to is write some really good tree walking functions that can tell you the context, choose a traversal order, and such things. As is, the cerl:subtrees() function is your best friend. The cerl_trees:fold() was just intended for simple things like checking for occurrences, counting tree sizes and whatnot. See the example below for how you can label a Core Erlang tree and traverse it to compute mappings between labels and function names. It's written as a core transform, so you can try it on an arbitrary module foo by compiling it with c(foo,[{core_transform,cerl_funcmap}]). /Richard %% ===================================================================== %% @doc Core transform example for computing and printing a label mapping %% @author Richard Carlsson -module(cerl_funcmap). -export([core_transform/2]). core_transform(T, _Opts) -> {T1, _MaxL} = cerl_trees:label(T), %%io:format("~n~s.~n", [cerl_prettypr:format(T1)]), {Ms, _Ls} = visit(T1), io:format("Functions to labels:~n~p.~n", [maps:from_list(Ms)]), Rev = lists:usort( lists:flatmap(fun ({V, Ls}) -> [{L, V} || L <- Ls] end, Ms)), io:format("Labels to functions:~n~p.~n", [maps:from_list(Rev)]), T. % return original T visit(T) -> case cerl:type(T) of letrec -> {visit_defs(cerl:letrec_defs(T), []), get_label(T)}; module -> {visit_defs(cerl:module_defs(T), []), get_label(T)}; _ -> case cerl:subtrees(T) of [] -> {[], get_label(T)}; Gs -> {Ms, Ls} = visit_list(lists:flatten(Gs)), {Ms, get_label(T) ++ Ls} end end. visit_list(Ts) -> lists:foldl(fun (T, {Ms0, Ls0}) -> {Ms, Ls} = visit(T), {Ms ++ Ms0, Ls ++ Ls0} end, {[], []}, Ts). visit_defs([{V, T} | Ds], Ms0) -> {Ms, Ls} = visit(T), Ls1 = ordsets:union(get_label(V), ordsets:from_list(Ls)), visit_defs(Ds, [{cerl:var_name(V), Ls1}] ++ Ms ++ Ms0); visit_defs([], Ms) -> Ms. get_label(T) -> case cerl:get_ann(T) of [{label, L} | _] -> [L]; _ -> [] end. %% ============================================================ Den m?n 11 mars 2019 kl 15:49 skrev Christopher Meiklejohn < christopher.meiklejohn@REDACTED>: > On Sun, Mar 10, 2019 at 1:02 PM Christopher Meiklejohn > wrote: > > > > As part of a static analysis I'm writing, I'm trying to associate > > function names with their function bodies so I can provide information > > about the calling functions to users as part of the completed > > analysis. However, I'm running into difficulty performing this > > mapping. > > > > The problem I'm running into is the following: > > > > 1.) In the Core Erlang AST, named functions are defined by associating > > a c_var node in the form of {Function, Arity} to a subtree containing > > the c_fun function body. > > 2.) Also, in the Core Erlang AST, calls to functions are also > > represented as c_var nodes in the form of {Function, Arity}. > > > > The cerl_trees:fold, mapfold all perform postorder traversals. With a > > postorder traversal, there may be an arbitrary distance in the fold > > between when a function is defined and where it is given a name. With > > reverse postorder, my understanding is that these nodes would be > > directly next to each other, which would make the mapping easier. > > > > My initial approach was to attempt to, when a c_var node was found in > > the proper form, store a candidate name for the next function that's > > found and perform the association that way. The problem that arises > > from this approach is that there can be an arbitrary number of c_var > > nodes for function invocations between the definition of the function > > and it's actual body. The same can also happen for any functions that > > occur in between as well. > > > > Therefore, my analysis incorrectly associates function bodies to > > function names for any function that calls another function in the > > body -- incorrectly thinking that the nearest c_var node containing a > > function name is it's associated name. > > > > I assume this must have been done for a previous analysis performed on > > Erlang, but I haven't found anything. Would a reverse postorder > > traversal make this easier? Is there a better way to identify the > > mapping between c_var nodes and c_funs that are being assigned to > > them? Has this been done before? > > Just for those who are interested, I did figure out one solution to > the problem which I have tried out on several models now that appears > to be working so far. > > Here's the rough outline of my currently-working solution: > > Since there is no node directly connecting the c_var of a variable > assignment along with the body of the function, I had to perform a > traversal where I try to match function bodies that I find along with > the variables they are being assigned to. To do this, I did the > following: > > 1.) I first use cerl_trees:fold to perform a postorder traversal of > the tree, building up a list of nodes to explore. > 2.) I then lists:foldr over this, allowing me to perform effectively a > reverse postorder traversal of the graph, where, I will encounter > function bodies (c_fun) prior to encountering function variables. > (c_var) > 3.) I perform an analysis that allows me to match up names to bodies > using the following heuristic: > > a.) Whenever I encounter a function body, I can determine from the > node whether or not the function body is the body of an anonymous > function or not. Anonymous functions are annotated with a randomly > assigned label which includes the enclosing function and the line > where the anonymous function was generated. This allows me to rule > out the top-level functions from functions that are created from > within a top-level function. When I discover one of these functions, > I keep track of this in a candidate list of potential function body > matches for the function variable I am assigning to. > b.) Whenever I encounter a c_var in the form of {Function, Arity}, I > know that I'm dealing with an application or an assignment. > (Curiously, why is there not a node that directly associates the c_var > to the c_fun -- this would have made things *significantly* easier, > but does not exist in the Core Erlang when performing a traversal via > cerl_trees.) If the function contains an annotation containing a line > number of invocation, then I know it's the *application* of this > function, and not the *abstraction* of this function. (Again, why > does c_var treat LHS assignments the same as RHS use of the function > -- if this was more specific, it would have again, made things > *significantly* easier.) If I'm looking for a candidate match between > body and function variable, then I perform a match based on this. > c.) Otherwise, either the c_var is the use of a function or the c_fun > is the creation of an anonymous function, and it's subsequently > ignored by the matching procedure. > > On the 'analysis' branch of this, I have a prototype of this > implementation that I've tested on several modules that appears to be > working. > > If this could have been done a different, easier way, I'd appreciate > knowing about it. > > Thanks, > Christopher > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From komendantskaya@REDACTED Tue Mar 12 22:02:12 2019 From: komendantskaya@REDACTED (Ekaterina Komendantskaya) Date: Tue, 12 Mar 2019 21:02:12 +0000 Subject: [erlang-questions] Principles and Practice of Declarative Programming 2019 -- 2nd CFP Message-ID: Dear Colleagues, apologies for multiple postings, and please distribute to other mailing lists that concern Declarative Programming Languages. We are looking forward to receiving your papers at PPDP'19, and to seeing you in Porto! ====================================================================== SECOND CALL FOR PAPERS -- PPDP 2019 21st International Symposium on Principles and Practice of Declarative Programming 7?9 October 2019, Porto, Portugal Collocated with FM'19 http://ppdp2019.macs.hw.ac.uk ====================================================================== Important Dates --------------- Title and abstract registration 26 April 2019 (AoE) Paper submission 3 May 2019 (AoE) Rebuttal period (48 hours) 3 June 2019 (AoE) Author notification 14 June 2019 Final paper version 15 July 2019 Conference 7?9 October 2019 About PPDP ---------- The PPDP 2019 symposium brings together researchers from the declarative programming communities, including those working in the functional, logic, answer-set, and constraint handling programming paradigms. The goal is to stimulate research in the use of logical formalisms and methods for analyzing, performing, specifying, and reasoning about computations, including mechanisms for concurrency, security, static analysis, and verification. Invited Speakers ---------------- Amal Ahmed Northeastern University, USA Naoki Kobayashi The University of Tokyo, Japan Scope ----- Submissions are invited on all topics related to declarative programming, from principles to practice, from foundations to applications. Topics of interest include, but are not limited to - Language Design: domain-specific languages; interoperability; concurrency, parallelism, and distribution; modules; probabilistic languages; reactive languages; database languages; knowledge representation languages; languages with objects; language extensions for tabulation; metaprogramming. - Implementations: abstract machines; interpreters; compilation; compile-time and run-time optimization; memory management. - Foundations: types; logical frameworks; monads and effects; semantics. - Analysis and Transformation: partial evaluation; abstract interpretation; control flow; data flow; information flow; termination analysis; resource analysis; type inference and type checking; verification; validation; debugging; testing. - Tools and Applications: programming and proof environments; verification tools; case studies in proof assistants or interactive theorem provers; certification; novel applications of declarative programming inside and outside of CS; declarative programming pearls; practical experience reports and industrial application; education. The PC chair (Ekaterina Komendanstkaya ) will be happy to advise on the appropriateness of a topic. Submission Categories --------------------- Submissions can be made in three categories: regular Research Papers, System Descriptions, and Experience Reports. Submissions of Research Papers must present original research which is unpublished and not submitted elsewhere. They must not exceed 12 pages ACM style 2-column (including figures, but excluding bibliography). Work that already appeared in unpublished or informally published workshop proceedings may be submitted (please contact the PC chair in case of questions). Research papers will be judged on originality, significance, correctness, clarity, and readability. Submission of System Descriptions must describe a working system whose description has not been published or submitted elsewhere. They must not exceed 10 pages and should contain a link to a working system. System Descriptions must be marked as such at the time of submission and will be judged on originality, significance, usefulness, clarity, and readability. Submissions of Experience Reports are meant to help create a body of published, refereed, citable evidence where declarative programming such as functional, logic, answer-set, constraint programming, etc., is used in practice. They must not exceed 5 pages **including references**. Experience Reports must be marked as such at the time of submission and need not report original research results. They will be judged on significance, usefulness, clarity, and readability. Supplementary material may be provided in a clearly marked appendix beyond the above-mentioned page limits. Reviewers are not required to study any material beyond the respective page limit. Format of a Submission ---------------------- For each paper category, you must use the most recent version of the "Current ACM Master Template" which is available at . The most recent version at the time of writing is 1.48. You must use the LaTeX sigconf proceedings template as the conference organizers are unable to process final submissions in other formats. In case of problems with the templates, contact ACM's TeX support team at Aptara . Authors should note ACM's statement on author's rights (http://authors.acm.org/) which apply to final papers. Submitted papers should meet the requirements of ACM's plagiarism policy (http://www.acm.org/publications/policies/plagiarism_policy). Requirements for Publication ---------------------------- At least one author of each accepted submission will be expected to attend and present the work at the conference. The pc chair may retract a paper that is not presented. The pc chair may also retract a paper if complaints about the paper's correctness are raised which cannot be resolved by the final paper deadline. Program Committee Chair ----------------------- Ekaterina Komendantskaya Heriot-Watt University, UK Program Committee ----------------- Henning Basold CNRS, ENS de Lyon, France Jasmin Christian Blanchette Vrije Universiteit Amsterdam, The Netherlands Maria Paola Bonacina University of Verona, Italy Dmitry Boulytchev JetBrains, Russia William Byrd University of Alabama at Birmingham, USA Ornela Dardha University of Glasgow, UK Marco Gaboardi University at Buffalo, SUNY, USA Arie Gurfinkel University of Waterloo, Canada Zhenjiang Hu National Institute of Informatics, Japan Moa Johansson Chalmers University of Technology, Sweden Neelakantan Krishnaswami University of Cambridge, UK Ralf L?mmel University of Koblenz ? Landau, Germany Anthony Widjaja Lin University of Oxford, UK Christopher Mieklejohn Carnegie Mellon University, USA Aart Middeldorp University of Innsbruck, Austria Gopalan Nadathur University of Minnesota, USA Keisuke Nakano Tohoku University, Japan Dominic Orchard University of Kent, UK Alberto Pardo University of the Republic, Uruguay Aleksy Schubert University of Warsaw, Poland Peter J. Stuckey The University of Melbourne, Australia Tarmo Uustalu Reykjavik University, Iceland Local Chair ----------- Jos? Nuno Oliveira INESC TEC & University of Minho, Portugal For any queries about local issues please contact the local organiser, Jos? Nuno Oliveira . -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Wed Mar 13 08:46:05 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Wed, 13 Mar 2019 14:46:05 +0700 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: <3463DD52-1024-4F4B-AE0E-41BF648A0783@gmail.com> References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> <3463DD52-1024-4F4B-AE0E-41BF648A0783@gmail.com> Message-ID: Hi, This is my updated code: https://pastebin.com/D9SAPUG8 please review again. Please give me the pseudo code clue if there's more incorrectness to fix in my code. And this is the output when i run my erlang program Erlang/OTP 21 [erts-10.2] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] Eshell V10.2 (abort with ^G) 1> c(procslinked). Recompiling /Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/procslinked.erl /Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/procslinked.erl:2: Warning: export_all flag enabled - all functions will be exported {ok,procslinked} 2> procslinked:starter(). Receive init_done from P1 Receive init_done from P2 Receive init_done from P3 {<0.91.0>,okbeud} 3> procslinked:call_the_first(). {<0.91.0>,"the_first_p()","Halo first p!"} 4> procslinked:call_the_second(). {<0.92.0>,"the_second_p()","Halo second p!"} 5> procslinked:call_the_third(). {<0.93.0>,"the_third_p()","Halo third p!"} 6> procslinked:call_the_first(). {<0.91.0>,"the_first_p()","Halo first p!"} 7> procslinked:call_the_second(). {<0.92.0>,"the_second_p()","Halo second p!"} 8> procslinked:call_the_third(). {<0.93.0>,"the_third_p()","Halo third p!"} 9> Thank you :) Pada tanggal Sel, 12 Mar 2019 pukul 02.13 bengt menulis: > Greetings, > > The race is that starter/0 will return before any of the three processes > have started. If you add a timer:sleep( 60000 ) before the calls to > register/0 you will see this even if you do call_the_first/0 manually. > > The pseudo code would be > My_pid = erlang:self(), > P = spawn(?MODULE, the_first_p, [My_pid]), > receive > {P, init_done} -> ok > end. > > And then sending {erlang:self(), init_done} to My_pid (the process that > started the_first_p). > > > On 11 Mar 2019, at 12:03, I Gusti Ngurah Oka Prinarjaya < > okaprinarjaya@REDACTED> wrote: > > Hi Andreas Schultz, > > >> The reason is that there is no guarantee that `call_the_third()` will > be executed after any of the spawn has succeeded or the register was > invoked. > 1. Did you mean this code? https://pastebin.com/ECf3jhZ2 > 2. and did you mean spawn_link/3 and register/2 is racy? > 3. I've test this code many times, and never get error in each call_the_* > function, even call_the_third/0 function. > > Here: https://learnyousomeerlang.com/the-hitchhikers-guide-to-concurrency, > and here: https://learnyousomeerlang.com/more-on-multiprocessing and > here: https://learnyousomeerlang.com/errors-and-processes teach me to do > that. Oh My God, where in this earth i can read the best erlang process > tutorial ? so i can use erlang in the right way. > > >> In order to get ordering guarantees you need to wait for the processes > to be past the init stage. > >> The normal way to do that is to wait for a message from the init > function of you child process. > Please give me a short pseudo-code clue to do this. I do really shocked > because of this code: https://pastebin.com/ECf3jhZ2 still not correct > after 2 times revision. > > Thank you :) > > > > Pada tanggal Sen, 11 Mar 2019 pukul 14.55 Andreas Schultz < > andreas.schultz@REDACTED> menulis: > >> You do realize that your code is still "racy" ? >> >> Invoking it like >> >> 2> procslinked:starter(), procslinked:call_the_third(). >> >> has a good chance of not producing the expected result. Most times it >> will simply fail with: >> >> ** exception error: bad argument >> in function procslinked:call_the_third/0 (procslinked.erl, line >> 54) >> >> The reason is that there is no guarantee that `call_the_third()` will be >> executed after any of the spawn has succeeded or the register was invoked. >> In order to get ordering guarantees you need to wait for the processes to >> be past the init stage. The normal way to do that is to wait for a message >> from the init function of you child process. >> >> BTW: this is exactly what proc_lib:init_ack does, but I guess you are >> trying to implement that yourself as a learning exercise. >> >> Andreas >> >> I Gusti Ngurah Oka Prinarjaya schrieb am So., >> 10. M?rz 2019 um 23:38 Uhr: >> >>> Hi Bengt, >>> >>> Thank you very much for all of your hints and suggestions. It's clear >>> now. >>> >>> >>> >>> Pada tanggal Sen, 11 Mar 2019 05.20, bengt >>> menulis: >>> >>>> I think your code is about learning erlang. Do that first. OTP is the >>>> next step. >>>> >>>> Yes, splitting a gen_server into callback module and interface module >>>> is not the OTP way (as described in documentation), so while good for a >>>> beginner it can be considered bad style by experienced programmers. >>>> >>>> Sorry, but I have not seen any tutorial about how to avoid thinking the >>>> same function/module is always in the same process. It is a very >>>> fundamental concept (them not being) in Erlang, so just keep it in mind. >>>> One way would be to try and make all your three functions the same >>>> function, just have different arguments to the loop. Then you must think >>>> about it. >>>> >>>> >>>> On 10 Mar 2019, at 11:11, I Gusti Ngurah Oka Prinarjaya < >>>> okaprinarjaya@REDACTED> wrote: >>>> >>>> Hi Bengt, >>>> >>>> Thank you for your review :) >>>> >>>> I don't quite understand with some of your thought. Then i hope you not >>>> mind to give more explanation. >>>> >>>> >> Seasoned Erlang programmers will tell you this is not the OTP way, >>>> or a waste of modules >>>> Did you mean my code here: https://pastebin.com/ECf3jhZ2 wasn't the >>>> OTP way? >>>> I learn from here: https://learnyousomeerlang.com/errors-and-processes >>>> and i do really a beginner at programming with erlang. >>>> >>>> >> So only do this until you have a better understanding. >>>> What is that? Did you mean *doing one module with the interface >>>> functions to a gen_server and one module for the gen_server callbacks.?* >>>> or what? >>>> >>>> >> Conflating the function (or even more often, module) and the process >>>> is a common mistake in the beginning. When my fellow programmers are >>>> experienced, but not used >> to process oriented programming. >>>> Any tutorials / reference for me to avoid this mistake ? >>>> >>>> Thank you :) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Pada tanggal Min, 10 Mar 2019 pukul 14.49 bengt >>>> menulis: >>>> >>>>> Conflating the function (or even more often, module) and the process >>>>> is a common mistake in the beginning. When my fellow programmers are >>>>> experienced, but not used to process oriented programming, I have found >>>>> that it helps to put the code that is run in different process in different >>>>> modules. Ex: one module with the interface functions to a gen_server and >>>>> one module for the gen_server callbacks. Seasoned Erlang programmers will >>>>> tell you this is not the OTP way, or a waste of modules. So only do this >>>>> until you have a better understanding. >>>>> >>>>> bengt >>>>> >>>>> On 10 Mar 2019, at 04:57, I Gusti Ngurah Oka Prinarjaya < >>>>> okaprinarjaya@REDACTED> wrote: >>>>> >>>>> Hi Bengt, >>>>> >>>>> Thank you for the idea, >>>>> >>>>> I've implement your idea, from performance side, i think using two >>>>> version of function will have better performance because there's no need to >>>>> checking using IF statement. >>>>> >>>>> I worry at first to implement this idea, because i think different >>>>> version of function will have different PID, hahaha it turns out exactly >>>>> have same PID. >>>>> this is my new code https://pastebin.com/ECf3jhZ2 . Please review if >>>>> there's any improvement needs. >>>>> >>>>> Thank you >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt >>>>> menulis: >>>>> >>>>>> Greetings, >>>>>> >>>>>> The error happens the second time any of the three processes call >>>>>> erlang:register/2. They already registered themselves the first time. If >>>>>> you want this structure, but not the error, you have to do the register >>>>>> before starting the loop. Eg, split the functions into two. One that do the >>>>>> register and then calls the second that does the loop. >>>>>> >>>>>> bengt >>>>>> >>>>>> On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya < >>>>>> okaprinarjaya@REDACTED> wrote: >>>>>> >>>>>> Hi Attila Rajmund Nohl, >>>>>> >>>>>> After i implement your suggestion, i get error when execute any of >>>>>> function call_the_*_p() >>>>>> for example: >>>>>> >>>>>> 3> newbie:starter(). >>>>>> <0.112.0> >>>>>> 4> newbie:call_the_second(). >>>>>> =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === >>>>>> Error in process <0.113.0> with exit value: >>>>>> {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, >>>>>> {newbie,the_second_p,0, >>>>>> >>>>>> [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, >>>>>> {line,17}]}]} >>>>>> >>>>>> {<0.113.0>,"the_second_p()","Halo second p!"} >>>>>> >>>>>> This is my new modified code https://pastebin.com/iYCxkkuz >>>>>> >>>>>> >>>>>> Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl < >>>>>> attila.r.nohl@REDACTED> menulis: >>>>>> >>>>>>> I Gusti Ngurah Oka Prinarjaya ezt ?rta >>>>>>> (id?pont: 2019. m?rc. 8., P, 12:11): >>>>>>> > >>>>>>> > Hi Folks, >>>>>>> > >>>>>>> > I need your help to review my code. I create and linking 3 process >>>>>>> manually without using recursive. And inside p1 and p2 i using IF statement >>>>>>> to check to make sure spawning process will only once. >>>>>>> > >>>>>>> > I mean, is part code below is a good idea? >>>>>>> > >>>>>>> > IsPidExists = whereis(xxx), >>>>>>> > if IsPidExists =:= undefined -> >>>>>>> > Pid = spawn_link(?MODULE, the_p, []), >>>>>>> > register(xxx, Pid); >>>>>>> > true -> true >>>>>>> > end, >>>>>>> >>>>>>> Generally this is not a good idea, there's a race condition between >>>>>>> checking that the process is registered (the whereis/1 call) and >>>>>>> registering the new process. A better idea is to start the process >>>>>>> and >>>>>>> let the process itself to register. If register fails, it means that >>>>>>> there's already a process registered, so the just started process can >>>>>>> terminate. So your code could look like something like this: >>>>>>> >>>>>>> starter() -> >>>>>>> spawn(?MODULE, the_first_p, []). >>>>>>> >>>>>>> the_first_p() -> >>>>>>> register(pidfirstp, self()), >>>>>>> spawn_link(?MODULE, the_second_p, []), >>>>>>> ... >>>>>>> the_first_p(). >>>>>>> >>>>>>> Actually if the register call fails, it throws a badarg and the >>>>>>> process dies automatically, simplifying the code. >>>>>>> >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> -- >> -- >> Dipl.-Inform. Andreas Schultz >> >> ----------------------- enabling your networks ---------------------- >> Travelping GmbH Phone: +49-391-81 90 99 0 >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 >> 39108 Magdeburg Email: info@REDACTED >> GERMANY Web: http://www.travelping.com >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 >> --------------------------------------------------------------------- >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Thu Mar 14 12:29:15 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Thu, 14 Mar 2019 12:29:15 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. Message-ID: Hi, I'm working on an Erlang WebRTC peer client (to send audio/video to the browser). WebRTC requires dtls-srtp and that in turn requires: 1. The use_srtp extension for key exchange. 2. Multiplexing of stun/turn/srtp packets on the socket. I know there's been work towards use_srtp and it's even in the source, but commented out. Ingela has been working on it for OTP 2, I believe, is there an ETA on this feature? Is multiplexing on the DTLS socket already possible using the cb_info? Has anyone tried that? http://erlang.org/pipermail/erlang-questions/2018-October/096457.html --Albin From frank.muller.erl@REDACTED Thu Mar 14 12:39:18 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 14 Mar 2019 12:39:18 +0100 Subject: [erlang-questions] Trim Logger output Message-ID: Hi guys Which config I should use to force Logger trim long lines of logs (ellided [...])? Thanks in advance /Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Mar 14 13:37:41 2019 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 14 Mar 2019 13:37:41 +0100 Subject: [erlang-questions] Trim Logger output In-Reply-To: References: Message-ID: Hi Frank, The default formatter, logger_formatter, has three configuration parameters for this purpose: depth, chars_limit, and max_size. depth and chars_limit are soft limits that work on format strings, and max_size is a hard truncation limit. See http://erlang.org/doc/man/logger_formatter.html for more details. Regards /siri Den tor. 14. mar. 2019 kl. 12:39 skrev Frank Muller < frank.muller.erl@REDACTED>: > Hi guys > > Which config I should use to force Logger trim long lines of logs (ellided > [...])? > > Thanks in advance > /Frank > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Mar 14 13:50:26 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 14 Mar 2019 13:50:26 +0100 Subject: [erlang-questions] Trim Logger output In-Reply-To: References: Message-ID: Hi Siri Exactly what I want. Any real example usage with good default settings please? I want to trim my strings to 1KB. /Frank Hi Frank, > > The default formatter, logger_formatter, has three configuration > parameters for this purpose: depth, chars_limit, and max_size. depth and > chars_limit are soft limits that work on format strings, and max_size is a > hard truncation limit. See http://erlang.org/doc/man/logger_formatter.html > for more details. > > Regards > /siri > > Den tor. 14. mar. 2019 kl. 12:39 skrev Frank Muller < > frank.muller.erl@REDACTED>: > >> Hi guys >> >> Which config I should use to force Logger trim long lines of logs >> (ellided [...])? >> >> Thanks in advance >> /Frank >> > _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Thu Mar 14 13:51:56 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 14 Mar 2019 13:51:56 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi! Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? : > Hi, > > I'm working on an Erlang WebRTC peer client (to send audio/video to > the browser). > > WebRTC requires dtls-srtp and that in turn requires: > > 1. The use_srtp extension for key exchange. > We will be implementing this as part of TLS-1.3 that we are currently working on, and we will have something runnable for OTP-22.0, although we are not promising that it will complete or that use_srtp will be part of OTP-22.0 > 2. Multiplexing of stun/turn/srtp packets on the socket. > > I know there's been work towards use_srtp and it's even in the source, > but commented out. Ingela has been working on it for OTP 2, I believe, > is there an ETA on this feature? > > Is multiplexing on the DTLS socket already possible using the cb_info? > Has anyone tried that? > > http://erlang.org/pipermail/erlang-questions/2018-October/096457.html > > The code has been written to make such extensions possible. There might be a need for more callbacks. I have not really had time to work on that as TLS-1.3, optimizations and erlang distribution over TLS has been prioritized higher. Suggestions are welcome. Regards Ingela Erlang/OTP team - Ericsson AB > > --Albin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Thu Mar 14 13:58:23 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 14 Mar 2019 13:58:23 +0100 Subject: [erlang-questions] Handle incoming UDP packets in DTLS server In-Reply-To: References: Message-ID: Hi! Den tis 12 mars 2019 kl 13:17 skrev pablo platt : > Hi, > > I'm trying to handle DTLS with other protocols on the same port but my UDP > packets are ignored by the dtls_connection pid. I'm using OTP-22.0-rc1. > > I'm creating a UDP socket and dtls_connection pid and pass incoming DTLS > UDP packets to the pid: > Pid ! {udp, Socket, IP, Port, Data} > > The UDP packets are ignored in dtls_connection:init/3 [2]. > >> init(Type, Event, State) -> >> gen_handshake(?FUNCTION_NAME, Type, Event, State). >> > > I think the packets should arrive instead to [3]. > >> init({call, _} = Type, Event, #state{static_env = #static_env{role = >> server}, >> protocol_specific = PS} = State) -> >> > > dtls_packet.demux:dispatch/3 just sends incoming UDP packets to the > connection pid as normal messages [3] so I don't understand how it's > different than what I'm doing. Does dtls_packet_demux changes the > gen_statem state somehow before sending the first packet? > > It dispatches the packets in an active once manner to the DTLS connection process that will tell the multiplexer when it wants more data. > This is how I'm creating the dtls connection pid to bypass > dtls_packet_demux: > > I think what we really want is callbacks to the multiplexor so that it should not need to be bypassed but extended. Regards Ingela Erlang/OTP team - Ericsson AB > -include_lib("ssl/src/ssl_internal.hrl"). >> listen(Socket, Options) -> >> {ok, Config} = ssl:handle_options(Options, server), >> #config{ssl = DTLSOpts, emulated = EmOpts} = Config, >> {ok, {IP, Port}} = inet:peername(Socket), >> Client = {IP, Port}, >> User = self(), >> ConnArgs = [server, "localhost", Port, {self(), {Client, Socket}}, >> {DTLSOpts, EmOpts, dtls_listener}, User, >> dtls_socket:default_cb_info()], >> case dtls_connection_sup:start_child(ConnArgs) of >> {ok, Pid} -> >> erlang:monitor(process, Pid), >> {ok, Pid}; >> {error, Reason} -> >> {error, Reason} >> end. >> >> handle_info({udp, Socket, Addr, Port, Data}, #state{pid=Pid} = State) >> Pid ! {udp, Socket, Addr, Port, Data}, >> {noreply, State}; >> > > [1] > https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_connection.erl#L463 > [2] > https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_connection.erl#L454 > [3] > https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L203 > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Thu Mar 14 15:38:03 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Thu, 14 Mar 2019 15:38:03 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi Ingela, Thanks for the quick reply! While cb_info certainly is one way of doing it, it feels a bit complicated... specifically if switching between active and passive mode. Not sure if ssl ever use passive mode internally? Demuxing is a different use case, I think.. Something that IMHO would be fantastic and simple (?) would be a dtls_filter_fun option. If true packet is passed up the ssl stack, otherwise passed on like a normal udp packet! There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically boils down to looking at the first byte of the packet, if it's [20..63] it should be treated as DTLS otherwise something else. So this would be absolutely trivial to implement if there was a dtls_filter_fun... https://tools.ietf.org/html/rfc7983 Then of course there also has to be a way to bypass DTLS when sending data... maybe send/3 (Socket, Data, Options)... What do you think? --Albin On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin wrote: > > Hi! > > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? : >> >> Hi, >> >> I'm working on an Erlang WebRTC peer client (to send audio/video to >> the browser). >> >> WebRTC requires dtls-srtp and that in turn requires: >> >> 1. The use_srtp extension for key exchange. > > > We will be implementing this as part of TLS-1.3 that we are currently working on, and we will have something runnable for OTP-22.0, although we are not promising that it will complete or that use_srtp will be part of OTP-22.0 > > >> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >> >> I know there's been work towards use_srtp and it's even in the source, >> but commented out. Ingela has been working on it for OTP 2, I believe, >> is there an ETA on this feature? > > >> >> >> >> Is multiplexing on the DTLS socket already possible using the cb_info? >> Has anyone tried that? >> >> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >> > > The code has been written to make such extensions possible. There might be a need for more callbacks. I have not really had time to work on that as > TLS-1.3, optimizations and erlang distribution over TLS has been prioritized higher. Suggestions are welcome. > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > >> >> >> --Albin >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From erlangsiri@REDACTED Thu Mar 14 16:13:43 2019 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 14 Mar 2019 16:13:43 +0100 Subject: [erlang-questions] Trim Logger output In-Reply-To: References: Message-ID: Since logger is so new, I don't know about any real use examples, but since chars_limit specifically tries to reduce the number of characters to the given number I'd set it to the actual size (or possibly a bit smaller) that you allow. If the size is absolute, then I'd use max_size in addition to do the hard truncation. If you'd rather use depth, the outcome is a bit harder to predict, but I found this guideline in some old documentation: "A reasonable starting value for Depth is 30. We recommend to test crashing various processes in your application, examine the logs from the crashes, and then increase or decrease the value." /siri Den tor. 14. mar. 2019 kl. 13:50 skrev Frank Muller < frank.muller.erl@REDACTED>: > Hi Siri > > Exactly what I want. Any real example usage with good default settings > please? > > I want to trim my strings to 1KB. > > /Frank > > Hi Frank, >> >> The default formatter, logger_formatter, has three configuration >> parameters for this purpose: depth, chars_limit, and max_size. depth and >> chars_limit are soft limits that work on format strings, and max_size is a >> hard truncation limit. See >> http://erlang.org/doc/man/logger_formatter.html for more details. >> >> Regards >> /siri >> >> Den tor. 14. mar. 2019 kl. 12:39 skrev Frank Muller < >> frank.muller.erl@REDACTED>: >> >>> Hi guys >>> >>> Which config I should use to force Logger trim long lines of logs >>> (ellided [...])? >>> >>> Thanks in advance >>> /Frank >>> >> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Mar 14 17:30:22 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 14 Mar 2019 19:30:22 +0300 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: The best option is to use dtls as a server that allows sending packets from outside and receiving reply from there. We are using this code in our webrtc stack, took it from dtls4srtp.erl file -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Thu Mar 14 17:34:20 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 14 Mar 2019 17:34:20 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi Albin! Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? : > Hi Ingela, > > Thanks for the quick reply! > > While cb_info certainly is one way of doing it, it feels a bit > complicated... specifically if switching between active and passive > mode. Not sure if ssl ever use passive mode internally? Demuxing is a > different use case, I think.. > > The cb_info is intended so that you may replace the transport layer, with most likely, an SCTP transport (can be done for both TLS and DTLS although there are some extensions needed for the DLTS version to work properly). I think some people also use it to implement WebSockets. ssl internally uses active n for TLS (since latest release) and active once for DTLS (we might change it) but an OTP supervised process will not use passive recv as we do not want it to block. > Something that IMHO would be fantastic and simple (?) would be a > dtls_filter_fun option. If true packet is passed up the ssl stack, > otherwise passed on like a normal udp packet! > > Sounds reasonable. Otherwise sent to some other Erlang process than the "DTLS-connection" process that is. > There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically > boils down to looking at the first byte of the packet, if it's > [20..63] it should be treated as DTLS otherwise something else. So > this would be absolutely trivial to implement if there was a > dtls_filter_fun... > > https://tools.ietf.org/html/rfc7983 > > Then of course there also has to be a way to bypass DTLS when sending > data... maybe send/3 (Socket, Data, Options)... > > Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS. Regards Ingela Erlang/OTP team - Ericsson AB > What do you think? > > > --Albin > > On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin > wrote: > > > > Hi! > > > > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? >: > >> > >> Hi, > >> > >> I'm working on an Erlang WebRTC peer client (to send audio/video to > >> the browser). > >> > >> WebRTC requires dtls-srtp and that in turn requires: > >> > >> 1. The use_srtp extension for key exchange. > > > > > > We will be implementing this as part of TLS-1.3 that we are currently > working on, and we will have something runnable for OTP-22.0, although we > are not promising that it will complete or that use_srtp will be part of > OTP-22.0 > > > > > >> > >> 2. Multiplexing of stun/turn/srtp packets on the socket. > >> > >> I know there's been work towards use_srtp and it's even in the source, > >> but commented out. Ingela has been working on it for OTP 2, I believe, > >> is there an ETA on this feature? > > > > > >> > >> > >> > >> Is multiplexing on the DTLS socket already possible using the cb_info? > >> Has anyone tried that? > >> > >> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html > >> > > > > The code has been written to make such extensions possible. There might > be a need for more callbacks. I have not really had time to work on that as > > TLS-1.3, optimizations and erlang distribution over TLS has been > prioritized higher. Suggestions are welcome. > > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > > > > > >> > >> > >> --Albin > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.schultz@REDACTED Thu Mar 14 17:38:42 2019 From: andreas.schultz@REDACTED (Andreas Schultz) Date: Thu, 14 Mar 2019 17:38:42 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi Ingela Andin schrieb am Do., 14. M?rz 2019 um 17:34 Uhr: > Hi Albin! > > Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? : > >> Hi Ingela, >> >> Thanks for the quick reply! >> >> While cb_info certainly is one way of doing it, it feels a bit >> complicated... specifically if switching between active and passive >> mode. Not sure if ssl ever use passive mode internally? Demuxing is a >> different use case, I think.. >> >> > The cb_info is intended so that you may replace the transport layer, with > most likely, an SCTP transport (can be done for both TLS and DTLS > although there are some extensions needed for the DLTS version to work > properly). I think some people also use it to implement WebSockets. > > ssl internally uses active n for TLS (since latest release) and active > once for DTLS (we might change it) but an OTP supervised process will not > use passive recv as we do not want it to block. > > > >> Something that IMHO would be fantastic and simple (?) would be a >> dtls_filter_fun option. If true packet is passed up the ssl stack, >> otherwise passed on like a normal udp packet! >> >> > Sounds reasonable. Otherwise sent to some other Erlang process than the > "DTLS-connection" process that is. > No, that's not enough. Some protocols put additional headers in front of the DTLS packets. So there needs to be a way to strip headers on Rx and add it on Tx (with session information if needed). Andreas > > >> There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically >> boils down to looking at the first byte of the packet, if it's >> [20..63] it should be treated as DTLS otherwise something else. So >> this would be absolutely trivial to implement if there was a >> dtls_filter_fun... >> >> https://tools.ietf.org/html/rfc7983 >> >> Then of course there also has to be a way to bypass DTLS when sending >> data... maybe send/3 (Socket, Data, Options)... >> >> > Maybe transport_send as compared to the existing transport_accept. Would > only work for DTLS. > > Regards Ingela Erlang/OTP team - Ericsson AB > > >> What do you think? >> >> >> --Albin >> >> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin >> wrote: >> > >> > Hi! >> > >> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? > >: >> >> >> >> Hi, >> >> >> >> I'm working on an Erlang WebRTC peer client (to send audio/video to >> >> the browser). >> >> >> >> WebRTC requires dtls-srtp and that in turn requires: >> >> >> >> 1. The use_srtp extension for key exchange. >> > >> > >> > We will be implementing this as part of TLS-1.3 that we are currently >> working on, and we will have something runnable for OTP-22.0, although we >> are not promising that it will complete or that use_srtp will be part of >> OTP-22.0 >> > >> > >> >> >> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >> >> >> >> I know there's been work towards use_srtp and it's even in the source, >> >> but commented out. Ingela has been working on it for OTP 2, I believe, >> >> is there an ETA on this feature? >> > >> > >> >> >> >> >> >> >> >> Is multiplexing on the DTLS socket already possible using the cb_info? >> >> Has anyone tried that? >> >> >> >> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >> >> >> > >> > The code has been written to make such extensions possible. There might >> be a need for more callbacks. I have not really had time to work on that as >> > TLS-1.3, optimizations and erlang distribution over TLS has been >> prioritized higher. Suggestions are welcome. >> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >> > >> > >> > >> > >> >> >> >> >> >> --Albin >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl.-Inform. Andreas Schultz ----------------------- enabling your networks ---------------------- Travelping GmbH Phone: +49-391-81 90 99 0 Roentgenstr. 13 Fax: +49-391-81 90 99 299 39108 Magdeburg Email: info@REDACTED GERMANY Web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Thu Mar 14 18:22:31 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 14 Mar 2019 18:22:31 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi! Andreas, see comment below. Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < andreas.schultz@REDACTED>: > Hi > > Ingela Andin schrieb am Do., 14. M?rz 2019 um > 17:34 Uhr: > >> Hi Albin! >> >> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? : >> >>> Hi Ingela, >>> >>> Thanks for the quick reply! >>> >>> While cb_info certainly is one way of doing it, it feels a bit >>> complicated... specifically if switching between active and passive >>> mode. Not sure if ssl ever use passive mode internally? Demuxing is a >>> different use case, I think.. >>> >>> >> The cb_info is intended so that you may replace the transport layer, with >> most likely, an SCTP transport (can be done for both TLS and DTLS >> although there are some extensions needed for the DLTS version to work >> properly). I think some people also use it to implement WebSockets. >> >> ssl internally uses active n for TLS (since latest release) and active >> once for DTLS (we might change it) but an OTP supervised process will not >> use passive recv as we do not want it to block. >> >> >> >>> Something that IMHO would be fantastic and simple (?) would be a >>> dtls_filter_fun option. If true packet is passed up the ssl stack, >>> otherwise passed on like a normal udp packet! >>> >>> >> Sounds reasonable. Otherwise sent to some other Erlang process than the >> "DTLS-connection" process that is. >> > > No, that's not enough. Some protocols put additional headers in front of > the DTLS packets. So there needs to be a way to strip headers on Rx and add > it on Tx (with session information if needed). > > Maybe the demultiplexor process can have a "packet mode" that is set to "no packet" default and needs a callback handler for anything else? Regards Ingela Erlang/OTP team - Ericsson AB > Andreas > > >> >> >>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically >>> boils down to looking at the first byte of the packet, if it's >>> [20..63] it should be treated as DTLS otherwise something else. So >>> this would be absolutely trivial to implement if there was a >>> dtls_filter_fun... >>> >>> https://tools.ietf.org/html/rfc7983 >>> >>> Then of course there also has to be a way to bypass DTLS when sending >>> data... maybe send/3 (Socket, Data, Options)... >>> >>> >> Maybe transport_send as compared to the existing transport_accept. Would >> only work for DTLS. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >>> What do you think? >>> >>> >>> --Albin >>> >>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin >>> wrote: >>> > >>> > Hi! >>> > >>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < >>> albin.stigo@REDACTED>: >>> >> >>> >> Hi, >>> >> >>> >> I'm working on an Erlang WebRTC peer client (to send audio/video to >>> >> the browser). >>> >> >>> >> WebRTC requires dtls-srtp and that in turn requires: >>> >> >>> >> 1. The use_srtp extension for key exchange. >>> > >>> > >>> > We will be implementing this as part of TLS-1.3 that we are currently >>> working on, and we will have something runnable for OTP-22.0, although we >>> are not promising that it will complete or that use_srtp will be part of >>> OTP-22.0 >>> > >>> > >>> >> >>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >>> >> >>> >> I know there's been work towards use_srtp and it's even in the source, >>> >> but commented out. Ingela has been working on it for OTP 2, I believe, >>> >> is there an ETA on this feature? >>> > >>> > >>> >> >>> >> >>> >> >>> >> Is multiplexing on the DTLS socket already possible using the cb_info? >>> >> Has anyone tried that? >>> >> >>> >> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >>> >> >>> > >>> > The code has been written to make such extensions possible. There >>> might be a need for more callbacks. I have not really had time to work on >>> that as >>> > TLS-1.3, optimizations and erlang distribution over TLS has been >>> prioritized higher. Suggestions are welcome. >>> > >>> > Regards Ingela Erlang/OTP team - Ericsson AB >>> > >>> > >>> > >>> > >>> >> >>> >> >>> >> --Albin >>> >> _______________________________________________ >>> >> erlang-questions mailing list >>> >> erlang-questions@REDACTED >>> >> http://erlang.org/mailman/listinfo/erlang-questions >>> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- > -- > Dipl.-Inform. Andreas Schultz > > ----------------------- enabling your networks ---------------------- > Travelping GmbH Phone: +49-391-81 90 99 0 > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > 39108 Magdeburg Email: info@REDACTED > GERMANY Web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > --------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Mar 14 18:47:55 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 14 Mar 2019 18:47:55 +0100 Subject: [erlang-questions] Trim Logger output In-Reply-To: References: Message-ID: depth 10 / chars_limit 1024 / max_size 2048 worked for me. /Frank Since logger is so new, I don't know about any real use examples, but since chars_limit > specifically tries to reduce the number of characters to the given number > I'd set it to the actual size (or possibly a bit smaller) that you allow. If > the size is absolute, then I'd use max_size in addition to do the hard > truncation. > > If you'd rather use depth, the outcome is a bit harder to predict, but I > found this guideline in some old documentation: > "A reasonable starting value for Depth is 30. We recommend to test > crashing various processes in your application, examine the logs from the > crashes, and then increase or decrease the value." > > > /siri > > > Den tor. 14. mar. 2019 kl. 13:50 skrev Frank Muller < > frank.muller.erl@REDACTED>: > >> Hi Siri >> >> Exactly what I want. Any real example usage with good default settings >> please? >> >> I want to trim my strings to 1KB. >> >> /Frank >> >> Hi Frank, >>> >>> The default formatter, logger_formatter, has three configuration >>> parameters for this purpose: depth, chars_limit, and max_size. depth and >>> chars_limit are soft limits that work on format strings, and max_size is a >>> hard truncation limit. See >>> http://erlang.org/doc/man/logger_formatter.html for more details. >>> >>> Regards >>> /siri >>> >>> Den tor. 14. mar. 2019 kl. 12:39 skrev Frank Muller < >>> frank.muller.erl@REDACTED>: >>> >>>> Hi guys >>>> >>>> Which config I should use to force Logger trim long lines of logs >>>> (ellided [...])? >>>> >>>> Thanks in advance >>>> /Frank >>>> >>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Thu Mar 14 18:49:40 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Thu, 14 Mar 2019 18:49:40 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi Ingela and Andreas, > No, that's not enough. Some protocols put additional headers in front of the DTLS packets. So there needs to be a way to strip > headers on Rx and add it on Tx (with session information if needed). I have to admit I have not encountered this practice... do you have a particular protocol in mind or is it a part of dtls-srtp I have missed? One could argue that if you add additional headers and maintain some kind of state you are actually dealing with a different transport layer...? I would very much like a way where filtered out packages were sent to the controlling process as {udp,Socket instead of {ssl, Socket... The question in the latter case is if Socket should be the ssl socket or the transport socket. Messing with the transport socket could be detrimental to dtls. One could also extend the filter_fun idea to a transform_fun where one could transform in packet in addition to demultiplexing, but like I said, I think additional headers to dtls packets belong to the transport layer. I don't have in-depth knowledge of the ssl app but it seems adding a filter_fun would be almost trivial? > Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS. Well either that or some way of accessing the transport socket, but transport_send for sure plays well with existing API! --Albin On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin wrote: > > Hi! > > Andreas, see comment below. > > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz : >> >> Hi >> >> Ingela Andin schrieb am Do., 14. M?rz 2019 um 17:34 Uhr: >>> >>> Hi Albin! >>> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? : >>>> >>>> Hi Ingela, >>>> >>>> Thanks for the quick reply! >>>> >>>> While cb_info certainly is one way of doing it, it feels a bit >>>> complicated... specifically if switching between active and passive >>>> mode. Not sure if ssl ever use passive mode internally? Demuxing is a >>>> different use case, I think.. >>>> >>> >>> The cb_info is intended so that you may replace the transport layer, with most likely, an SCTP transport (can be done for both TLS and DTLS although there are some extensions needed for the DLTS version to work properly). I think some people also use it to implement WebSockets. >>> >>> ssl internally uses active n for TLS (since latest release) and active once for DTLS (we might change it) but an OTP supervised process will not use passive recv as we do not want it to block. >>> >>> >>>> >>>> Something that IMHO would be fantastic and simple (?) would be a >>>> dtls_filter_fun option. If true packet is passed up the ssl stack, >>>> otherwise passed on like a normal udp packet! >>>> >>> >>> Sounds reasonable. Otherwise sent to some other Erlang process than the "DTLS-connection" process that is. >> >> >> No, that's not enough. Some protocols put additional headers in front of the DTLS packets. So there needs to be a way to strip headers on Rx and add it on Tx (with session information if needed). >> > > Maybe the demultiplexor process can have a "packet mode" that is set to "no packet" default and needs a callback handler for anything else? > > > Regards Ingela Erlang/OTP team - Ericsson AB > >> >> Andreas >> >>> >>> >>>> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically >>>> boils down to looking at the first byte of the packet, if it's >>>> [20..63] it should be treated as DTLS otherwise something else. So >>>> this would be absolutely trivial to implement if there was a >>>> dtls_filter_fun... >>>> >>>> https://tools.ietf.org/html/rfc7983 >>>> >>>> Then of course there also has to be a way to bypass DTLS when sending >>>> data... maybe send/3 (Socket, Data, Options)... >>>> >>> >>> Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS. >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>>> >>>> What do you think? >>>> >>>> >>>> --Albin >>>> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin wrote: >>>> > >>>> > Hi! >>>> > >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? : >>>> >> >>>> >> Hi, >>>> >> >>>> >> I'm working on an Erlang WebRTC peer client (to send audio/video to >>>> >> the browser). >>>> >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: >>>> >> >>>> >> 1. The use_srtp extension for key exchange. >>>> > >>>> > >>>> > We will be implementing this as part of TLS-1.3 that we are currently working on, and we will have something runnable for OTP-22.0, although we are not promising that it will complete or that use_srtp will be part of OTP-22.0 >>>> > >>>> > >>>> >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >>>> >> >>>> >> I know there's been work towards use_srtp and it's even in the source, >>>> >> but commented out. Ingela has been working on it for OTP 2, I believe, >>>> >> is there an ETA on this feature? >>>> > >>>> > >>>> >> >>>> >> >>>> >> >>>> >> Is multiplexing on the DTLS socket already possible using the cb_info? >>>> >> Has anyone tried that? >>>> >> >>>> >> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >>>> >> >>>> > >>>> > The code has been written to make such extensions possible. There might be a need for more callbacks. I have not really had time to work on that as >>>> > TLS-1.3, optimizations and erlang distribution over TLS has been prioritized higher. Suggestions are welcome. >>>> > >>>> > Regards Ingela Erlang/OTP team - Ericsson AB >>>> > >>>> > >>>> > >>>> > >>>> >> >>>> >> >>>> >> --Albin >>>> >> _______________________________________________ >>>> >> erlang-questions mailing list >>>> >> erlang-questions@REDACTED >>>> >> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> -- >> -- >> Dipl.-Inform. Andreas Schultz >> >> ----------------------- enabling your networks ---------------------- >> Travelping GmbH Phone: +49-391-81 90 99 0 >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 >> 39108 Magdeburg Email: info@REDACTED >> GERMANY Web: http://www.travelping.com >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 >> --------------------------------------------------------------------- From eric.pailleau@REDACTED Thu Mar 14 22:19:01 2019 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Thu, 14 Mar 2019 22:19:01 +0100 Subject: [erlang-questions] [ANN] geas 2.4.4 (Erlang 21.3) Message-ID: Hi Geas 2.4.4 has been released ! Geas is a tool detecting the runnable official Erlang release window for your project. Geas will tell you also : - what are the offending functions in the beam/source files that reduce the available window. - if some beam files are compiled native. - the installed patches and recommend patches that should be installed depending your code. Geas is available as a module, erlang.mk and rebar 2/3 plugins. Changelog : - Update for Erlang 21.3 detection and database https://github.com/crownedgrouse/geas https://github.com/crownedgrouse/geas/releases/tag/2.4.4 Change between 21.2 and 21.3 : https://raw.githubusercontent.com/crownedgrouse/geas_devel/master/doc/reldiffs/yaml/21.2%7E21.3 Cheers ! Eric From t6sn7gt@REDACTED Thu Mar 14 23:12:35 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Thu, 14 Mar 2019 18:12:35 -0400 Subject: [erlang-questions] Good form Message-ID: <63ed714d-6084-fff7-930a-1a1e4f29e67a@aim.com> Sometimes, when a variable is bound then used only once in a function call, it seems easier just to just use what it is bound to directly in the function call, bypassing the first step. Here's an example: getSound(Event) ->element(evaluate:probableElement(evaluate:probabilities(maps:get(elementTag, Event))), hd(lists:nth(maps:get(templateTag, Event), agitatedSoundResources(maps:get(scalarTag, Event), maps:get(registerTag, Event), maps:get(transpositionTag, Event))))). Alternatively, I could have declared, for example, a raft of variable like ElementNumber, ElementTag, TemplateTag, etc. I realize that this all-in-one-compact version tends towards inscrutabel c code liek &X++ ?. How do you approach the temptation to avoid discrete steps in favor of compactness? Thanks. Don -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugo@REDACTED Thu Mar 14 23:35:50 2019 From: hugo@REDACTED (Hugo Mills) Date: Thu, 14 Mar 2019 22:35:50 +0000 Subject: [erlang-questions] Good form In-Reply-To: <63ed714d-6084-fff7-930a-1a1e4f29e67a@aim.com> References: <63ed714d-6084-fff7-930a-1a1e4f29e67a@aim.com> Message-ID: <20190314223550.GC10520@carfax.org.uk> On Thu, Mar 14, 2019 at 06:12:35PM -0400, Donald Steven wrote: > Sometimes, when a variable is bound then used only once in a > function call, it seems easier just to just use what it is bound to > directly in the function call, bypassing the first step. > > Here's an example: > > getSound(Event) ->element(evaluate:probableElement(evaluate:probabilities(maps:get(elementTag, > Event))), > hd(lists:nth(maps:get(templateTag, Event), > agitatedSoundResources(maps:get(scalarTag, Event), > maps:get(registerTag, > Event), maps:get(transpositionTag, Event))))). > > Alternatively, I could have declared, for example, a raft of > variable like ElementNumber, ElementTag, TemplateTag, etc. > > I realize that this all-in-one-compact version tends towards > inscrutabel c code liek &X++ ?. > > How do you approach the temptation to avoid discrete steps in favor > of compactness? I don't find it tempting at all. :) The discrete steps can be useful documentation, because you can give the interim variables meaningful names, explaining (a little) what it is that you're doing. It also helps to break up the calls for formatting and readability, particularly if you have functions with multiple parameters in the sequence. Hugo. -- Hugo Mills | The most exciting phrase to hear in science, the one hugo@REDACTED carfax.org.uk | that heralds new discoveries, is not "Eureka!", but http://carfax.org.uk/ | "That's funny..." PGP: E2AB1DE4 | Isaac Asimov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From be.dmitry@REDACTED Fri Mar 15 01:49:59 2019 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Fri, 15 Mar 2019 11:49:59 +1100 Subject: [erlang-questions] Calls to global:register_name hang in whole cluster for hours Message-ID: Hi, I'm just announcing a ticket https://bugs.erlang.org/browse/ERL-885 and would like to invite interested parties to participate in the discussion of global behaviour in it. Kind regards, Dmitry Belyaev -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Fri Mar 15 02:56:10 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Fri, 15 Mar 2019 14:56:10 +1300 Subject: [erlang-questions] Good form In-Reply-To: <20190314223550.GC10520@carfax.org.uk> References: <63ed714d-6084-fff7-930a-1a1e4f29e67a@aim.com> <20190314223550.GC10520@carfax.org.uk> Message-ID: At one extreme we reach the 'point-free' style liked in Haskell, or the 'pipeful' style common in F#. There is a place for that sort of thing, but I'm not convinced that code meant for other people to read is that place. Think of introducing variables as an opportunity to make your code easier to understand, not as a cost. On Fri, 15 Mar 2019 at 11:36, Hugo Mills wrote: > On Thu, Mar 14, 2019 at 06:12:35PM -0400, Donald Steven wrote: > > Sometimes, when a variable is bound then used only once in a > > function call, it seems easier just to just use what it is bound to > > directly in the function call, bypassing the first step. > > > > Here's an example: > > > > getSound(Event) > ->element(evaluate:probableElement(evaluate:probabilities(maps:get(elementTag, > > Event))), > > hd(lists:nth(maps:get(templateTag, Event), > > agitatedSoundResources(maps:get(scalarTag, Event), > > maps:get(registerTag, > > Event), maps:get(transpositionTag, Event))))). > > > > Alternatively, I could have declared, for example, a raft of > > variable like ElementNumber, ElementTag, TemplateTag, etc. > > > > I realize that this all-in-one-compact version tends towards > > inscrutabel c code liek &X++ ?. > > > > How do you approach the temptation to avoid discrete steps in favor > > of compactness? > > I don't find it tempting at all. :) > > The discrete steps can be useful documentation, because you can > give the interim variables meaningful names, explaining (a little) > what it is that you're doing. > > It also helps to break up the calls for formatting and readability, > particularly if you have functions with multiple parameters in the > sequence. > > Hugo. > > -- > Hugo Mills | The most exciting phrase to hear in science, the > one > hugo@REDACTED carfax.org.uk | that heralds new discoveries, is not "Eureka!", > but > http://carfax.org.uk/ | "That's funny..." > PGP: E2AB1DE4 | Isaac > Asimov > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBAgAGBQJcitdGAAoJEFheFHXiqx3khsgP/2+gnwII70wb5JGoX4i+U78F > /aLbdSA7mtYDlXJDevPmwAr0unZZOG4A+EM8pytRXLmN1lxanOU5Ja1LIsDTWJFP > AsjwbAH2pVtdFerwug6braBFNyD+vyoPpYo3lni+UnmDmaeCTR88C9np5Nvi07bZ > TJRVoi5Sx7pRo5m4P2v2O2diTb/Gt8Xxk+zkvOzo5obSAsB8bzLhDiL/fVnCR91m > 6Z4bk2eL/iVvuYqhVQmpIrMDGJvzzqW1POuevoE7+/HdScFzHv8Xow3XxDmPC3TT > r/04lviaZounef0mymNsVILmsQUzpF/ZMq3X8KLddbFovqRLbxyYmtgiMs8iyfvF > 0tbKfM53Y+LbKvRdmVe50lDVR1C8KAPvpUO+piFh3lP5aOK9r8vK0v5R9v9exMwp > yNqspsNZk6iTnF4Mxaa2P80vHM2DmAfdiKYLZb9gqJKXbuC9g1t2g6z+1GP1Y9JS > HuUaTX3ed0zdzmNWT7YxaSsWi6TJp9lhTH4gcfqNLmvr4wgsgPABD1KqoOgverrZ > yJcwEKk2xuuZt5xLvNdJacN1VWZS/ybQiko022JR4iXV1nXoz/P8tR1rx+tKez2u > y3gqdrPVA4XT/X8j+YrkLm3G2v1XJy6+ANO2oe+Iz41vgi0EtbVywZZKyChUry6u > Qpsht+QWZofR+vdWzk4Q > =fKS8 > -----END PGP SIGNATURE----- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Fri Mar 15 06:35:11 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Fri, 15 Mar 2019 06:35:11 +0100 Subject: [erlang-questions] Erlang 21.3: erl_call crashing Message-ID: Hi guys We switched to 21.3 to generate our release and noticed that we can?t use erl_call shipped with 21.3 anymore. It always crashes with SIGSEGV. Simply overwriting the erl_call binary with the one from 21.2.4 fixed the problem even in release generated with 21.3. Any idea? Did the Erlang team change erl_call in 21.3? /Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.schultz@REDACTED Fri Mar 15 11:35:43 2019 From: andreas.schultz@REDACTED (Andreas Schultz) Date: Fri, 15 Mar 2019 11:35:43 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Albin Stig? schrieb am Do., 14. M?rz 2019 um 18:49 Uhr: > Hi Ingela and Andreas, > > > No, that's not enough. Some protocols put additional headers in front of > the DTLS packets. So there needs to be a way to strip > > headers on Rx and add it on Tx (with session information if needed). > > I have to admit I have not encountered this practice... do you have a > particular protocol in mind or is it a part of dtls-srtp I have > missed? One could argue that if you add additional headers and > maintain some kind of state you are actually dealing with a different > transport layer...? > CAPWAP is doing that https://tools.ietf.org/html/rfc5415#section-4.1 I would very much like a way where filtered out packages were sent to > the controlling process as {udp,Socket instead of {ssl, Socket... The > question in the latter case is if Socket should be the ssl socket or > the transport socket. Messing with the transport socket could be > detrimental to dtls. > > One could also extend the filter_fun idea to a transform_fun where one > could transform in packet in addition to demultiplexing, but like I > said, I think additional headers to dtls packets belong to the > transport layer. > Passing a State in and out of such a transform would be good. Andreas > > I don't have in-depth knowledge of the ssl app but it seems adding a > filter_fun would be almost trivial? > > > Maybe transport_send as compared to the existing transport_accept. > Would only work for DTLS. > > Well either that or some way of accessing the transport socket, but > transport_send for sure plays well with existing API! > > > --Albin > > On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin > wrote: > > > > Hi! > > > > Andreas, see comment below. > > > > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < > andreas.schultz@REDACTED>: > >> > >> Hi > >> > >> Ingela Andin schrieb am Do., 14. M?rz 2019 um > 17:34 Uhr: > >>> > >>> Hi Albin! > >>> > >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? < > albin.stigo@REDACTED>: > >>>> > >>>> Hi Ingela, > >>>> > >>>> Thanks for the quick reply! > >>>> > >>>> While cb_info certainly is one way of doing it, it feels a bit > >>>> complicated... specifically if switching between active and passive > >>>> mode. Not sure if ssl ever use passive mode internally? Demuxing is a > >>>> different use case, I think.. > >>>> > >>> > >>> The cb_info is intended so that you may replace the transport layer, > with most likely, an SCTP transport (can be done for both TLS and DTLS > although there are some extensions needed for the DLTS version to work > properly). I think some people also use it to implement WebSockets. > >>> > >>> ssl internally uses active n for TLS (since latest release) and active > once for DTLS (we might change it) but an OTP supervised process will not > use passive recv as we do not want it to block. > >>> > >>> > >>>> > >>>> Something that IMHO would be fantastic and simple (?) would be a > >>>> dtls_filter_fun option. If true packet is passed up the ssl stack, > >>>> otherwise passed on like a normal udp packet! > >>>> > >>> > >>> Sounds reasonable. Otherwise sent to some other Erlang process than > the "DTLS-connection" process that is. > >> > >> > >> No, that's not enough. Some protocols put additional headers in front > of the DTLS packets. So there needs to be a way to strip headers on Rx and > add it on Tx (with session information if needed). > >> > > > > Maybe the demultiplexor process can have a "packet mode" that is set to > "no packet" default and needs a callback handler for anything else? > > > > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > >> > >> Andreas > >> > >>> > >>> > >>>> > >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically > >>>> boils down to looking at the first byte of the packet, if it's > >>>> [20..63] it should be treated as DTLS otherwise something else. So > >>>> this would be absolutely trivial to implement if there was a > >>>> dtls_filter_fun... > >>>> > >>>> https://tools.ietf.org/html/rfc7983 > >>>> > >>>> Then of course there also has to be a way to bypass DTLS when sending > >>>> data... maybe send/3 (Socket, Data, Options)... > >>>> > >>> > >>> Maybe transport_send as compared to the existing transport_accept. > Would only work for DTLS. > >>> > >>> Regards Ingela Erlang/OTP team - Ericsson AB > >>> > >>>> > >>>> What do you think? > >>>> > >>>> > >>>> --Albin > >>>> > >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin > wrote: > >>>> > > >>>> > Hi! > >>>> > > >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < > albin.stigo@REDACTED>: > >>>> >> > >>>> >> Hi, > >>>> >> > >>>> >> I'm working on an Erlang WebRTC peer client (to send audio/video to > >>>> >> the browser). > >>>> >> > >>>> >> WebRTC requires dtls-srtp and that in turn requires: > >>>> >> > >>>> >> 1. The use_srtp extension for key exchange. > >>>> > > >>>> > > >>>> > We will be implementing this as part of TLS-1.3 that we are > currently working on, and we will have something runnable for OTP-22.0, > although we are not promising that it will complete or that use_srtp will > be part of OTP-22.0 > >>>> > > >>>> > > >>>> >> > >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. > >>>> >> > >>>> >> I know there's been work towards use_srtp and it's even in the > source, > >>>> >> but commented out. Ingela has been working on it for OTP 2, I > believe, > >>>> >> is there an ETA on this feature? > >>>> > > >>>> > > >>>> >> > >>>> >> > >>>> >> > >>>> >> Is multiplexing on the DTLS socket already possible using the > cb_info? > >>>> >> Has anyone tried that? > >>>> >> > >>>> >> > http://erlang.org/pipermail/erlang-questions/2018-October/096457.html > >>>> >> > >>>> > > >>>> > The code has been written to make such extensions possible. There > might be a need for more callbacks. I have not really had time to work on > that as > >>>> > TLS-1.3, optimizations and erlang distribution over TLS has been > prioritized higher. Suggestions are welcome. > >>>> > > >>>> > Regards Ingela Erlang/OTP team - Ericsson AB > >>>> > > >>>> > > >>>> > > >>>> > > >>>> >> > >>>> >> > >>>> >> --Albin > >>>> >> _______________________________________________ > >>>> >> erlang-questions mailing list > >>>> >> erlang-questions@REDACTED > >>>> >> http://erlang.org/mailman/listinfo/erlang-questions > >>> > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questions@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > >> > >> -- > >> -- > >> Dipl.-Inform. Andreas Schultz > >> > >> ----------------------- enabling your networks ---------------------- > >> Travelping GmbH Phone: +49-391-81 90 99 0 > >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 > <+49%20391%20819099299> > >> 39108 Magdeburg Email: info@REDACTED > >> GERMANY Web: http://www.travelping.com > >> > >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > >> --------------------------------------------------------------------- > -- -- Dipl.-Inform. Andreas Schultz ----------------------- enabling your networks ---------------------- Travelping GmbH Phone: +49-391-81 90 99 0 Roentgenstr. 13 Fax: +49-391-81 90 99 299 39108 Magdeburg Email: info@REDACTED GERMANY Web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Fri Mar 15 13:10:41 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Fri, 15 Mar 2019 13:10:41 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: There're all kinds of abuse of DTLS it seems :-) I still think the use cases are orthogonal though... Demuxing as described in https://tools.ietf.org/html/rfc7983 is trivial and requires no state. A demux_fun would solve that problem. DTLS packets wrapped in extra headers with the need of state information is much more complicated... Maybe what is needed are two different approaches? Especially since you will need forward and backwards transform..? Ingela, is there already an API for getting the key data from use_srtp (when implemented) or will that have to be added also? --Albin On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz wrote: > > Albin Stig? schrieb am Do., 14. M?rz 2019 um 18:49 Uhr: >> >> Hi Ingela and Andreas, >> >> > No, that's not enough. Some protocols put additional headers in front of the DTLS packets. So there needs to be a way to strip >> > headers on Rx and add it on Tx (with session information if needed). >> >> I have to admit I have not encountered this practice... do you have a >> particular protocol in mind or is it a part of dtls-srtp I have >> missed? One could argue that if you add additional headers and >> maintain some kind of state you are actually dealing with a different >> transport layer...? > > > CAPWAP is doing that https://tools.ietf.org/html/rfc5415#section-4.1 > >> I would very much like a way where filtered out packages were sent to >> the controlling process as {udp,Socket instead of {ssl, Socket... The >> question in the latter case is if Socket should be the ssl socket or >> the transport socket. Messing with the transport socket could be >> detrimental to dtls. >> >> One could also extend the filter_fun idea to a transform_fun where one >> could transform in packet in addition to demultiplexing, but like I >> said, I think additional headers to dtls packets belong to the >> transport layer. > > > Passing a State in and out of such a transform would be good. > > Andreas > >> >> >> I don't have in-depth knowledge of the ssl app but it seems adding a >> filter_fun would be almost trivial? >> >> > Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS. >> >> Well either that or some way of accessing the transport socket, but >> transport_send for sure plays well with existing API! >> >> >> --Albin >> >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin wrote: >> > >> > Hi! >> > >> > Andreas, see comment below. >> > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz : >> >> >> >> Hi >> >> >> >> Ingela Andin schrieb am Do., 14. M?rz 2019 um 17:34 Uhr: >> >>> >> >>> Hi Albin! >> >>> >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? : >> >>>> >> >>>> Hi Ingela, >> >>>> >> >>>> Thanks for the quick reply! >> >>>> >> >>>> While cb_info certainly is one way of doing it, it feels a bit >> >>>> complicated... specifically if switching between active and passive >> >>>> mode. Not sure if ssl ever use passive mode internally? Demuxing is a >> >>>> different use case, I think.. >> >>>> >> >>> >> >>> The cb_info is intended so that you may replace the transport layer, with most likely, an SCTP transport (can be done for both TLS and DTLS although there are some extensions needed for the DLTS version to work properly). I think some people also use it to implement WebSockets. >> >>> >> >>> ssl internally uses active n for TLS (since latest release) and active once for DTLS (we might change it) but an OTP supervised process will not use passive recv as we do not want it to block. >> >>> >> >>> >> >>>> >> >>>> Something that IMHO would be fantastic and simple (?) would be a >> >>>> dtls_filter_fun option. If true packet is passed up the ssl stack, >> >>>> otherwise passed on like a normal udp packet! >> >>>> >> >>> >> >>> Sounds reasonable. Otherwise sent to some other Erlang process than the "DTLS-connection" process that is. >> >> >> >> >> >> No, that's not enough. Some protocols put additional headers in front of the DTLS packets. So there needs to be a way to strip headers on Rx and add it on Tx (with session information if needed). >> >> >> > >> > Maybe the demultiplexor process can have a "packet mode" that is set to "no packet" default and needs a callback handler for anything else? >> > >> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >> > >> >> >> >> Andreas >> >> >> >>> >> >>> >> >>>> >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically >> >>>> boils down to looking at the first byte of the packet, if it's >> >>>> [20..63] it should be treated as DTLS otherwise something else. So >> >>>> this would be absolutely trivial to implement if there was a >> >>>> dtls_filter_fun... >> >>>> >> >>>> https://tools.ietf.org/html/rfc7983 >> >>>> >> >>>> Then of course there also has to be a way to bypass DTLS when sending >> >>>> data... maybe send/3 (Socket, Data, Options)... >> >>>> >> >>> >> >>> Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS. >> >>> >> >>> Regards Ingela Erlang/OTP team - Ericsson AB >> >>> >> >>>> >> >>>> What do you think? >> >>>> >> >>>> >> >>>> --Albin >> >>>> >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin wrote: >> >>>> > >> >>>> > Hi! >> >>>> > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? : >> >>>> >> >> >>>> >> Hi, >> >>>> >> >> >>>> >> I'm working on an Erlang WebRTC peer client (to send audio/video to >> >>>> >> the browser). >> >>>> >> >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: >> >>>> >> >> >>>> >> 1. The use_srtp extension for key exchange. >> >>>> > >> >>>> > >> >>>> > We will be implementing this as part of TLS-1.3 that we are currently working on, and we will have something runnable for OTP-22.0, although we are not promising that it will complete or that use_srtp will be part of OTP-22.0 >> >>>> > >> >>>> > >> >>>> >> >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >> >>>> >> >> >>>> >> I know there's been work towards use_srtp and it's even in the source, >> >>>> >> but commented out. Ingela has been working on it for OTP 2, I believe, >> >>>> >> is there an ETA on this feature? >> >>>> > >> >>>> > >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> Is multiplexing on the DTLS socket already possible using the cb_info? >> >>>> >> Has anyone tried that? >> >>>> >> >> >>>> >> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >> >>>> >> >> >>>> > >> >>>> > The code has been written to make such extensions possible. There might be a need for more callbacks. I have not really had time to work on that as >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS has been prioritized higher. Suggestions are welcome. >> >>>> > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> >> >> >>>> >> >> >>>> >> --Albin >> >>>> >> _______________________________________________ >> >>>> >> erlang-questions mailing list >> >>>> >> erlang-questions@REDACTED >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions >> >>> >> >>> _______________________________________________ >> >>> erlang-questions mailing list >> >>> erlang-questions@REDACTED >> >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> -- >> >> -- >> >> Dipl.-Inform. Andreas Schultz >> >> >> >> ----------------------- enabling your networks ---------------------- >> >> Travelping GmbH Phone: +49-391-81 90 99 0 >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 >> >> 39108 Magdeburg Email: info@REDACTED >> >> GERMANY Web: http://www.travelping.com >> >> >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 >> >> --------------------------------------------------------------------- > > -- > -- > Dipl.-Inform. Andreas Schultz > > ----------------------- enabling your networks ---------------------- > Travelping GmbH Phone: +49-391-81 90 99 0 > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > 39108 Magdeburg Email: info@REDACTED > GERMANY Web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > --------------------------------------------------------------------- From albin.stigo@REDACTED Fri Mar 15 13:20:35 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Fri, 15 Mar 2019 13:20:35 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Am I right to assume this is the single point of udp receive for dtls? https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906 --Albin On Fri, Mar 15, 2019 at 1:10 PM Albin Stig? wrote: > > There're all kinds of abuse of DTLS it seems :-) > > I still think the use cases are orthogonal though... Demuxing as > described in https://tools.ietf.org/html/rfc7983 is trivial and > requires no state. A demux_fun would solve that problem. > > DTLS packets wrapped in extra headers with the need of state > information is much more complicated... Maybe what is needed are two > different approaches? Especially since you will need forward and > backwards transform..? > > Ingela, is there already an API for getting the key data from use_srtp > (when implemented) or will that have to be added also? > > > --Albin > > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz > wrote: > > > > Albin Stig? schrieb am Do., 14. M?rz 2019 um 18:49 Uhr: > >> > >> Hi Ingela and Andreas, > >> > >> > No, that's not enough. Some protocols put additional headers in front of the DTLS packets. So there needs to be a way to strip > >> > headers on Rx and add it on Tx (with session information if needed). > >> > >> I have to admit I have not encountered this practice... do you have a > >> particular protocol in mind or is it a part of dtls-srtp I have > >> missed? One could argue that if you add additional headers and > >> maintain some kind of state you are actually dealing with a different > >> transport layer...? > > > > > > CAPWAP is doing that https://tools.ietf.org/html/rfc5415#section-4.1 > > > >> I would very much like a way where filtered out packages were sent to > >> the controlling process as {udp,Socket instead of {ssl, Socket... The > >> question in the latter case is if Socket should be the ssl socket or > >> the transport socket. Messing with the transport socket could be > >> detrimental to dtls. > >> > >> One could also extend the filter_fun idea to a transform_fun where one > >> could transform in packet in addition to demultiplexing, but like I > >> said, I think additional headers to dtls packets belong to the > >> transport layer. > > > > > > Passing a State in and out of such a transform would be good. > > > > Andreas > > > >> > >> > >> I don't have in-depth knowledge of the ssl app but it seems adding a > >> filter_fun would be almost trivial? > >> > >> > Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS. > >> > >> Well either that or some way of accessing the transport socket, but > >> transport_send for sure plays well with existing API! > >> > >> > >> --Albin > >> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin wrote: > >> > > >> > Hi! > >> > > >> > Andreas, see comment below. > >> > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz : > >> >> > >> >> Hi > >> >> > >> >> Ingela Andin schrieb am Do., 14. M?rz 2019 um 17:34 Uhr: > >> >>> > >> >>> Hi Albin! > >> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? : > >> >>>> > >> >>>> Hi Ingela, > >> >>>> > >> >>>> Thanks for the quick reply! > >> >>>> > >> >>>> While cb_info certainly is one way of doing it, it feels a bit > >> >>>> complicated... specifically if switching between active and passive > >> >>>> mode. Not sure if ssl ever use passive mode internally? Demuxing is a > >> >>>> different use case, I think.. > >> >>>> > >> >>> > >> >>> The cb_info is intended so that you may replace the transport layer, with most likely, an SCTP transport (can be done for both TLS and DTLS although there are some extensions needed for the DLTS version to work properly). I think some people also use it to implement WebSockets. > >> >>> > >> >>> ssl internally uses active n for TLS (since latest release) and active once for DTLS (we might change it) but an OTP supervised process will not use passive recv as we do not want it to block. > >> >>> > >> >>> > >> >>>> > >> >>>> Something that IMHO would be fantastic and simple (?) would be a > >> >>>> dtls_filter_fun option. If true packet is passed up the ssl stack, > >> >>>> otherwise passed on like a normal udp packet! > >> >>>> > >> >>> > >> >>> Sounds reasonable. Otherwise sent to some other Erlang process than the "DTLS-connection" process that is. > >> >> > >> >> > >> >> No, that's not enough. Some protocols put additional headers in front of the DTLS packets. So there needs to be a way to strip headers on Rx and add it on Tx (with session information if needed). > >> >> > >> > > >> > Maybe the demultiplexor process can have a "packet mode" that is set to "no packet" default and needs a callback handler for anything else? > >> > > >> > > >> > Regards Ingela Erlang/OTP team - Ericsson AB > >> > > >> >> > >> >> Andreas > >> >> > >> >>> > >> >>> > >> >>>> > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it basically > >> >>>> boils down to looking at the first byte of the packet, if it's > >> >>>> [20..63] it should be treated as DTLS otherwise something else. So > >> >>>> this would be absolutely trivial to implement if there was a > >> >>>> dtls_filter_fun... > >> >>>> > >> >>>> https://tools.ietf.org/html/rfc7983 > >> >>>> > >> >>>> Then of course there also has to be a way to bypass DTLS when sending > >> >>>> data... maybe send/3 (Socket, Data, Options)... > >> >>>> > >> >>> > >> >>> Maybe transport_send as compared to the existing transport_accept. Would only work for DTLS. > >> >>> > >> >>> Regards Ingela Erlang/OTP team - Ericsson AB > >> >>> > >> >>>> > >> >>>> What do you think? > >> >>>> > >> >>>> > >> >>>> --Albin > >> >>>> > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin wrote: > >> >>>> > > >> >>>> > Hi! > >> >>>> > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? : > >> >>>> >> > >> >>>> >> Hi, > >> >>>> >> > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send audio/video to > >> >>>> >> the browser). > >> >>>> >> > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: > >> >>>> >> > >> >>>> >> 1. The use_srtp extension for key exchange. > >> >>>> > > >> >>>> > > >> >>>> > We will be implementing this as part of TLS-1.3 that we are currently working on, and we will have something runnable for OTP-22.0, although we are not promising that it will complete or that use_srtp will be part of OTP-22.0 > >> >>>> > > >> >>>> > > >> >>>> >> > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. > >> >>>> >> > >> >>>> >> I know there's been work towards use_srtp and it's even in the source, > >> >>>> >> but commented out. Ingela has been working on it for OTP 2, I believe, > >> >>>> >> is there an ETA on this feature? > >> >>>> > > >> >>>> > > >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> Is multiplexing on the DTLS socket already possible using the cb_info? > >> >>>> >> Has anyone tried that? > >> >>>> >> > >> >>>> >> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html > >> >>>> >> > >> >>>> > > >> >>>> > The code has been written to make such extensions possible. There might be a need for more callbacks. I have not really had time to work on that as > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS has been prioritized higher. Suggestions are welcome. > >> >>>> > > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> >> > >> >>>> >> > >> >>>> >> --Albin > >> >>>> >> _______________________________________________ > >> >>>> >> erlang-questions mailing list > >> >>>> >> erlang-questions@REDACTED > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions > >> >>> > >> >>> _______________________________________________ > >> >>> erlang-questions mailing list > >> >>> erlang-questions@REDACTED > >> >>> http://erlang.org/mailman/listinfo/erlang-questions > >> >> > >> >> -- > >> >> -- > >> >> Dipl.-Inform. Andreas Schultz > >> >> > >> >> ----------------------- enabling your networks ---------------------- > >> >> Travelping GmbH Phone: +49-391-81 90 99 0 > >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 > >> >> 39108 Magdeburg Email: info@REDACTED > >> >> GERMANY Web: http://www.travelping.com > >> >> > >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > >> >> --------------------------------------------------------------------- > > > > -- > > -- > > Dipl.-Inform. Andreas Schultz > > > > ----------------------- enabling your networks ---------------------- > > Travelping GmbH Phone: +49-391-81 90 99 0 > > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > > 39108 Magdeburg Email: info@REDACTED > > GERMANY Web: http://www.travelping.com > > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > --------------------------------------------------------------------- From rickard@REDACTED Fri Mar 15 16:11:48 2019 From: rickard@REDACTED (Rickard Green) Date: Fri, 15 Mar 2019 16:11:48 +0100 Subject: [erlang-questions] Erlang 21.3: erl_call crashing In-Reply-To: References: Message-ID: On Fri, Mar 15, 2019 at 6:35 AM Frank Muller wrote: > > Hi guys > > We switched to 21.3 to generate our release and noticed that we can?t use erl_call shipped with 21.3 anymore. It always crashes with SIGSEGV. > > Simply overwriting the erl_call binary with the one from 21.2.4 fixed the problem even in release generated with 21.3. > > Any idea? Did the Erlang team change erl_call in 21.3? > > /Frank > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Please try fix in pull request 2183 . Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Mar 15 16:16:18 2019 From: erlang@REDACTED (Robert Carbone) Date: Fri, 15 Mar 2019 11:16:18 -0400 Subject: [erlang-questions] Good form In-Reply-To: <20190314223550.GC10520@carfax.org.uk> References: <63ed714d-6084-fff7-930a-1a1e4f29e67a@aim.com> <20190314223550.GC10520@carfax.org.uk> Message-ID: <30eb166c-1469-d138-5c6f-147ce618c4a2@scriptculture.com> I couldn't agree more with Hugo & Richard - We are programming in a high level language here; you shouldn't be trying to compact your code unless you are /trying /to obfuscate it. And as far as I understand it,*the compiler is going to make those substitution optimizations for you*. http://blog.erlang.org/core-erlang-optimizations/ So absolutely, line up your variables nicely,? give them good names, keep things in short & make it readable. Other peeps, & more probably your future-self, will thank you. All this is great Erlang coding technique and solid habits to be forming. - Rob C. /scriptculture.com / On 3/14/19 6:35 PM, Hugo Mills wrote: > On Thu, Mar 14, 2019 at 06:12:35PM -0400, Donald Steven wrote: >> Sometimes, when a variable is bound then used only once in a >> function call, it seems easier just to just use what it is bound to >> directly in the function call, bypassing the first step. >> >> Here's an example: >> >> getSound(Event) ->element(evaluate:probableElement(evaluate:probabilities(maps:get(elementTag, >> Event))), >> hd(lists:nth(maps:get(templateTag, Event), >> agitatedSoundResources(maps:get(scalarTag, Event), >> maps:get(registerTag, >> Event), maps:get(transpositionTag, Event))))). >> >> Alternatively, I could have declared, for example, a raft of >> variable like ElementNumber, ElementTag, TemplateTag, etc. >> >> I realize that this all-in-one-compact version tends towards >> inscrutabel c code liek &X++ ?. >> >> How do you approach the temptation to avoid discrete steps in favor >> of compactness? > I don't find it tempting at all. :) > > The discrete steps can be useful documentation, because you can > give the interim variables meaningful names, explaining (a little) > what it is that you're doing. > > It also helps to break up the calls for formatting and readability, > particularly if you have functions with multiple parameters in the > sequence. > > Hugo. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Fri Mar 15 17:01:23 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Fri, 15 Mar 2019 17:01:23 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi Albin! There is the handshake_compleation option together with the handshake_continue functions that let you pause the handshake and retrieve the hello extensions and possibly provide more options before continuing the handshake. Den fre 15 mars 2019 kl 13:20 skrev Albin Stig? : > Am I right to assume this is the single point of udp receive for dtls? > > > https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906 > > > If you want to multiplex UDP packets to other processes than the DTLS connection process that is not encrypted under DTLS you should not look at the DTLS connection process but at the https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140 Regards Ingela Erlang/OTP team Ericsson AB > --Albin > > On Fri, Mar 15, 2019 at 1:10 PM Albin Stig? wrote: > > > > There're all kinds of abuse of DTLS it seems :-) > > > > I still think the use cases are orthogonal though... Demuxing as > > described in https://tools.ietf.org/html/rfc7983 is trivial and > > requires no state. A demux_fun would solve that problem. > > > > DTLS packets wrapped in extra headers with the need of state > > information is much more complicated... Maybe what is needed are two > > different approaches? Especially since you will need forward and > > backwards transform..? > > > > Ingela, is there already an API for getting the key data from use_srtp > > (when implemented) or will that have to be added also? > > > > > > --Albin > > > > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz > > wrote: > > > > > > Albin Stig? schrieb am Do., 14. M?rz 2019 um > 18:49 Uhr: > > >> > > >> Hi Ingela and Andreas, > > >> > > >> > No, that's not enough. Some protocols put additional headers in > front of the DTLS packets. So there needs to be a way to strip > > >> > headers on Rx and add it on Tx (with session information if needed). > > >> > > >> I have to admit I have not encountered this practice... do you have a > > >> particular protocol in mind or is it a part of dtls-srtp I have > > >> missed? One could argue that if you add additional headers and > > >> maintain some kind of state you are actually dealing with a different > > >> transport layer...? > > > > > > > > > CAPWAP is doing that https://tools.ietf.org/html/rfc5415#section-4.1 > > > > > >> I would very much like a way where filtered out packages were sent to > > >> the controlling process as {udp,Socket instead of {ssl, Socket... The > > >> question in the latter case is if Socket should be the ssl socket or > > >> the transport socket. Messing with the transport socket could be > > >> detrimental to dtls. > > >> > > >> One could also extend the filter_fun idea to a transform_fun where one > > >> could transform in packet in addition to demultiplexing, but like I > > >> said, I think additional headers to dtls packets belong to the > > >> transport layer. > > > > > > > > > Passing a State in and out of such a transform would be good. > > > > > > Andreas > > > > > >> > > >> > > >> I don't have in-depth knowledge of the ssl app but it seems adding a > > >> filter_fun would be almost trivial? > > >> > > >> > Maybe transport_send as compared to the existing transport_accept. > Would only work for DTLS. > > >> > > >> Well either that or some way of accessing the transport socket, but > > >> transport_send for sure plays well with existing API! > > >> > > >> > > >> --Albin > > >> > > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin > wrote: > > >> > > > >> > Hi! > > >> > > > >> > Andreas, see comment below. > > >> > > > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < > andreas.schultz@REDACTED>: > > >> >> > > >> >> Hi > > >> >> > > >> >> Ingela Andin schrieb am Do., 14. M?rz > 2019 um 17:34 Uhr: > > >> >>> > > >> >>> Hi Albin! > > >> >>> > > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? < > albin.stigo@REDACTED>: > > >> >>>> > > >> >>>> Hi Ingela, > > >> >>>> > > >> >>>> Thanks for the quick reply! > > >> >>>> > > >> >>>> While cb_info certainly is one way of doing it, it feels a bit > > >> >>>> complicated... specifically if switching between active and > passive > > >> >>>> mode. Not sure if ssl ever use passive mode internally? Demuxing > is a > > >> >>>> different use case, I think.. > > >> >>>> > > >> >>> > > >> >>> The cb_info is intended so that you may replace the transport > layer, with most likely, an SCTP transport (can be done for both TLS and > DTLS although there are some extensions needed for the DLTS version to work > properly). I think some people also use it to implement WebSockets. > > >> >>> > > >> >>> ssl internally uses active n for TLS (since latest release) and > active once for DTLS (we might change it) but an OTP supervised process > will not use passive recv as we do not want it to block. > > >> >>> > > >> >>> > > >> >>>> > > >> >>>> Something that IMHO would be fantastic and simple (?) would be a > > >> >>>> dtls_filter_fun option. If true packet is passed up the ssl > stack, > > >> >>>> otherwise passed on like a normal udp packet! > > >> >>>> > > >> >>> > > >> >>> Sounds reasonable. Otherwise sent to some other Erlang process > than the "DTLS-connection" process that is. > > >> >> > > >> >> > > >> >> No, that's not enough. Some protocols put additional headers in > front of the DTLS packets. So there needs to be a way to strip headers on > Rx and add it on Tx (with session information if needed). > > >> >> > > >> > > > >> > Maybe the demultiplexor process can have a "packet mode" that is > set to "no packet" default and needs a callback handler for anything else? > > >> > > > >> > > > >> > Regards Ingela Erlang/OTP team - Ericsson AB > > >> > > > >> >> > > >> >> Andreas > > >> >> > > >> >>> > > >> >>> > > >> >>>> > > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it > basically > > >> >>>> boils down to looking at the first byte of the packet, if it's > > >> >>>> [20..63] it should be treated as DTLS otherwise something else. > So > > >> >>>> this would be absolutely trivial to implement if there was a > > >> >>>> dtls_filter_fun... > > >> >>>> > > >> >>>> https://tools.ietf.org/html/rfc7983 > > >> >>>> > > >> >>>> Then of course there also has to be a way to bypass DTLS when > sending > > >> >>>> data... maybe send/3 (Socket, Data, Options)... > > >> >>>> > > >> >>> > > >> >>> Maybe transport_send as compared to the existing > transport_accept. Would only work for DTLS. > > >> >>> > > >> >>> Regards Ingela Erlang/OTP team - Ericsson AB > > >> >>> > > >> >>>> > > >> >>>> What do you think? > > >> >>>> > > >> >>>> > > >> >>>> --Albin > > >> >>>> > > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin < > ingela.andin@REDACTED> wrote: > > >> >>>> > > > >> >>>> > Hi! > > >> >>>> > > > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < > albin.stigo@REDACTED>: > > >> >>>> >> > > >> >>>> >> Hi, > > >> >>>> >> > > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send > audio/video to > > >> >>>> >> the browser). > > >> >>>> >> > > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: > > >> >>>> >> > > >> >>>> >> 1. The use_srtp extension for key exchange. > > >> >>>> > > > >> >>>> > > > >> >>>> > We will be implementing this as part of TLS-1.3 that we are > currently working on, and we will have something runnable for OTP-22.0, > although we are not promising that it will complete or that use_srtp will > be part of OTP-22.0 > > >> >>>> > > > >> >>>> > > > >> >>>> >> > > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. > > >> >>>> >> > > >> >>>> >> I know there's been work towards use_srtp and it's even in > the source, > > >> >>>> >> but commented out. Ingela has been working on it for OTP 2, I > believe, > > >> >>>> >> is there an ETA on this feature? > > >> >>>> > > > >> >>>> > > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> Is multiplexing on the DTLS socket already possible using the > cb_info? > > >> >>>> >> Has anyone tried that? > > >> >>>> >> > > >> >>>> >> > http://erlang.org/pipermail/erlang-questions/2018-October/096457.html > > >> >>>> >> > > >> >>>> > > > >> >>>> > The code has been written to make such extensions possible. > There might be a need for more callbacks. I have not really had time to > work on that as > > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS has > been prioritized higher. Suggestions are welcome. > > >> >>>> > > > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB > > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>> >> > > >> >>>> >> > > >> >>>> >> --Albin > > >> >>>> >> _______________________________________________ > > >> >>>> >> erlang-questions mailing list > > >> >>>> >> erlang-questions@REDACTED > > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions > > >> >>> > > >> >>> _______________________________________________ > > >> >>> erlang-questions mailing list > > >> >>> erlang-questions@REDACTED > > >> >>> http://erlang.org/mailman/listinfo/erlang-questions > > >> >> > > >> >> -- > > >> >> -- > > >> >> Dipl.-Inform. Andreas Schultz > > >> >> > > >> >> ----------------------- enabling your networks > ---------------------- > > >> >> Travelping GmbH Phone: +49-391-81 90 99 0 > > >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 > > >> >> 39108 Magdeburg Email: info@REDACTED > > >> >> GERMANY Web: > http://www.travelping.com > > >> >> > > >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB > 10578 > > >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: > DE236673780 > > >> >> > --------------------------------------------------------------------- > > > > > > -- > > > -- > > > Dipl.-Inform. Andreas Schultz > > > > > > ----------------------- enabling your networks ---------------------- > > > Travelping GmbH Phone: +49-391-81 90 99 0 > > > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > > > 39108 Magdeburg Email: info@REDACTED > > > GERMANY Web: http://www.travelping.com > > > > > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > > > --------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t6sn7gt@REDACTED Fri Mar 15 17:01:40 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Fri, 15 Mar 2019 12:01:40 -0400 Subject: [erlang-questions] Good form In-Reply-To: <30eb166c-1469-d138-5c6f-147ce618c4a2@scriptculture.com> References: <63ed714d-6084-fff7-930a-1a1e4f29e67a@aim.com> <20190314223550.GC10520@carfax.org.uk> <30eb166c-1469-d138-5c6f-147ce618c4a2@scriptculture.com> Message-ID: <9c7ddf18-46f0-5382-22ff-dcbd82249a41@aim.com> Thanks everyone, much appreciated. Don On 3/15/2019 11.16 AM, Robert Carbone wrote: > > I couldn't agree more with Hugo & Richard - > > We are programming in a high level language here; you shouldn't be > trying to compact your code unless you are /trying /to obfuscate it. > > And as far as I understand it,*the compiler is going to make those > substitution optimizations for you*. > > http://blog.erlang.org/core-erlang-optimizations/ > > So absolutely, line up your variables nicely,? give them good names, > keep things in short & make it readable. > Other peeps, & more probably your future-self, will thank you. > > All this is great Erlang coding technique and solid habits to be forming. > > - Rob C. > /scriptculture.com / > > > > On 3/14/19 6:35 PM, Hugo Mills wrote: >> On Thu, Mar 14, 2019 at 06:12:35PM -0400, Donald Steven wrote: >>> Sometimes, when a variable is bound then used only once in a >>> function call, it seems easier just to just use what it is bound to >>> directly in the function call, bypassing the first step. >>> >>> Here's an example: >>> >>> getSound(Event) ->element(evaluate:probableElement(evaluate:probabilities(maps:get(elementTag, >>> Event))), >>> hd(lists:nth(maps:get(templateTag, Event), >>> agitatedSoundResources(maps:get(scalarTag, Event), >>> maps:get(registerTag, >>> Event),maps:get(transpositionTag, Event))))). >>> >>> Alternatively, I could have declared, for example, a raft of >>> variable like ElementNumber, ElementTag, TemplateTag, etc. >>> >>> I realize that this all-in-one-compact version tends towards >>> inscrutabel c code liek &X++ ?. >>> >>> How do you approach the temptation to avoid discrete steps in favor >>> of compactness? >> I don't find it tempting at all. :) >> >> The discrete steps can be useful documentation, because you can >> give the interim variables meaningful names, explaining (a little) >> what it is that you're doing. >> >> It also helps to break up the calls for formatting and readability, >> particularly if you have functions with multiple parameters in the >> sequence. >> >> Hugo. >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Fri Mar 15 17:25:42 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Fri, 15 Mar 2019 17:25:42 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Ok thanks! Maybe demultiplexing should just be default when the use_srtp extension is used, since that's how it's supposed to be used anyway... or a rfc7983_demux option... What's the name in the #state that holds the pid of the controlling process (the process that receives {ssl.. data)? --Albin On Fri, Mar 15, 2019, 17:01 Ingela Andin wrote: > Hi Albin! > > There is the handshake_compleation option together with the > handshake_continue functions that let you pause the handshake and retrieve > the hello extensions and possibly provide more options before continuing > the handshake. > > Den fre 15 mars 2019 kl 13:20 skrev Albin Stig? : > >> Am I right to assume this is the single point of udp receive for dtls? >> >> >> https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906 >> >> >> > If you want to multiplex UDP packets to other processes than the DTLS > connection process that is not encrypted under DTLS you > should not look at the DTLS connection process but at the > > > https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140 > > Regards Ingela Erlang/OTP team Ericsson AB > > >> --Albin >> >> On Fri, Mar 15, 2019 at 1:10 PM Albin Stig? >> wrote: >> > >> > There're all kinds of abuse of DTLS it seems :-) >> > >> > I still think the use cases are orthogonal though... Demuxing as >> > described in https://tools.ietf.org/html/rfc7983 is trivial and >> > requires no state. A demux_fun would solve that problem. >> > >> > DTLS packets wrapped in extra headers with the need of state >> > information is much more complicated... Maybe what is needed are two >> > different approaches? Especially since you will need forward and >> > backwards transform..? >> > >> > Ingela, is there already an API for getting the key data from use_srtp >> > (when implemented) or will that have to be added also? >> > >> > >> > --Albin >> > >> > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz >> > wrote: >> > > >> > > Albin Stig? schrieb am Do., 14. M?rz 2019 um >> 18:49 Uhr: >> > >> >> > >> Hi Ingela and Andreas, >> > >> >> > >> > No, that's not enough. Some protocols put additional headers in >> front of the DTLS packets. So there needs to be a way to strip >> > >> > headers on Rx and add it on Tx (with session information if >> needed). >> > >> >> > >> I have to admit I have not encountered this practice... do you have a >> > >> particular protocol in mind or is it a part of dtls-srtp I have >> > >> missed? One could argue that if you add additional headers and >> > >> maintain some kind of state you are actually dealing with a different >> > >> transport layer...? >> > > >> > > >> > > CAPWAP is doing that https://tools.ietf.org/html/rfc5415#section-4.1 >> > > >> > >> I would very much like a way where filtered out packages were sent to >> > >> the controlling process as {udp,Socket instead of {ssl, Socket... The >> > >> question in the latter case is if Socket should be the ssl socket or >> > >> the transport socket. Messing with the transport socket could be >> > >> detrimental to dtls. >> > >> >> > >> One could also extend the filter_fun idea to a transform_fun where >> one >> > >> could transform in packet in addition to demultiplexing, but like I >> > >> said, I think additional headers to dtls packets belong to the >> > >> transport layer. >> > > >> > > >> > > Passing a State in and out of such a transform would be good. >> > > >> > > Andreas >> > > >> > >> >> > >> >> > >> I don't have in-depth knowledge of the ssl app but it seems adding a >> > >> filter_fun would be almost trivial? >> > >> >> > >> > Maybe transport_send as compared to the existing >> transport_accept. Would only work for DTLS. >> > >> >> > >> Well either that or some way of accessing the transport socket, but >> > >> transport_send for sure plays well with existing API! >> > >> >> > >> >> > >> --Albin >> > >> >> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin >> wrote: >> > >> > >> > >> > Hi! >> > >> > >> > >> > Andreas, see comment below. >> > >> > >> > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < >> andreas.schultz@REDACTED>: >> > >> >> >> > >> >> Hi >> > >> >> >> > >> >> Ingela Andin schrieb am Do., 14. M?rz >> 2019 um 17:34 Uhr: >> > >> >>> >> > >> >>> Hi Albin! >> > >> >>> >> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? < >> albin.stigo@REDACTED>: >> > >> >>>> >> > >> >>>> Hi Ingela, >> > >> >>>> >> > >> >>>> Thanks for the quick reply! >> > >> >>>> >> > >> >>>> While cb_info certainly is one way of doing it, it feels a bit >> > >> >>>> complicated... specifically if switching between active and >> passive >> > >> >>>> mode. Not sure if ssl ever use passive mode internally? >> Demuxing is a >> > >> >>>> different use case, I think.. >> > >> >>>> >> > >> >>> >> > >> >>> The cb_info is intended so that you may replace the transport >> layer, with most likely, an SCTP transport (can be done for both TLS and >> DTLS although there are some extensions needed for the DLTS version to work >> properly). I think some people also use it to implement WebSockets. >> > >> >>> >> > >> >>> ssl internally uses active n for TLS (since latest release) and >> active once for DTLS (we might change it) but an OTP supervised process >> will not use passive recv as we do not want it to block. >> > >> >>> >> > >> >>> >> > >> >>>> >> > >> >>>> Something that IMHO would be fantastic and simple (?) would be a >> > >> >>>> dtls_filter_fun option. If true packet is passed up the ssl >> stack, >> > >> >>>> otherwise passed on like a normal udp packet! >> > >> >>>> >> > >> >>> >> > >> >>> Sounds reasonable. Otherwise sent to some other Erlang process >> than the "DTLS-connection" process that is. >> > >> >> >> > >> >> >> > >> >> No, that's not enough. Some protocols put additional headers in >> front of the DTLS packets. So there needs to be a way to strip headers on >> Rx and add it on Tx (with session information if needed). >> > >> >> >> > >> > >> > >> > Maybe the demultiplexor process can have a "packet mode" that is >> set to "no packet" default and needs a callback handler for anything else? >> > >> > >> > >> > >> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >> > >> > >> > >> >> >> > >> >> Andreas >> > >> >> >> > >> >>> >> > >> >>> >> > >> >>>> >> > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it >> basically >> > >> >>>> boils down to looking at the first byte of the packet, if it's >> > >> >>>> [20..63] it should be treated as DTLS otherwise something else. >> So >> > >> >>>> this would be absolutely trivial to implement if there was a >> > >> >>>> dtls_filter_fun... >> > >> >>>> >> > >> >>>> https://tools.ietf.org/html/rfc7983 >> > >> >>>> >> > >> >>>> Then of course there also has to be a way to bypass DTLS when >> sending >> > >> >>>> data... maybe send/3 (Socket, Data, Options)... >> > >> >>>> >> > >> >>> >> > >> >>> Maybe transport_send as compared to the existing >> transport_accept. Would only work for DTLS. >> > >> >>> >> > >> >>> Regards Ingela Erlang/OTP team - Ericsson AB >> > >> >>> >> > >> >>>> >> > >> >>>> What do you think? >> > >> >>>> >> > >> >>>> >> > >> >>>> --Albin >> > >> >>>> >> > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin < >> ingela.andin@REDACTED> wrote: >> > >> >>>> > >> > >> >>>> > Hi! >> > >> >>>> > >> > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < >> albin.stigo@REDACTED>: >> > >> >>>> >> >> > >> >>>> >> Hi, >> > >> >>>> >> >> > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send >> audio/video to >> > >> >>>> >> the browser). >> > >> >>>> >> >> > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: >> > >> >>>> >> >> > >> >>>> >> 1. The use_srtp extension for key exchange. >> > >> >>>> > >> > >> >>>> > >> > >> >>>> > We will be implementing this as part of TLS-1.3 that we are >> currently working on, and we will have something runnable for OTP-22.0, >> although we are not promising that it will complete or that use_srtp will >> be part of OTP-22.0 >> > >> >>>> > >> > >> >>>> > >> > >> >>>> >> >> > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >> > >> >>>> >> >> > >> >>>> >> I know there's been work towards use_srtp and it's even in >> the source, >> > >> >>>> >> but commented out. Ingela has been working on it for OTP 2, >> I believe, >> > >> >>>> >> is there an ETA on this feature? >> > >> >>>> > >> > >> >>>> > >> > >> >>>> >> >> > >> >>>> >> >> > >> >>>> >> >> > >> >>>> >> Is multiplexing on the DTLS socket already possible using >> the cb_info? >> > >> >>>> >> Has anyone tried that? >> > >> >>>> >> >> > >> >>>> >> >> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >> > >> >>>> >> >> > >> >>>> > >> > >> >>>> > The code has been written to make such extensions possible. >> There might be a need for more callbacks. I have not really had time to >> work on that as >> > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS has >> been prioritized higher. Suggestions are welcome. >> > >> >>>> > >> > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB >> > >> >>>> > >> > >> >>>> > >> > >> >>>> > >> > >> >>>> > >> > >> >>>> >> >> > >> >>>> >> >> > >> >>>> >> --Albin >> > >> >>>> >> _______________________________________________ >> > >> >>>> >> erlang-questions mailing list >> > >> >>>> >> erlang-questions@REDACTED >> > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions >> > >> >>> >> > >> >>> _______________________________________________ >> > >> >>> erlang-questions mailing list >> > >> >>> erlang-questions@REDACTED >> > >> >>> http://erlang.org/mailman/listinfo/erlang-questions >> > >> >> >> > >> >> -- >> > >> >> -- >> > >> >> Dipl.-Inform. Andreas Schultz >> > >> >> >> > >> >> ----------------------- enabling your networks >> ---------------------- >> > >> >> Travelping GmbH Phone: +49-391-81 90 99 0 >> > >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 >> > >> >> 39108 Magdeburg Email: info@REDACTED >> > >> >> GERMANY Web: >> http://www.travelping.com >> > >> >> >> > >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB >> 10578 >> > >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >> DE236673780 >> > >> >> >> --------------------------------------------------------------------- >> > > >> > > -- >> > > -- >> > > Dipl.-Inform. Andreas Schultz >> > > >> > > ----------------------- enabling your networks ---------------------- >> > > Travelping GmbH Phone: +49-391-81 90 99 0 >> > > Roentgenstr. 13 Fax: +49-391-81 90 99 299 >> > > 39108 Magdeburg Email: info@REDACTED >> > > GERMANY Web: http://www.travelping.com >> > > >> > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >> > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 >> > > --------------------------------------------------------------------- >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Fri Mar 15 18:14:01 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Fri, 15 Mar 2019 18:14:01 +0100 Subject: [erlang-questions] Erlang 21.3: erl_call crashing In-Reply-To: References: Message-ID: Hi Rickard Works perfectly. Thanks for the quick fix. /Frank On Fri, Mar 15, 2019 at 6:35 AM Frank Muller > wrote: > > > > Hi guys > > > > We switched to 21.3 to generate our release and noticed that we can?t > use erl_call shipped with 21.3 anymore. It always crashes with SIGSEGV. > > > > Simply overwriting the erl_call binary with the one from 21.2.4 fixed > the problem even in release generated with 21.3. > > > > Any idea? Did the Erlang team change erl_call in 21.3? > > > > /Frank > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > Please try fix in pull request 2183 < > https://github.com/erlang/otp/pull/2183>. > > Regards, > Rickard > -- > Rickard Green, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugo@REDACTED Fri Mar 15 23:52:09 2019 From: hugo@REDACTED (Hugo Mills) Date: Fri, 15 Mar 2019 22:52:09 +0000 Subject: [erlang-questions] String representations of floating point numbers Message-ID: <20190315225209.GD10520@carfax.org.uk> Where in the manual is the set of allowable string representations of floating point numbers documented? I'd have expected it to be here: http://erlang.org/doc/reference_manual/data_types.html ... but apparently not. Specifically, I'm trying to use list_to_float/1, and I've been trying to reverse engineer it: 1> list_to_float("-1"). ** exception error: bad argument in function list_to_float/1 called as list_to_float("-1") 2> list_to_float("-1.0"). -1.0 3> list_to_float("-1.0e-23"). -1.0e-23 4> list_to_float("-1e-23"). ** exception error: bad argument in function list_to_float/1 called as list_to_float("-1e-23") 5> list_to_float(".3"). ** exception error: bad argument in function list_to_float/1 called as list_to_float(".3") An actual written specification would be really handy here. Even just a regex or EBNF for them. I'm writing a parser for something where the definition of floating point literals isn't quite the same as Erlang's, and it's a bit painful. Hugo. -- Hugo Mills | Your problem is that you've got too much taste to be hugo@REDACTED carfax.org.uk | a web developer. http://carfax.org.uk/ | PGP: E2AB1DE4 | Steve Harris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bob@REDACTED Sat Mar 16 01:32:54 2019 From: bob@REDACTED (Bob Ippolito) Date: Fri, 15 Mar 2019 17:32:54 -0700 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: <20190315225209.GD10520@carfax.org.uk> References: <20190315225209.GD10520@carfax.org.uk> Message-ID: If you dive into the implementation it's effectively a wrapper around strtod from C with a validation pass that is more strict than the strtod standard. https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54 https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732 So as far as a regex goes it would be something like this: [+-]?\d+[.,]\d+([eE][+-]?\d+) The major differences between this and other popular float grammars are: * At least one digit is required in each part * Both integer and fractional parts are required, even if there's an exponent part (so "1", ".1", "1e-1" would not be valid) * The decimal separator is either , or . (the implementation will try the other if necessary to compensate for a different locale) On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills wrote: > Where in the manual is the set of allowable string representations > of floating point numbers documented? I'd have expected it to be here: > > http://erlang.org/doc/reference_manual/data_types.html > > ... but apparently not. > > Specifically, I'm trying to use list_to_float/1, and I've been > trying to reverse engineer it: > > 1> list_to_float("-1"). > ** exception error: bad argument > in function list_to_float/1 > called as list_to_float("-1") > 2> list_to_float("-1.0"). > -1.0 > 3> list_to_float("-1.0e-23"). > -1.0e-23 > 4> list_to_float("-1e-23"). > ** exception error: bad argument > in function list_to_float/1 > called as list_to_float("-1e-23") > 5> list_to_float(".3"). > ** exception error: bad argument > in function list_to_float/1 > called as list_to_float(".3") > > An actual written specification would be really handy here. Even > just a regex or EBNF for them. I'm writing a parser for something > where the definition of floating point literals isn't quite the same > as Erlang's, and it's a bit painful. > > Hugo. > > -- > Hugo Mills | Your problem is that you've got too much taste to > be > hugo@REDACTED carfax.org.uk | a web developer. > http://carfax.org.uk/ | > PGP: E2AB1DE4 | Steve > Harris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIbBAEBAgAGBQJcjCyYAAoJEFheFHXiqx3kBo8P+KYpzGUmaV4lA8jopR5h39S8 > XMt6e+mO4zceiz1LE9mGFozayPPgPlchuJz3h/9EgtvNKXV8AvUGLFOZHtcE5qeM > wDwQg6kreHW/5ejrpYFCH1rZt9DftnAzMQo0SXOCQTfLkAC5W/jRrZyAE8ibVEH+ > JoAOG/ZRUTz4E3bnoSGfcrY13IwD5A3sJ3Jex6rLttVjJyfCEbBJMx5ofFXO9WbY > PfggXSD7EALHdUOT1vQWJsRiJClq25HjAucblA+zst/8N1wllpRnK3uhA1M22lNB > OuYv0lnvKwYmyNSs/VcXRAne5CXjpf/CxJpVMuvXdbRYxrlsybWz9+UWMk7DB+TA > fQvCRIGROG/DlVWo8KAoMN6ZgfxE3pmVjfN3p2usDza2V43QAY+jaZF7x2SyxKxo > Bw4/jW7RODduzWu/XQvRX0780RQlbPbNcFjrOHIt3PZe7+Qtl++6QQcVCJ+TrE8h > 1drKkbFvm2/ecyAXdMkXV8CxiJdbgcSkz2kgIYhTUpiGJz0ubCt3HOA/byh3P8em > /5EhxuQQo5r+Yvn4rHkOIe2KBJuBHHhNky9f8xRU7j9JnxFvm6tQK8tJ4C3fIklI > yua+T9thS3XifUNiWTw/WX6CjSYVl2/lFtmzXYZ5+LiZgd4IImEHnXik/jOv/2eC > ayHhzl8YuA1yxsjULsw= > =Y3WO > -----END PGP SIGNATURE----- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Sat Mar 16 01:52:31 2019 From: bob@REDACTED (Bob Ippolito) Date: Fri, 15 Mar 2019 17:52:31 -0700 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: References: <20190315225209.GD10520@carfax.org.uk> Message-ID: There?s a typo in that regex, the exponent part is optional of course. [+-]?\d+[.,]\d+([eE][+-]?\d+)? On Fri, Mar 15, 2019 at 17:32 Bob Ippolito wrote: > If you dive into the implementation it's effectively a wrapper around > strtod from C with a validation pass that is more strict than the strtod > standard. > > > https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54 > > https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732 > > So as far as a regex goes it would be something like this: > > [+-]?\d+[.,]\d+([eE][+-]?\d+) > > The major differences between this and other popular float grammars are: > > * At least one digit is required in each part > * Both integer and fractional parts are required, even if there's an > exponent part (so "1", ".1", "1e-1" would not be valid) > * The decimal separator is either , or . (the implementation will try the > other if necessary to compensate for a different locale) > > > On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills wrote: > >> Where in the manual is the set of allowable string representations >> of floating point numbers documented? I'd have expected it to be here: >> >> http://erlang.org/doc/reference_manual/data_types.html >> >> ... but apparently not. >> >> Specifically, I'm trying to use list_to_float/1, and I've been >> trying to reverse engineer it: >> >> 1> list_to_float("-1"). >> ** exception error: bad argument >> in function list_to_float/1 >> called as list_to_float("-1") >> 2> list_to_float("-1.0"). >> -1.0 >> 3> list_to_float("-1.0e-23"). >> -1.0e-23 >> 4> list_to_float("-1e-23"). >> ** exception error: bad argument >> in function list_to_float/1 >> called as list_to_float("-1e-23") >> 5> list_to_float(".3"). >> ** exception error: bad argument >> in function list_to_float/1 >> called as list_to_float(".3") >> >> An actual written specification would be really handy here. Even >> just a regex or EBNF for them. I'm writing a parser for something >> where the definition of floating point literals isn't quite the same >> as Erlang's, and it's a bit painful. >> >> Hugo. >> >> -- >> Hugo Mills | Your problem is that you've got too much taste >> to be >> hugo@REDACTED carfax.org.uk | a web developer. >> http://carfax.org.uk/ | >> PGP: E2AB1DE4 | Steve >> Harris >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iQIbBAEBAgAGBQJcjCyYAAoJEFheFHXiqx3kBo8P+KYpzGUmaV4lA8jopR5h39S8 >> XMt6e+mO4zceiz1LE9mGFozayPPgPlchuJz3h/9EgtvNKXV8AvUGLFOZHtcE5qeM >> wDwQg6kreHW/5ejrpYFCH1rZt9DftnAzMQo0SXOCQTfLkAC5W/jRrZyAE8ibVEH+ >> JoAOG/ZRUTz4E3bnoSGfcrY13IwD5A3sJ3Jex6rLttVjJyfCEbBJMx5ofFXO9WbY >> PfggXSD7EALHdUOT1vQWJsRiJClq25HjAucblA+zst/8N1wllpRnK3uhA1M22lNB >> OuYv0lnvKwYmyNSs/VcXRAne5CXjpf/CxJpVMuvXdbRYxrlsybWz9+UWMk7DB+TA >> fQvCRIGROG/DlVWo8KAoMN6ZgfxE3pmVjfN3p2usDza2V43QAY+jaZF7x2SyxKxo >> Bw4/jW7RODduzWu/XQvRX0780RQlbPbNcFjrOHIt3PZe7+Qtl++6QQcVCJ+TrE8h >> 1drKkbFvm2/ecyAXdMkXV8CxiJdbgcSkz2kgIYhTUpiGJz0ubCt3HOA/byh3P8em >> /5EhxuQQo5r+Yvn4rHkOIe2KBJuBHHhNky9f8xRU7j9JnxFvm6tQK8tJ4C3fIklI >> yua+T9thS3XifUNiWTw/WX6CjSYVl2/lFtmzXYZ5+LiZgd4IImEHnXik/jOv/2eC >> ayHhzl8YuA1yxsjULsw= >> =Y3WO >> -----END PGP SIGNATURE----- >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Sat Mar 16 09:05:26 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Sat, 16 Mar 2019 09:05:26 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi Albin! Den fre 15 mars 2019 kl 17:25 skrev Albin Stig? : > Ok thanks! > > Maybe demultiplexing should just be default when the use_srtp extension is > used, since that's how it's supposed to be used anyway... or a > rfc7983_demux option... > > ? A DTLS server will always have a demultiplexing process as UDP does not have a connection concept. > What's the name in the #state that holds the pid of the controlling > process (the process that receives {ssl.. data)? > > It is part of the "user" in the state of the TLS/DTLS connection process. You should not have to care. You set the controlling process with ssl:controlling_process/2. I guess what you care about is the demultiplexing process and which Pid it sends the incoming UDP packets to. All the code is defined in the dtls_packet_demux.erl Regards Ingela Erlang/OTP team - Ericsson AB > --Albin > > On Fri, Mar 15, 2019, 17:01 Ingela Andin wrote: > >> Hi Albin! >> >> There is the handshake_compleation option together with the >> handshake_continue functions that let you pause the handshake and retrieve >> the hello extensions and possibly provide more options before continuing >> the handshake. >> >> Den fre 15 mars 2019 kl 13:20 skrev Albin Stig? : >> >>> Am I right to assume this is the single point of udp receive for dtls? >>> >>> >>> https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906 >>> >>> >>> >> If you want to multiplex UDP packets to other processes than the DTLS >> connection process that is not encrypted under DTLS you >> should not look at the DTLS connection process but at the >> >> >> https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140 >> >> Regards Ingela Erlang/OTP team Ericsson AB >> >> >>> --Albin >>> >>> On Fri, Mar 15, 2019 at 1:10 PM Albin Stig? >>> wrote: >>> > >>> > There're all kinds of abuse of DTLS it seems :-) >>> > >>> > I still think the use cases are orthogonal though... Demuxing as >>> > described in https://tools.ietf.org/html/rfc7983 is trivial and >>> > requires no state. A demux_fun would solve that problem. >>> > >>> > DTLS packets wrapped in extra headers with the need of state >>> > information is much more complicated... Maybe what is needed are two >>> > different approaches? Especially since you will need forward and >>> > backwards transform..? >>> > >>> > Ingela, is there already an API for getting the key data from use_srtp >>> > (when implemented) or will that have to be added also? >>> > >>> > >>> > --Albin >>> > >>> > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz >>> > wrote: >>> > > >>> > > Albin Stig? schrieb am Do., 14. M?rz 2019 >>> um 18:49 Uhr: >>> > >> >>> > >> Hi Ingela and Andreas, >>> > >> >>> > >> > No, that's not enough. Some protocols put additional headers in >>> front of the DTLS packets. So there needs to be a way to strip >>> > >> > headers on Rx and add it on Tx (with session information if >>> needed). >>> > >> >>> > >> I have to admit I have not encountered this practice... do you have >>> a >>> > >> particular protocol in mind or is it a part of dtls-srtp I have >>> > >> missed? One could argue that if you add additional headers and >>> > >> maintain some kind of state you are actually dealing with a >>> different >>> > >> transport layer...? >>> > > >>> > > >>> > > CAPWAP is doing that https://tools.ietf.org/html/rfc5415#section-4.1 >>> > > >>> > >> I would very much like a way where filtered out packages were sent >>> to >>> > >> the controlling process as {udp,Socket instead of {ssl, Socket... >>> The >>> > >> question in the latter case is if Socket should be the ssl socket or >>> > >> the transport socket. Messing with the transport socket could be >>> > >> detrimental to dtls. >>> > >> >>> > >> One could also extend the filter_fun idea to a transform_fun where >>> one >>> > >> could transform in packet in addition to demultiplexing, but like I >>> > >> said, I think additional headers to dtls packets belong to the >>> > >> transport layer. >>> > > >>> > > >>> > > Passing a State in and out of such a transform would be good. >>> > > >>> > > Andreas >>> > > >>> > >> >>> > >> >>> > >> I don't have in-depth knowledge of the ssl app but it seems adding a >>> > >> filter_fun would be almost trivial? >>> > >> >>> > >> > Maybe transport_send as compared to the existing >>> transport_accept. Would only work for DTLS. >>> > >> >>> > >> Well either that or some way of accessing the transport socket, but >>> > >> transport_send for sure plays well with existing API! >>> > >> >>> > >> >>> > >> --Albin >>> > >> >>> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin < >>> ingela.andin@REDACTED> wrote: >>> > >> > >>> > >> > Hi! >>> > >> > >>> > >> > Andreas, see comment below. >>> > >> > >>> > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < >>> andreas.schultz@REDACTED>: >>> > >> >> >>> > >> >> Hi >>> > >> >> >>> > >> >> Ingela Andin schrieb am Do., 14. M?rz >>> 2019 um 17:34 Uhr: >>> > >> >>> >>> > >> >>> Hi Albin! >>> > >> >>> >>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? < >>> albin.stigo@REDACTED>: >>> > >> >>>> >>> > >> >>>> Hi Ingela, >>> > >> >>>> >>> > >> >>>> Thanks for the quick reply! >>> > >> >>>> >>> > >> >>>> While cb_info certainly is one way of doing it, it feels a bit >>> > >> >>>> complicated... specifically if switching between active and >>> passive >>> > >> >>>> mode. Not sure if ssl ever use passive mode internally? >>> Demuxing is a >>> > >> >>>> different use case, I think.. >>> > >> >>>> >>> > >> >>> >>> > >> >>> The cb_info is intended so that you may replace the transport >>> layer, with most likely, an SCTP transport (can be done for both TLS and >>> DTLS although there are some extensions needed for the DLTS version to work >>> properly). I think some people also use it to implement WebSockets. >>> > >> >>> >>> > >> >>> ssl internally uses active n for TLS (since latest release) and >>> active once for DTLS (we might change it) but an OTP supervised process >>> will not use passive recv as we do not want it to block. >>> > >> >>> >>> > >> >>> >>> > >> >>>> >>> > >> >>>> Something that IMHO would be fantastic and simple (?) would be >>> a >>> > >> >>>> dtls_filter_fun option. If true packet is passed up the ssl >>> stack, >>> > >> >>>> otherwise passed on like a normal udp packet! >>> > >> >>>> >>> > >> >>> >>> > >> >>> Sounds reasonable. Otherwise sent to some other Erlang process >>> than the "DTLS-connection" process that is. >>> > >> >> >>> > >> >> >>> > >> >> No, that's not enough. Some protocols put additional headers in >>> front of the DTLS packets. So there needs to be a way to strip headers on >>> Rx and add it on Tx (with session information if needed). >>> > >> >> >>> > >> > >>> > >> > Maybe the demultiplexor process can have a "packet mode" that is >>> set to "no packet" default and needs a callback handler for anything else? >>> > >> > >>> > >> > >>> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >>> > >> > >>> > >> >> >>> > >> >> Andreas >>> > >> >> >>> > >> >>> >>> > >> >>> >>> > >> >>>> >>> > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it >>> basically >>> > >> >>>> boils down to looking at the first byte of the packet, if it's >>> > >> >>>> [20..63] it should be treated as DTLS otherwise something >>> else. So >>> > >> >>>> this would be absolutely trivial to implement if there was a >>> > >> >>>> dtls_filter_fun... >>> > >> >>>> >>> > >> >>>> https://tools.ietf.org/html/rfc7983 >>> > >> >>>> >>> > >> >>>> Then of course there also has to be a way to bypass DTLS when >>> sending >>> > >> >>>> data... maybe send/3 (Socket, Data, Options)... >>> > >> >>>> >>> > >> >>> >>> > >> >>> Maybe transport_send as compared to the existing >>> transport_accept. Would only work for DTLS. >>> > >> >>> >>> > >> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> > >> >>> >>> > >> >>>> >>> > >> >>>> What do you think? >>> > >> >>>> >>> > >> >>>> >>> > >> >>>> --Albin >>> > >> >>>> >>> > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin < >>> ingela.andin@REDACTED> wrote: >>> > >> >>>> > >>> > >> >>>> > Hi! >>> > >> >>>> > >>> > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < >>> albin.stigo@REDACTED>: >>> > >> >>>> >> >>> > >> >>>> >> Hi, >>> > >> >>>> >> >>> > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send >>> audio/video to >>> > >> >>>> >> the browser). >>> > >> >>>> >> >>> > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: >>> > >> >>>> >> >>> > >> >>>> >> 1. The use_srtp extension for key exchange. >>> > >> >>>> > >>> > >> >>>> > >>> > >> >>>> > We will be implementing this as part of TLS-1.3 that we are >>> currently working on, and we will have something runnable for OTP-22.0, >>> although we are not promising that it will complete or that use_srtp will >>> be part of OTP-22.0 >>> > >> >>>> > >>> > >> >>>> > >>> > >> >>>> >> >>> > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >>> > >> >>>> >> >>> > >> >>>> >> I know there's been work towards use_srtp and it's even in >>> the source, >>> > >> >>>> >> but commented out. Ingela has been working on it for OTP 2, >>> I believe, >>> > >> >>>> >> is there an ETA on this feature? >>> > >> >>>> > >>> > >> >>>> > >>> > >> >>>> >> >>> > >> >>>> >> >>> > >> >>>> >> >>> > >> >>>> >> Is multiplexing on the DTLS socket already possible using >>> the cb_info? >>> > >> >>>> >> Has anyone tried that? >>> > >> >>>> >> >>> > >> >>>> >> >>> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >>> > >> >>>> >> >>> > >> >>>> > >>> > >> >>>> > The code has been written to make such extensions possible. >>> There might be a need for more callbacks. I have not really had time to >>> work on that as >>> > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS has >>> been prioritized higher. Suggestions are welcome. >>> > >> >>>> > >>> > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB >>> > >> >>>> > >>> > >> >>>> > >>> > >> >>>> > >>> > >> >>>> > >>> > >> >>>> >> >>> > >> >>>> >> >>> > >> >>>> >> --Albin >>> > >> >>>> >> _______________________________________________ >>> > >> >>>> >> erlang-questions mailing list >>> > >> >>>> >> erlang-questions@REDACTED >>> > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions >>> > >> >>> >>> > >> >>> _______________________________________________ >>> > >> >>> erlang-questions mailing list >>> > >> >>> erlang-questions@REDACTED >>> > >> >>> http://erlang.org/mailman/listinfo/erlang-questions >>> > >> >> >>> > >> >> -- >>> > >> >> -- >>> > >> >> Dipl.-Inform. Andreas Schultz >>> > >> >> >>> > >> >> ----------------------- enabling your networks >>> ---------------------- >>> > >> >> Travelping GmbH Phone: +49-391-81 90 99 0 >>> > >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 >>> > >> >> 39108 Magdeburg Email: info@REDACTED >>> > >> >> GERMANY Web: >>> http://www.travelping.com >>> > >> >> >>> > >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB >>> 10578 >>> > >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>> DE236673780 >>> > >> >> >>> --------------------------------------------------------------------- >>> > > >>> > > -- >>> > > -- >>> > > Dipl.-Inform. Andreas Schultz >>> > > >>> > > ----------------------- enabling your networks ---------------------- >>> > > Travelping GmbH Phone: +49-391-81 90 99 0 >>> > > Roentgenstr. 13 Fax: +49-391-81 90 99 299 >>> > > 39108 Magdeburg Email: info@REDACTED >>> > > GERMANY Web: >>> http://www.travelping.com >>> > > >>> > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >>> > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 >>> > > --------------------------------------------------------------------- >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Sat Mar 16 10:21:22 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Sat, 16 Mar 2019 10:21:22 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Ok sorry about the confusion. What's needed is a second level of demultiplexing after the first... But I realize now this will be very difficult to achieve with the current implementation because that relies on one socket per connection. Otherwise you won't know which process to send the none DTLS packets to... Or am i missing something? I might have to attempt a separate DTLS use_srtp app just for this application... --Albin On Sat, Mar 16, 2019, 09:05 Ingela Andin wrote: > Hi Albin! > > Den fre 15 mars 2019 kl 17:25 skrev Albin Stig? : > >> Ok thanks! >> >> Maybe demultiplexing should just be default when the use_srtp extension >> is used, since that's how it's supposed to be used anyway... or a >> rfc7983_demux option... >> >> > ? A DTLS server will always have a demultiplexing process as UDP does not > have a connection concept. > > > >> What's the name in the #state that holds the pid of the controlling >> process (the process that receives {ssl.. data)? >> >> > It is part of the "user" in the state of the TLS/DTLS connection process. > You should not have to care. You set the controlling process with > ssl:controlling_process/2. > > I guess what you care about is the demultiplexing process and which Pid it > sends the incoming UDP packets to. All the code is defined in the > dtls_packet_demux.erl > > Regards Ingela Erlang/OTP team - Ericsson AB > > >> --Albin >> >> On Fri, Mar 15, 2019, 17:01 Ingela Andin wrote: >> >>> Hi Albin! >>> >>> There is the handshake_compleation option together with the >>> handshake_continue functions that let you pause the handshake and retrieve >>> the hello extensions and possibly provide more options before continuing >>> the handshake. >>> >>> Den fre 15 mars 2019 kl 13:20 skrev Albin Stig? : >>> >>>> Am I right to assume this is the single point of udp receive for dtls? >>>> >>>> >>>> https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906 >>>> >>>> >>>> >>> If you want to multiplex UDP packets to other processes than the DTLS >>> connection process that is not encrypted under DTLS you >>> should not look at the DTLS connection process but at the >>> >>> >>> https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140 >>> >>> Regards Ingela Erlang/OTP team Ericsson AB >>> >>> >>>> --Albin >>>> >>>> On Fri, Mar 15, 2019 at 1:10 PM Albin Stig? >>>> wrote: >>>> > >>>> > There're all kinds of abuse of DTLS it seems :-) >>>> > >>>> > I still think the use cases are orthogonal though... Demuxing as >>>> > described in https://tools.ietf.org/html/rfc7983 is trivial and >>>> > requires no state. A demux_fun would solve that problem. >>>> > >>>> > DTLS packets wrapped in extra headers with the need of state >>>> > information is much more complicated... Maybe what is needed are two >>>> > different approaches? Especially since you will need forward and >>>> > backwards transform..? >>>> > >>>> > Ingela, is there already an API for getting the key data from use_srtp >>>> > (when implemented) or will that have to be added also? >>>> > >>>> > >>>> > --Albin >>>> > >>>> > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz >>>> > wrote: >>>> > > >>>> > > Albin Stig? schrieb am Do., 14. M?rz 2019 >>>> um 18:49 Uhr: >>>> > >> >>>> > >> Hi Ingela and Andreas, >>>> > >> >>>> > >> > No, that's not enough. Some protocols put additional headers in >>>> front of the DTLS packets. So there needs to be a way to strip >>>> > >> > headers on Rx and add it on Tx (with session information if >>>> needed). >>>> > >> >>>> > >> I have to admit I have not encountered this practice... do you >>>> have a >>>> > >> particular protocol in mind or is it a part of dtls-srtp I have >>>> > >> missed? One could argue that if you add additional headers and >>>> > >> maintain some kind of state you are actually dealing with a >>>> different >>>> > >> transport layer...? >>>> > > >>>> > > >>>> > > CAPWAP is doing that >>>> https://tools.ietf.org/html/rfc5415#section-4.1 >>>> > > >>>> > >> I would very much like a way where filtered out packages were sent >>>> to >>>> > >> the controlling process as {udp,Socket instead of {ssl, Socket... >>>> The >>>> > >> question in the latter case is if Socket should be the ssl socket >>>> or >>>> > >> the transport socket. Messing with the transport socket could be >>>> > >> detrimental to dtls. >>>> > >> >>>> > >> One could also extend the filter_fun idea to a transform_fun where >>>> one >>>> > >> could transform in packet in addition to demultiplexing, but like I >>>> > >> said, I think additional headers to dtls packets belong to the >>>> > >> transport layer. >>>> > > >>>> > > >>>> > > Passing a State in and out of such a transform would be good. >>>> > > >>>> > > Andreas >>>> > > >>>> > >> >>>> > >> >>>> > >> I don't have in-depth knowledge of the ssl app but it seems adding >>>> a >>>> > >> filter_fun would be almost trivial? >>>> > >> >>>> > >> > Maybe transport_send as compared to the existing >>>> transport_accept. Would only work for DTLS. >>>> > >> >>>> > >> Well either that or some way of accessing the transport socket, but >>>> > >> transport_send for sure plays well with existing API! >>>> > >> >>>> > >> >>>> > >> --Albin >>>> > >> >>>> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin < >>>> ingela.andin@REDACTED> wrote: >>>> > >> > >>>> > >> > Hi! >>>> > >> > >>>> > >> > Andreas, see comment below. >>>> > >> > >>>> > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < >>>> andreas.schultz@REDACTED>: >>>> > >> >> >>>> > >> >> Hi >>>> > >> >> >>>> > >> >> Ingela Andin schrieb am Do., 14. M?rz >>>> 2019 um 17:34 Uhr: >>>> > >> >>> >>>> > >> >>> Hi Albin! >>>> > >> >>> >>>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? < >>>> albin.stigo@REDACTED>: >>>> > >> >>>> >>>> > >> >>>> Hi Ingela, >>>> > >> >>>> >>>> > >> >>>> Thanks for the quick reply! >>>> > >> >>>> >>>> > >> >>>> While cb_info certainly is one way of doing it, it feels a bit >>>> > >> >>>> complicated... specifically if switching between active and >>>> passive >>>> > >> >>>> mode. Not sure if ssl ever use passive mode internally? >>>> Demuxing is a >>>> > >> >>>> different use case, I think.. >>>> > >> >>>> >>>> > >> >>> >>>> > >> >>> The cb_info is intended so that you may replace the transport >>>> layer, with most likely, an SCTP transport (can be done for both TLS and >>>> DTLS although there are some extensions needed for the DLTS version to work >>>> properly). I think some people also use it to implement WebSockets. >>>> > >> >>> >>>> > >> >>> ssl internally uses active n for TLS (since latest release) >>>> and active once for DTLS (we might change it) but an OTP supervised process >>>> will not use passive recv as we do not want it to block. >>>> > >> >>> >>>> > >> >>> >>>> > >> >>>> >>>> > >> >>>> Something that IMHO would be fantastic and simple (?) would >>>> be a >>>> > >> >>>> dtls_filter_fun option. If true packet is passed up the ssl >>>> stack, >>>> > >> >>>> otherwise passed on like a normal udp packet! >>>> > >> >>>> >>>> > >> >>> >>>> > >> >>> Sounds reasonable. Otherwise sent to some other Erlang process >>>> than the "DTLS-connection" process that is. >>>> > >> >> >>>> > >> >> >>>> > >> >> No, that's not enough. Some protocols put additional headers in >>>> front of the DTLS packets. So there needs to be a way to strip headers on >>>> Rx and add it on Tx (with session information if needed). >>>> > >> >> >>>> > >> > >>>> > >> > Maybe the demultiplexor process can have a "packet mode" that is >>>> set to "no packet" default and needs a callback handler for anything else? >>>> > >> > >>>> > >> > >>>> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >>>> > >> > >>>> > >> >> >>>> > >> >> Andreas >>>> > >> >> >>>> > >> >>> >>>> > >> >>> >>>> > >> >>>> >>>> > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it >>>> basically >>>> > >> >>>> boils down to looking at the first byte of the packet, if it's >>>> > >> >>>> [20..63] it should be treated as DTLS otherwise something >>>> else. So >>>> > >> >>>> this would be absolutely trivial to implement if there was a >>>> > >> >>>> dtls_filter_fun... >>>> > >> >>>> >>>> > >> >>>> https://tools.ietf.org/html/rfc7983 >>>> > >> >>>> >>>> > >> >>>> Then of course there also has to be a way to bypass DTLS when >>>> sending >>>> > >> >>>> data... maybe send/3 (Socket, Data, Options)... >>>> > >> >>>> >>>> > >> >>> >>>> > >> >>> Maybe transport_send as compared to the existing >>>> transport_accept. Would only work for DTLS. >>>> > >> >>> >>>> > >> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>>> > >> >>> >>>> > >> >>>> >>>> > >> >>>> What do you think? >>>> > >> >>>> >>>> > >> >>>> >>>> > >> >>>> --Albin >>>> > >> >>>> >>>> > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin < >>>> ingela.andin@REDACTED> wrote: >>>> > >> >>>> > >>>> > >> >>>> > Hi! >>>> > >> >>>> > >>>> > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < >>>> albin.stigo@REDACTED>: >>>> > >> >>>> >> >>>> > >> >>>> >> Hi, >>>> > >> >>>> >> >>>> > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send >>>> audio/video to >>>> > >> >>>> >> the browser). >>>> > >> >>>> >> >>>> > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: >>>> > >> >>>> >> >>>> > >> >>>> >> 1. The use_srtp extension for key exchange. >>>> > >> >>>> > >>>> > >> >>>> > >>>> > >> >>>> > We will be implementing this as part of TLS-1.3 that we are >>>> currently working on, and we will have something runnable for OTP-22.0, >>>> although we are not promising that it will complete or that use_srtp will >>>> be part of OTP-22.0 >>>> > >> >>>> > >>>> > >> >>>> > >>>> > >> >>>> >> >>>> > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >>>> > >> >>>> >> >>>> > >> >>>> >> I know there's been work towards use_srtp and it's even in >>>> the source, >>>> > >> >>>> >> but commented out. Ingela has been working on it for OTP >>>> 2, I believe, >>>> > >> >>>> >> is there an ETA on this feature? >>>> > >> >>>> > >>>> > >> >>>> > >>>> > >> >>>> >> >>>> > >> >>>> >> >>>> > >> >>>> >> >>>> > >> >>>> >> Is multiplexing on the DTLS socket already possible using >>>> the cb_info? >>>> > >> >>>> >> Has anyone tried that? >>>> > >> >>>> >> >>>> > >> >>>> >> >>>> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >>>> > >> >>>> >> >>>> > >> >>>> > >>>> > >> >>>> > The code has been written to make such extensions possible. >>>> There might be a need for more callbacks. I have not really had time to >>>> work on that as >>>> > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS has >>>> been prioritized higher. Suggestions are welcome. >>>> > >> >>>> > >>>> > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB >>>> > >> >>>> > >>>> > >> >>>> > >>>> > >> >>>> > >>>> > >> >>>> > >>>> > >> >>>> >> >>>> > >> >>>> >> >>>> > >> >>>> >> --Albin >>>> > >> >>>> >> _______________________________________________ >>>> > >> >>>> >> erlang-questions mailing list >>>> > >> >>>> >> erlang-questions@REDACTED >>>> > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions >>>> > >> >>> >>>> > >> >>> _______________________________________________ >>>> > >> >>> erlang-questions mailing list >>>> > >> >>> erlang-questions@REDACTED >>>> > >> >>> http://erlang.org/mailman/listinfo/erlang-questions >>>> > >> >> >>>> > >> >> -- >>>> > >> >> -- >>>> > >> >> Dipl.-Inform. Andreas Schultz >>>> > >> >> >>>> > >> >> ----------------------- enabling your networks >>>> ---------------------- >>>> > >> >> Travelping GmbH Phone: +49-391-81 90 99 0 >>>> > >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 >>>> > >> >> 39108 Magdeburg Email: info@REDACTED >>>> > >> >> GERMANY Web: >>>> http://www.travelping.com >>>> > >> >> >>>> > >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB >>>> 10578 >>>> > >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>> DE236673780 >>>> > >> >> >>>> --------------------------------------------------------------------- >>>> > > >>>> > > -- >>>> > > -- >>>> > > Dipl.-Inform. Andreas Schultz >>>> > > >>>> > > ----------------------- enabling your networks >>>> ---------------------- >>>> > > Travelping GmbH Phone: +49-391-81 90 99 0 >>>> > > Roentgenstr. 13 Fax: +49-391-81 90 99 299 >>>> > > 39108 Magdeburg Email: info@REDACTED >>>> > > GERMANY Web: >>>> http://www.travelping.com >>>> > > >>>> > > Company Registration: Amtsgericht Stendal Reg No.: HRB >>>> 10578 >>>> > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>> DE236673780 >>>> > > >>>> --------------------------------------------------------------------- >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Sat Mar 16 11:00:26 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Sat, 16 Mar 2019 11:00:26 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi! Den l?r 16 mars 2019 kl 10:21 skrev Albin Stig? : > Ok sorry about the confusion. What's needed is a second level of > demultiplexing after the first... But I realize now this will be very > difficult to achieve with the current implementation because that relies on > one socket per connection. Otherwise you won't know which process to send > the none DTLS packets to... Or am i missing something? > > You will have to extend the demultiplexor process so that it sends packets to different processes depending on some criteria. It is ok to change the internals of the process if that is necessary. But we like the basic functionality to be the framework of the process and then add extended features mainly through callbacks. Regards Ingela Erlang/OTP Team - Ericsson AB > I might have to attempt a separate DTLS use_srtp app just for this > application... > > > --Albin > > On Sat, Mar 16, 2019, 09:05 Ingela Andin wrote: > >> Hi Albin! >> >> Den fre 15 mars 2019 kl 17:25 skrev Albin Stig? : >> >>> Ok thanks! >>> >>> Maybe demultiplexing should just be default when the use_srtp extension >>> is used, since that's how it's supposed to be used anyway... or a >>> rfc7983_demux option... >>> >>> >> ? A DTLS server will always have a demultiplexing process as UDP does not >> have a connection concept. >> >> >> >>> What's the name in the #state that holds the pid of the controlling >>> process (the process that receives {ssl.. data)? >>> >>> >> It is part of the "user" in the state of the TLS/DTLS connection >> process. You should not have to care. You set the controlling process with >> ssl:controlling_process/2. >> >> I guess what you care about is the demultiplexing process and which Pid >> it sends the incoming UDP packets to. All the code is defined in the >> dtls_packet_demux.erl >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> >>> --Albin >>> >>> On Fri, Mar 15, 2019, 17:01 Ingela Andin wrote: >>> >>>> Hi Albin! >>>> >>>> There is the handshake_compleation option together with the >>>> handshake_continue functions that let you pause the handshake and retrieve >>>> the hello extensions and possibly provide more options before >>>> continuing the handshake. >>>> >>>> Den fre 15 mars 2019 kl 13:20 skrev Albin Stig? >>> >: >>>> >>>>> Am I right to assume this is the single point of udp receive for dtls? >>>>> >>>>> >>>>> https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906 >>>>> >>>>> >>>>> >>>> If you want to multiplex UDP packets to other processes than the DTLS >>>> connection process that is not encrypted under DTLS you >>>> should not look at the DTLS connection process but at the >>>> >>>> >>>> https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140 >>>> >>>> Regards Ingela Erlang/OTP team Ericsson AB >>>> >>>> >>>>> --Albin >>>>> >>>>> On Fri, Mar 15, 2019 at 1:10 PM Albin Stig? >>>>> wrote: >>>>> > >>>>> > There're all kinds of abuse of DTLS it seems :-) >>>>> > >>>>> > I still think the use cases are orthogonal though... Demuxing as >>>>> > described in https://tools.ietf.org/html/rfc7983 is trivial and >>>>> > requires no state. A demux_fun would solve that problem. >>>>> > >>>>> > DTLS packets wrapped in extra headers with the need of state >>>>> > information is much more complicated... Maybe what is needed are two >>>>> > different approaches? Especially since you will need forward and >>>>> > backwards transform..? >>>>> > >>>>> > Ingela, is there already an API for getting the key data from >>>>> use_srtp >>>>> > (when implemented) or will that have to be added also? >>>>> > >>>>> > >>>>> > --Albin >>>>> > >>>>> > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz >>>>> > wrote: >>>>> > > >>>>> > > Albin Stig? schrieb am Do., 14. M?rz 2019 >>>>> um 18:49 Uhr: >>>>> > >> >>>>> > >> Hi Ingela and Andreas, >>>>> > >> >>>>> > >> > No, that's not enough. Some protocols put additional headers in >>>>> front of the DTLS packets. So there needs to be a way to strip >>>>> > >> > headers on Rx and add it on Tx (with session information if >>>>> needed). >>>>> > >> >>>>> > >> I have to admit I have not encountered this practice... do you >>>>> have a >>>>> > >> particular protocol in mind or is it a part of dtls-srtp I have >>>>> > >> missed? One could argue that if you add additional headers and >>>>> > >> maintain some kind of state you are actually dealing with a >>>>> different >>>>> > >> transport layer...? >>>>> > > >>>>> > > >>>>> > > CAPWAP is doing that >>>>> https://tools.ietf.org/html/rfc5415#section-4.1 >>>>> > > >>>>> > >> I would very much like a way where filtered out packages were >>>>> sent to >>>>> > >> the controlling process as {udp,Socket instead of {ssl, Socket... >>>>> The >>>>> > >> question in the latter case is if Socket should be the ssl socket >>>>> or >>>>> > >> the transport socket. Messing with the transport socket could be >>>>> > >> detrimental to dtls. >>>>> > >> >>>>> > >> One could also extend the filter_fun idea to a transform_fun >>>>> where one >>>>> > >> could transform in packet in addition to demultiplexing, but like >>>>> I >>>>> > >> said, I think additional headers to dtls packets belong to the >>>>> > >> transport layer. >>>>> > > >>>>> > > >>>>> > > Passing a State in and out of such a transform would be good. >>>>> > > >>>>> > > Andreas >>>>> > > >>>>> > >> >>>>> > >> >>>>> > >> I don't have in-depth knowledge of the ssl app but it seems >>>>> adding a >>>>> > >> filter_fun would be almost trivial? >>>>> > >> >>>>> > >> > Maybe transport_send as compared to the existing >>>>> transport_accept. Would only work for DTLS. >>>>> > >> >>>>> > >> Well either that or some way of accessing the transport socket, >>>>> but >>>>> > >> transport_send for sure plays well with existing API! >>>>> > >> >>>>> > >> >>>>> > >> --Albin >>>>> > >> >>>>> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin < >>>>> ingela.andin@REDACTED> wrote: >>>>> > >> > >>>>> > >> > Hi! >>>>> > >> > >>>>> > >> > Andreas, see comment below. >>>>> > >> > >>>>> > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < >>>>> andreas.schultz@REDACTED>: >>>>> > >> >> >>>>> > >> >> Hi >>>>> > >> >> >>>>> > >> >> Ingela Andin schrieb am Do., 14. >>>>> M?rz 2019 um 17:34 Uhr: >>>>> > >> >>> >>>>> > >> >>> Hi Albin! >>>>> > >> >>> >>>>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? < >>>>> albin.stigo@REDACTED>: >>>>> > >> >>>> >>>>> > >> >>>> Hi Ingela, >>>>> > >> >>>> >>>>> > >> >>>> Thanks for the quick reply! >>>>> > >> >>>> >>>>> > >> >>>> While cb_info certainly is one way of doing it, it feels a >>>>> bit >>>>> > >> >>>> complicated... specifically if switching between active and >>>>> passive >>>>> > >> >>>> mode. Not sure if ssl ever use passive mode internally? >>>>> Demuxing is a >>>>> > >> >>>> different use case, I think.. >>>>> > >> >>>> >>>>> > >> >>> >>>>> > >> >>> The cb_info is intended so that you may replace the transport >>>>> layer, with most likely, an SCTP transport (can be done for both TLS and >>>>> DTLS although there are some extensions needed for the DLTS version to work >>>>> properly). I think some people also use it to implement WebSockets. >>>>> > >> >>> >>>>> > >> >>> ssl internally uses active n for TLS (since latest release) >>>>> and active once for DTLS (we might change it) but an OTP supervised process >>>>> will not use passive recv as we do not want it to block. >>>>> > >> >>> >>>>> > >> >>> >>>>> > >> >>>> >>>>> > >> >>>> Something that IMHO would be fantastic and simple (?) would >>>>> be a >>>>> > >> >>>> dtls_filter_fun option. If true packet is passed up the ssl >>>>> stack, >>>>> > >> >>>> otherwise passed on like a normal udp packet! >>>>> > >> >>>> >>>>> > >> >>> >>>>> > >> >>> Sounds reasonable. Otherwise sent to some other Erlang >>>>> process than the "DTLS-connection" process that is. >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> No, that's not enough. Some protocols put additional headers >>>>> in front of the DTLS packets. So there needs to be a way to strip headers >>>>> on Rx and add it on Tx (with session information if needed). >>>>> > >> >> >>>>> > >> > >>>>> > >> > Maybe the demultiplexor process can have a "packet mode" that >>>>> is set to "no packet" default and needs a callback handler for anything >>>>> else? >>>>> > >> > >>>>> > >> > >>>>> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >>>>> > >> > >>>>> > >> >> >>>>> > >> >> Andreas >>>>> > >> >> >>>>> > >> >>> >>>>> > >> >>> >>>>> > >> >>>> >>>>> > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, it >>>>> basically >>>>> > >> >>>> boils down to looking at the first byte of the packet, if >>>>> it's >>>>> > >> >>>> [20..63] it should be treated as DTLS otherwise something >>>>> else. So >>>>> > >> >>>> this would be absolutely trivial to implement if there was a >>>>> > >> >>>> dtls_filter_fun... >>>>> > >> >>>> >>>>> > >> >>>> https://tools.ietf.org/html/rfc7983 >>>>> > >> >>>> >>>>> > >> >>>> Then of course there also has to be a way to bypass DTLS >>>>> when sending >>>>> > >> >>>> data... maybe send/3 (Socket, Data, Options)... >>>>> > >> >>>> >>>>> > >> >>> >>>>> > >> >>> Maybe transport_send as compared to the existing >>>>> transport_accept. Would only work for DTLS. >>>>> > >> >>> >>>>> > >> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>> > >> >>> >>>>> > >> >>>> >>>>> > >> >>>> What do you think? >>>>> > >> >>>> >>>>> > >> >>>> >>>>> > >> >>>> --Albin >>>>> > >> >>>> >>>>> > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin < >>>>> ingela.andin@REDACTED> wrote: >>>>> > >> >>>> > >>>>> > >> >>>> > Hi! >>>>> > >> >>>> > >>>>> > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < >>>>> albin.stigo@REDACTED>: >>>>> > >> >>>> >> >>>>> > >> >>>> >> Hi, >>>>> > >> >>>> >> >>>>> > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send >>>>> audio/video to >>>>> > >> >>>> >> the browser). >>>>> > >> >>>> >> >>>>> > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: >>>>> > >> >>>> >> >>>>> > >> >>>> >> 1. The use_srtp extension for key exchange. >>>>> > >> >>>> > >>>>> > >> >>>> > >>>>> > >> >>>> > We will be implementing this as part of TLS-1.3 that we >>>>> are currently working on, and we will have something runnable for OTP-22.0, >>>>> although we are not promising that it will complete or that use_srtp will >>>>> be part of OTP-22.0 >>>>> > >> >>>> > >>>>> > >> >>>> > >>>>> > >> >>>> >> >>>>> > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >>>>> > >> >>>> >> >>>>> > >> >>>> >> I know there's been work towards use_srtp and it's even >>>>> in the source, >>>>> > >> >>>> >> but commented out. Ingela has been working on it for OTP >>>>> 2, I believe, >>>>> > >> >>>> >> is there an ETA on this feature? >>>>> > >> >>>> > >>>>> > >> >>>> > >>>>> > >> >>>> >> >>>>> > >> >>>> >> >>>>> > >> >>>> >> >>>>> > >> >>>> >> Is multiplexing on the DTLS socket already possible using >>>>> the cb_info? >>>>> > >> >>>> >> Has anyone tried that? >>>>> > >> >>>> >> >>>>> > >> >>>> >> >>>>> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >>>>> > >> >>>> >> >>>>> > >> >>>> > >>>>> > >> >>>> > The code has been written to make such extensions >>>>> possible. There might be a need for more callbacks. I have not really had >>>>> time to work on that as >>>>> > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS >>>>> has been prioritized higher. Suggestions are welcome. >>>>> > >> >>>> > >>>>> > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB >>>>> > >> >>>> > >>>>> > >> >>>> > >>>>> > >> >>>> > >>>>> > >> >>>> > >>>>> > >> >>>> >> >>>>> > >> >>>> >> >>>>> > >> >>>> >> --Albin >>>>> > >> >>>> >> _______________________________________________ >>>>> > >> >>>> >> erlang-questions mailing list >>>>> > >> >>>> >> erlang-questions@REDACTED >>>>> > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions >>>>> > >> >>> >>>>> > >> >>> _______________________________________________ >>>>> > >> >>> erlang-questions mailing list >>>>> > >> >>> erlang-questions@REDACTED >>>>> > >> >>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> > >> >> >>>>> > >> >> -- >>>>> > >> >> -- >>>>> > >> >> Dipl.-Inform. Andreas Schultz >>>>> > >> >> >>>>> > >> >> ----------------------- enabling your networks >>>>> ---------------------- >>>>> > >> >> Travelping GmbH Phone: +49-391-81 90 99 0 >>>>> > >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 >>>>> 299 >>>>> > >> >> 39108 Magdeburg Email: >>>>> info@REDACTED >>>>> > >> >> GERMANY Web: >>>>> http://www.travelping.com >>>>> > >> >> >>>>> > >> >> Company Registration: Amtsgericht Stendal Reg No.: >>>>> HRB 10578 >>>>> > >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>>> DE236673780 >>>>> > >> >> >>>>> --------------------------------------------------------------------- >>>>> > > >>>>> > > -- >>>>> > > -- >>>>> > > Dipl.-Inform. Andreas Schultz >>>>> > > >>>>> > > ----------------------- enabling your networks >>>>> ---------------------- >>>>> > > Travelping GmbH Phone: +49-391-81 90 99 0 >>>>> > > Roentgenstr. 13 Fax: +49-391-81 90 99 299 >>>>> > > 39108 Magdeburg Email: info@REDACTED >>>>> > > GERMANY Web: >>>>> http://www.travelping.com >>>>> > > >>>>> > > Company Registration: Amtsgericht Stendal Reg No.: HRB >>>>> 10578 >>>>> > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>>> DE236673780 >>>>> > > >>>>> --------------------------------------------------------------------- >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Sat Mar 16 11:53:14 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Sat, 16 Mar 2019 11:53:14 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: True... A callback receiving {udp, Socket, IP, InPortNo, Packet} and deciding whether to use the the ssl demuxer or pass it on to another process might be enough. The STUN packets could come from any IP unsolicited when doing ICE nat traversal path discovery (as described by WebRTC). --Albin On Sat, Mar 16, 2019, 11:00 Ingela Andin wrote: > > Hi! > > Den l?r 16 mars 2019 kl 10:21 skrev Albin Stig? : > >> Ok sorry about the confusion. What's needed is a second level of >> demultiplexing after the first... But I realize now this will be very >> difficult to achieve with the current implementation because that relies on >> one socket per connection. Otherwise you won't know which process to send >> the none DTLS packets to... Or am i missing something? >> >> > You will have to extend the demultiplexor process so that it sends packets > to different processes depending on some criteria. It is ok to change the > internals of > the process if that is necessary. But we like the basic functionality to > be the framework of the process and then add extended features mainly > through callbacks. > > Regards Ingela Erlang/OTP Team - Ericsson AB > > >> I might have to attempt a separate DTLS use_srtp app just for this >> application... >> >> >> --Albin >> >> On Sat, Mar 16, 2019, 09:05 Ingela Andin wrote: >> >>> Hi Albin! >>> >>> Den fre 15 mars 2019 kl 17:25 skrev Albin Stig? : >>> >>>> Ok thanks! >>>> >>>> Maybe demultiplexing should just be default when the use_srtp extension >>>> is used, since that's how it's supposed to be used anyway... or a >>>> rfc7983_demux option... >>>> >>>> >>> ? A DTLS server will always have a demultiplexing process as UDP does >>> not have a connection concept. >>> >>> >>> >>>> What's the name in the #state that holds the pid of the controlling >>>> process (the process that receives {ssl.. data)? >>>> >>>> >>> It is part of the "user" in the state of the TLS/DTLS connection >>> process. You should not have to care. You set the controlling process with >>> ssl:controlling_process/2. >>> >>> I guess what you care about is the demultiplexing process and which Pid >>> it sends the incoming UDP packets to. All the code is defined in the >>> dtls_packet_demux.erl >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>>> --Albin >>>> >>>> On Fri, Mar 15, 2019, 17:01 Ingela Andin >>>> wrote: >>>> >>>>> Hi Albin! >>>>> >>>>> There is the handshake_compleation option together with the >>>>> handshake_continue functions that let you pause the handshake and retrieve >>>>> the hello extensions and possibly provide more options before >>>>> continuing the handshake. >>>>> >>>>> Den fre 15 mars 2019 kl 13:20 skrev Albin Stig? >>>> >: >>>>> >>>>>> Am I right to assume this is the single point of udp receive for dtls? >>>>>> >>>>>> >>>>>> https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906 >>>>>> >>>>>> >>>>>> >>>>> If you want to multiplex UDP packets to other processes than the DTLS >>>>> connection process that is not encrypted under DTLS you >>>>> should not look at the DTLS connection process but at the >>>>> >>>>> >>>>> https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140 >>>>> >>>>> Regards Ingela Erlang/OTP team Ericsson AB >>>>> >>>>> >>>>>> --Albin >>>>>> >>>>>> On Fri, Mar 15, 2019 at 1:10 PM Albin Stig? >>>>>> wrote: >>>>>> > >>>>>> > There're all kinds of abuse of DTLS it seems :-) >>>>>> > >>>>>> > I still think the use cases are orthogonal though... Demuxing as >>>>>> > described in https://tools.ietf.org/html/rfc7983 is trivial and >>>>>> > requires no state. A demux_fun would solve that problem. >>>>>> > >>>>>> > DTLS packets wrapped in extra headers with the need of state >>>>>> > information is much more complicated... Maybe what is needed are two >>>>>> > different approaches? Especially since you will need forward and >>>>>> > backwards transform..? >>>>>> > >>>>>> > Ingela, is there already an API for getting the key data from >>>>>> use_srtp >>>>>> > (when implemented) or will that have to be added also? >>>>>> > >>>>>> > >>>>>> > --Albin >>>>>> > >>>>>> > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz >>>>>> > wrote: >>>>>> > > >>>>>> > > Albin Stig? schrieb am Do., 14. M?rz >>>>>> 2019 um 18:49 Uhr: >>>>>> > >> >>>>>> > >> Hi Ingela and Andreas, >>>>>> > >> >>>>>> > >> > No, that's not enough. Some protocols put additional headers >>>>>> in front of the DTLS packets. So there needs to be a way to strip >>>>>> > >> > headers on Rx and add it on Tx (with session information if >>>>>> needed). >>>>>> > >> >>>>>> > >> I have to admit I have not encountered this practice... do you >>>>>> have a >>>>>> > >> particular protocol in mind or is it a part of dtls-srtp I have >>>>>> > >> missed? One could argue that if you add additional headers and >>>>>> > >> maintain some kind of state you are actually dealing with a >>>>>> different >>>>>> > >> transport layer...? >>>>>> > > >>>>>> > > >>>>>> > > CAPWAP is doing that >>>>>> https://tools.ietf.org/html/rfc5415#section-4.1 >>>>>> > > >>>>>> > >> I would very much like a way where filtered out packages were >>>>>> sent to >>>>>> > >> the controlling process as {udp,Socket instead of {ssl, >>>>>> Socket... The >>>>>> > >> question in the latter case is if Socket should be the ssl >>>>>> socket or >>>>>> > >> the transport socket. Messing with the transport socket could be >>>>>> > >> detrimental to dtls. >>>>>> > >> >>>>>> > >> One could also extend the filter_fun idea to a transform_fun >>>>>> where one >>>>>> > >> could transform in packet in addition to demultiplexing, but >>>>>> like I >>>>>> > >> said, I think additional headers to dtls packets belong to the >>>>>> > >> transport layer. >>>>>> > > >>>>>> > > >>>>>> > > Passing a State in and out of such a transform would be good. >>>>>> > > >>>>>> > > Andreas >>>>>> > > >>>>>> > >> >>>>>> > >> >>>>>> > >> I don't have in-depth knowledge of the ssl app but it seems >>>>>> adding a >>>>>> > >> filter_fun would be almost trivial? >>>>>> > >> >>>>>> > >> > Maybe transport_send as compared to the existing >>>>>> transport_accept. Would only work for DTLS. >>>>>> > >> >>>>>> > >> Well either that or some way of accessing the transport socket, >>>>>> but >>>>>> > >> transport_send for sure plays well with existing API! >>>>>> > >> >>>>>> > >> >>>>>> > >> --Albin >>>>>> > >> >>>>>> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin < >>>>>> ingela.andin@REDACTED> wrote: >>>>>> > >> > >>>>>> > >> > Hi! >>>>>> > >> > >>>>>> > >> > Andreas, see comment below. >>>>>> > >> > >>>>>> > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < >>>>>> andreas.schultz@REDACTED>: >>>>>> > >> >> >>>>>> > >> >> Hi >>>>>> > >> >> >>>>>> > >> >> Ingela Andin schrieb am Do., 14. >>>>>> M?rz 2019 um 17:34 Uhr: >>>>>> > >> >>> >>>>>> > >> >>> Hi Albin! >>>>>> > >> >>> >>>>>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? < >>>>>> albin.stigo@REDACTED>: >>>>>> > >> >>>> >>>>>> > >> >>>> Hi Ingela, >>>>>> > >> >>>> >>>>>> > >> >>>> Thanks for the quick reply! >>>>>> > >> >>>> >>>>>> > >> >>>> While cb_info certainly is one way of doing it, it feels a >>>>>> bit >>>>>> > >> >>>> complicated... specifically if switching between active and >>>>>> passive >>>>>> > >> >>>> mode. Not sure if ssl ever use passive mode internally? >>>>>> Demuxing is a >>>>>> > >> >>>> different use case, I think.. >>>>>> > >> >>>> >>>>>> > >> >>> >>>>>> > >> >>> The cb_info is intended so that you may replace the >>>>>> transport layer, with most likely, an SCTP transport (can be done for both >>>>>> TLS and DTLS although there are some extensions needed for the DLTS version >>>>>> to work properly). I think some people also use it to implement WebSockets. >>>>>> > >> >>> >>>>>> > >> >>> ssl internally uses active n for TLS (since latest release) >>>>>> and active once for DTLS (we might change it) but an OTP supervised process >>>>>> will not use passive recv as we do not want it to block. >>>>>> > >> >>> >>>>>> > >> >>> >>>>>> > >> >>>> >>>>>> > >> >>>> Something that IMHO would be fantastic and simple (?) would >>>>>> be a >>>>>> > >> >>>> dtls_filter_fun option. If true packet is passed up the ssl >>>>>> stack, >>>>>> > >> >>>> otherwise passed on like a normal udp packet! >>>>>> > >> >>>> >>>>>> > >> >>> >>>>>> > >> >>> Sounds reasonable. Otherwise sent to some other Erlang >>>>>> process than the "DTLS-connection" process that is. >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> No, that's not enough. Some protocols put additional headers >>>>>> in front of the DTLS packets. So there needs to be a way to strip headers >>>>>> on Rx and add it on Tx (with session information if needed). >>>>>> > >> >> >>>>>> > >> > >>>>>> > >> > Maybe the demultiplexor process can have a "packet mode" that >>>>>> is set to "no packet" default and needs a callback handler for anything >>>>>> else? >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >>>>>> > >> > >>>>>> > >> >> >>>>>> > >> >> Andreas >>>>>> > >> >> >>>>>> > >> >>> >>>>>> > >> >>> >>>>>> > >> >>>> >>>>>> > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, >>>>>> it basically >>>>>> > >> >>>> boils down to looking at the first byte of the packet, if >>>>>> it's >>>>>> > >> >>>> [20..63] it should be treated as DTLS otherwise something >>>>>> else. So >>>>>> > >> >>>> this would be absolutely trivial to implement if there was a >>>>>> > >> >>>> dtls_filter_fun... >>>>>> > >> >>>> >>>>>> > >> >>>> https://tools.ietf.org/html/rfc7983 >>>>>> > >> >>>> >>>>>> > >> >>>> Then of course there also has to be a way to bypass DTLS >>>>>> when sending >>>>>> > >> >>>> data... maybe send/3 (Socket, Data, Options)... >>>>>> > >> >>>> >>>>>> > >> >>> >>>>>> > >> >>> Maybe transport_send as compared to the existing >>>>>> transport_accept. Would only work for DTLS. >>>>>> > >> >>> >>>>>> > >> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>> > >> >>> >>>>>> > >> >>>> >>>>>> > >> >>>> What do you think? >>>>>> > >> >>>> >>>>>> > >> >>>> >>>>>> > >> >>>> --Albin >>>>>> > >> >>>> >>>>>> > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin < >>>>>> ingela.andin@REDACTED> wrote: >>>>>> > >> >>>> > >>>>>> > >> >>>> > Hi! >>>>>> > >> >>>> > >>>>>> > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < >>>>>> albin.stigo@REDACTED>: >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> Hi, >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send >>>>>> audio/video to >>>>>> > >> >>>> >> the browser). >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> 1. The use_srtp extension for key exchange. >>>>>> > >> >>>> > >>>>>> > >> >>>> > >>>>>> > >> >>>> > We will be implementing this as part of TLS-1.3 that we >>>>>> are currently working on, and we will have something runnable for OTP-22.0, >>>>>> although we are not promising that it will complete or that use_srtp will >>>>>> be part of OTP-22.0 >>>>>> > >> >>>> > >>>>>> > >> >>>> > >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> I know there's been work towards use_srtp and it's even >>>>>> in the source, >>>>>> > >> >>>> >> but commented out. Ingela has been working on it for OTP >>>>>> 2, I believe, >>>>>> > >> >>>> >> is there an ETA on this feature? >>>>>> > >> >>>> > >>>>>> > >> >>>> > >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> Is multiplexing on the DTLS socket already possible >>>>>> using the cb_info? >>>>>> > >> >>>> >> Has anyone tried that? >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> >>>>>> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >>>>>> > >> >>>> >> >>>>>> > >> >>>> > >>>>>> > >> >>>> > The code has been written to make such extensions >>>>>> possible. There might be a need for more callbacks. I have not really had >>>>>> time to work on that as >>>>>> > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS >>>>>> has been prioritized higher. Suggestions are welcome. >>>>>> > >> >>>> > >>>>>> > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB >>>>>> > >> >>>> > >>>>>> > >> >>>> > >>>>>> > >> >>>> > >>>>>> > >> >>>> > >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> >>>>>> > >> >>>> >> --Albin >>>>>> > >> >>>> >> _______________________________________________ >>>>>> > >> >>>> >> erlang-questions mailing list >>>>>> > >> >>>> >> erlang-questions@REDACTED >>>>>> > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> > >> >>> >>>>>> > >> >>> _______________________________________________ >>>>>> > >> >>> erlang-questions mailing list >>>>>> > >> >>> erlang-questions@REDACTED >>>>>> > >> >>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> > >> >> >>>>>> > >> >> -- >>>>>> > >> >> -- >>>>>> > >> >> Dipl.-Inform. Andreas Schultz >>>>>> > >> >> >>>>>> > >> >> ----------------------- enabling your networks >>>>>> ---------------------- >>>>>> > >> >> Travelping GmbH Phone: +49-391-81 90 99 0 >>>>>> > >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 >>>>>> 299 >>>>>> > >> >> 39108 Magdeburg Email: >>>>>> info@REDACTED >>>>>> > >> >> GERMANY Web: >>>>>> http://www.travelping.com >>>>>> > >> >> >>>>>> > >> >> Company Registration: Amtsgericht Stendal Reg No.: >>>>>> HRB 10578 >>>>>> > >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>>>> DE236673780 >>>>>> > >> >> >>>>>> --------------------------------------------------------------------- >>>>>> > > >>>>>> > > -- >>>>>> > > -- >>>>>> > > Dipl.-Inform. Andreas Schultz >>>>>> > > >>>>>> > > ----------------------- enabling your networks >>>>>> ---------------------- >>>>>> > > Travelping GmbH Phone: +49-391-81 90 99 0 >>>>>> > > Roentgenstr. 13 Fax: +49-391-81 90 99 299 >>>>>> > > 39108 Magdeburg Email: info@REDACTED >>>>>> > > GERMANY Web: >>>>>> http://www.travelping.com >>>>>> > > >>>>>> > > Company Registration: Amtsgericht Stendal Reg No.: HRB >>>>>> 10578 >>>>>> > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>>>> DE236673780 >>>>>> > > >>>>>> --------------------------------------------------------------------- >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Sat Mar 16 11:56:14 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Sat, 16 Mar 2019 23:56:14 +1300 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: <20190315225209.GD10520@carfax.org.uk> References: <20190315225209.GD10520@carfax.org.uk> Message-ID: I'd say that the specification of the input to erlang:list_to_float/1 should be in the manual entry for erlang:list_to_float/1, namely http://erlang.org/doc/man/erlang.html#list_to_float-1 By experiment, it looks like /^[-+]?[0-9]+[.][0-9]+([eE][-+]?[0-9]+)?$/ (Note: [-+] works but [+-] of course does not.) On Sat, 16 Mar 2019 at 11:52, Hugo Mills wrote: > Where in the manual is the set of allowable string representations > of floating point numbers documented? I'd have expected it to be here: > > http://erlang.org/doc/reference_manual/data_types.html > > ... but apparently not. > > Specifically, I'm trying to use list_to_float/1, and I've been > trying to reverse engineer it: > > 1> list_to_float("-1"). > ** exception error: bad argument > in function list_to_float/1 > called as list_to_float("-1") > 2> list_to_float("-1.0"). > -1.0 > 3> list_to_float("-1.0e-23"). > -1.0e-23 > 4> list_to_float("-1e-23"). > ** exception error: bad argument > in function list_to_float/1 > called as list_to_float("-1e-23") > 5> list_to_float(".3"). > ** exception error: bad argument > in function list_to_float/1 > called as list_to_float(".3") > > An actual written specification would be really handy here. Even > just a regex or EBNF for them. I'm writing a parser for something > where the definition of floating point literals isn't quite the same > as Erlang's, and it's a bit painful. > > Hugo. > > -- > Hugo Mills | Your problem is that you've got too much taste to > be > hugo@REDACTED carfax.org.uk | a web developer. > http://carfax.org.uk/ | > PGP: E2AB1DE4 | Steve > Harris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIbBAEBAgAGBQJcjCyYAAoJEFheFHXiqx3kBo8P+KYpzGUmaV4lA8jopR5h39S8 > XMt6e+mO4zceiz1LE9mGFozayPPgPlchuJz3h/9EgtvNKXV8AvUGLFOZHtcE5qeM > wDwQg6kreHW/5ejrpYFCH1rZt9DftnAzMQo0SXOCQTfLkAC5W/jRrZyAE8ibVEH+ > JoAOG/ZRUTz4E3bnoSGfcrY13IwD5A3sJ3Jex6rLttVjJyfCEbBJMx5ofFXO9WbY > PfggXSD7EALHdUOT1vQWJsRiJClq25HjAucblA+zst/8N1wllpRnK3uhA1M22lNB > OuYv0lnvKwYmyNSs/VcXRAne5CXjpf/CxJpVMuvXdbRYxrlsybWz9+UWMk7DB+TA > fQvCRIGROG/DlVWo8KAoMN6ZgfxE3pmVjfN3p2usDza2V43QAY+jaZF7x2SyxKxo > Bw4/jW7RODduzWu/XQvRX0780RQlbPbNcFjrOHIt3PZe7+Qtl++6QQcVCJ+TrE8h > 1drKkbFvm2/ecyAXdMkXV8CxiJdbgcSkz2kgIYhTUpiGJz0ubCt3HOA/byh3P8em > /5EhxuQQo5r+Yvn4rHkOIe2KBJuBHHhNky9f8xRU7j9JnxFvm6tQK8tJ4C3fIklI > yua+T9thS3XifUNiWTw/WX6CjSYVl2/lFtmzXYZ5+LiZgd4IImEHnXik/jOv/2eC > ayHhzl8YuA1yxsjULsw= > =Y3WO > -----END PGP SIGNATURE----- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t6sn7gt@REDACTED Sat Mar 16 12:06:43 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Sat, 16 Mar 2019 07:06:43 -0400 Subject: [erlang-questions] Recommendations re beam files Message-ID: To this point (I'm new at this) I've been keeping beam files for the modules I need in the same directory as the main module.? This makes sense for those modules that are closely allied to the main module and unlikely to be used or modified for other programs. However, I have a core set of modules that are used by all my programs.? I'd like to keep these together and in *one* place so that they're easier to maintain.? Also, I don't want to have multiple copies floating around. How do I specify to the compiler where to find them?? (I use Linux.) Thanks. Don From eric.pailleau@REDACTED Sat Mar 16 12:14:54 2019 From: eric.pailleau@REDACTED (Eric Pailleau) Date: Sat, 16 Mar 2019 12:14:54 +0100 Subject: [erlang-questions] Recommendations re beam files In-Reply-To: References: Message-ID: <29n36od4p4hq4kvlnd64h5e8.1552734894530@email.android.com> Hi, Move them to a project for all common things, and add a dependancy to it in all your projects. This way you can specify which version you need. Envoy? depuis mon mobile ---- Donald Steven a ?crit ---- >To this point (I'm new at this) I've been keeping beam files for the >modules I need in the same directory as the main module.? This makes >sense for those modules that are closely allied to the main module and >unlikely to be used or modified for other programs. However, I have a >core set of modules that are used by all my programs.? I'd like to keep >these together and in *one* place so that they're easier to maintain.? >Also, I don't want to have multiple copies floating around. > > >How do I specify to the compiler where to find them?? (I use Linux.) > > >Thanks. > > >Don > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugo@REDACTED Sat Mar 16 12:32:07 2019 From: hugo@REDACTED (Hugo Mills) Date: Sat, 16 Mar 2019 11:32:07 +0000 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: References: <20190315225209.GD10520@carfax.org.uk> Message-ID: <20190316113207.GE10520@carfax.org.uk> Hi, Bob, On Fri, Mar 15, 2019 at 05:32:54PM -0700, Bob Ippolito wrote: > If you dive into the implementation it's effectively a wrapper around > strtod from C with a validation pass that is more strict than the strtod > standard. > > https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54 > https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732 > > So as far as a regex goes it would be something like this: > > [+-]?\d+[.,]\d+([eE][+-]?\d+) > > The major differences between this and other popular float grammars are: > > * At least one digit is required in each part > * Both integer and fractional parts are required, even if there's an > exponent part (so "1", ".1", "1e-1" would not be valid) > * The decimal separator is either , or . (the implementation will try the > other if necessary to compensate for a different locale) Thanks for the confirmation. That's more or less what I discovered while playing around with list_to_float. It's the first two cases that are the problems for me, because the spec I'm working to(*) says that "1." and ".3" are valid floats, for example, as is "1e-1". Just for the record, here's the code I'm using to convert a Turtle double or decimal (the former in scientific notation; the latter without the E) into a form suitable for list_to_float/1: [...] % W3C's description of a float is wider than erlang's. We need to % split up the number into a few parts to add extra characters % where necessary so that list_to_float/1 will work right. F = case string:lexemes(Text, "eE") of [M, E] -> fixup_decimal(M) ++ "e" ++ E; [M] -> fixup_decimal(M) end, O = lagra_model:new_literal(list_to_float(F)), [...] -spec fixup_decimal(string()) -> string(). fixup_decimal(M) -> case string:lexemes(M, ".") of [I] -> I++".0"; [I, ""] -> I++".0"; ["", J] -> "0."++J; [I, J] -> M end. Hugo. (*) W3C's Turtle recommendation. > On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills wrote: > > > Where in the manual is the set of allowable string representations > > of floating point numbers documented? I'd have expected it to be here: > > > > http://erlang.org/doc/reference_manual/data_types.html > > > > ... but apparently not. > > > > Specifically, I'm trying to use list_to_float/1, and I've been > > trying to reverse engineer it: > > > > 1> list_to_float("-1"). > > ** exception error: bad argument > > in function list_to_float/1 > > called as list_to_float("-1") > > 2> list_to_float("-1.0"). > > -1.0 > > 3> list_to_float("-1.0e-23"). > > -1.0e-23 > > 4> list_to_float("-1e-23"). > > ** exception error: bad argument > > in function list_to_float/1 > > called as list_to_float("-1e-23") > > 5> list_to_float(".3"). > > ** exception error: bad argument > > in function list_to_float/1 > > called as list_to_float(".3") > > > > An actual written specification would be really handy here. Even > > just a regex or EBNF for them. I'm writing a parser for something > > where the definition of floating point literals isn't quite the same > > as Erlang's, and it's a bit painful. > > > > Hugo. > > -- Hugo Mills | Nostalgia isn't what it used to be. hugo@REDACTED carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From adhiyaman@REDACTED Sat Mar 16 12:35:48 2019 From: adhiyaman@REDACTED (Adhiyaman) Date: Sat, 16 Mar 2019 17:05:48 +0530 Subject: [erlang-questions] Recommendations re beam files In-Reply-To: <29n36od4p4hq4kvlnd64h5e8.1552734894530@email.android.com> References: <29n36od4p4hq4kvlnd64h5e8.1552734894530@email.android.com> Message-ID: <58ac5eaf-0b0d-f754-4e31-6a4b9348bf15@odysseytec.co.in> Hi, ??? You can set the code path using code module. This tell the ERTS where to locate your beams in case you've moved them from the default lib directory. -Adhi On 16-03-2019 04:44 PM, Eric Pailleau wrote: > > Hi, > > Move them to a project for all common things, and add a dependancy to > it in all your projects. > > This way you can specify which version you need. > > > > Envoy? depuis mon mobile > > > > ---- Donald Steven a ?crit ---- > > To this point (I'm new at this) I've been keeping beam files for the > modules I need in the same directory as the main module. This makes > sense for those modules that are closely allied to the main module and > unlikely to be used or modified for other programs. However, I have a > core set of modules that are used by all my programs. I'd like to keep > these together and in *one* place so that they're easier to maintain. > Also, I don't want to have multiple copies floating around. > > > How do I specify to the compiler where to find them? (I use Linux.) > > > Thanks. > > > Don > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From adhiyaman@REDACTED Sat Mar 16 13:37:00 2019 From: adhiyaman@REDACTED (Adhiyaman) Date: Sat, 16 Mar 2019 18:07:00 +0530 Subject: [erlang-questions] Recommendations re beam files In-Reply-To: <18c25272-c79d-caa7-c014-652a0906bf84@aim.com> References: <29n36od4p4hq4kvlnd64h5e8.1552734894530@email.android.com> <58ac5eaf-0b0d-f754-4e31-6a4b9348bf15@odysseytec.co.in> <18c25272-c79d-caa7-c014-652a0906bf84@aim.com> Message-ID: <8c62607a-0ce1-ba6c-4bec-d6bfab8680dd@odysseytec.co.in> Hi, /code:add_path(DIRECTORY)/, adds the directory to the list of directories where ERTS would look for a beam file. ??? To view the list of directories which are currently in this list, you can use : /??? code:get_path()./ //In addition to this, the following caution is needed : // /??? ??? If there are multiple beams having the same name. The beam in the directory which occurs first in the list is loaded for execution by the ERTS./ /??? ??? There are additional calls in the code module./ /??? ??? Which would aid in the addition of the directory towards the beginning of the list / /??? ??? code:add_patha(DIRECTORY). / /??? ??? For including the directory in the end of the list use code:add_pathz(DIRECTORY)./ Hope this helps you Donald, Cheers ! .. -Adhi // On 16-03-2019 05:52 PM, Donald Steven wrote: > > Thanks Adhi.? Can you please tell me how to do this; I don't > understand what you mean by "... using code module".? Thx. > > On 3/16/2019 7:35 AM, Adhiyaman wrote: >> >> Hi, >> >> ??? You can set the code path using code module. This tell the ERTS >> where to locate your beams in case you've moved them from the default >> lib directory. >> >> -Adhi >> >> On 16-03-2019 04:44 PM, Eric Pailleau wrote: >>> >>> Hi, >>> >>> Move them to a project for all common things, and add a dependancy >>> to it in all your projects. >>> >>> This way you can specify which version you need. >>> >>> >>> >>> Envoy? depuis mon mobile >>> >>> >>> >>> ---- Donald Steven a ?crit ---- >>> >>> To this point (I'm new at this) I've been keeping beam files for the >>> modules I need in the same directory as the main module. This makes >>> sense for those modules that are closely allied to the main module and >>> unlikely to be used or modified for other programs. However, I have a >>> core set of modules that are used by all my programs. I'd like to keep >>> these together and in *one* place so that they're easier to maintain. >>> Also, I don't want to have multiple copies floating around. >>> >>> >>> How do I specify to the compiler where to find them? (I use Linux.) >>> >>> >>> Thanks. >>> >>> >>> Don >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From adhiyaman@REDACTED Sat Mar 16 13:43:04 2019 From: adhiyaman@REDACTED (Adhiyaman) Date: Sat, 16 Mar 2019 18:13:04 +0530 Subject: [erlang-questions] Recommendations re beam files In-Reply-To: <8c62607a-0ce1-ba6c-4bec-d6bfab8680dd@odysseytec.co.in> References: <8c62607a-0ce1-ba6c-4bec-d6bfab8680dd@odysseytec.co.in> Message-ID: <767abf06-5ece-3a26-cb20-8f4b338eecde@odysseytec.co.in> Hi, /code:add_path(DIRECTORY)/, adds the directory to the list of directories where ERTS would look for a beam file. ??? To view the list of directories which are currently in this list, you can use : /??? code:get_path()./ //In addition to this, the following caution is needed : /??? ??? If there are multiple beams having the same name. The beam in the directory which occurs first in the list is loaded for execution by the ERTS./ /??? ??? There are additional calls in the code module./ /??? ??? Which would aid in the addition of the directory towards the beginning of the list / /??? ??? code:add_patha(DIRECTORY). / /??? ??? For including the directory in the end of the list use code:add_pathz(DIRECTORY)./ Hope this helps you Donald, Cheers ! .. -Adhi On 16-03-2019 05:52 PM, Donald Steven wrote: > > Thanks Adhi.? Can you please tell me how to do this; I don't > understand what you mean by "... using code module".? Thx. > > On 3/16/2019 7:35 AM, Adhiyaman wrote: >> >> Hi, >> >> ??? You can set the code path using code module. This tell the ERTS >> where to locate your beams in case you've moved them from the default >> lib directory. >> >> -Adhi >> >> On 16-03-2019 04:44 PM, Eric Pailleau wrote: >>> >>> Hi, >>> >>> Move them to a project for all common things, and add a dependancy >>> to it in all your projects. >>> >>> This way you can specify which version you need. >>> >>> >>> >>> Envoy? depuis mon mobile >>> >>> >>> >>> ---- Donald Steven a ?crit ---- >>> >>> To this point (I'm new at this) I've been keeping beam files for the >>> modules I need in the same directory as the main module. This makes >>> sense for those modules that are closely allied to the main module and >>> unlikely to be used or modified for other programs. However, I have a >>> core set of modules that are used by all my programs. I'd like to keep >>> these together and in *one* place so that they're easier to maintain. >>> Also, I don't want to have multiple copies floating around. >>> >>> >>> How do I specify to the compiler where to find them? (I use Linux.) >>> >>> >>> Thanks. >>> >>> >>> Don >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From cean.ebengt@REDACTED Sat Mar 16 15:23:42 2019 From: cean.ebengt@REDACTED (bengt) Date: Sat, 16 Mar 2019 15:23:42 +0100 Subject: [erlang-questions] [Code Review] Is this a good idea? I linking 3 process manually (not using recursive) In-Reply-To: References: <4E027A0D-0DEE-48EC-86DC-93CE41B5E749@gmail.com> <06FE11A6-8875-4CFF-AEF3-1CB11B35BDF5@gmail.com> <3463DD52-1024-4F4B-AE0E-41BF648A0783@gmail.com> Message-ID: Greetings, If the intention is to always run these functions manually, one by one, then it is okay. If you want to be able to do this: procslinked:starter(), procslinked:call_the_third(). you might get into trouble since you send init_done before you spawn the next process. Add a timer:sleep(60000) right before every spawn_link( ) and you will see the problem. One solution is to send init_done after spawn_link(). Best Wishes, bengt > On 13 Mar 2019, at 08:46, I Gusti Ngurah Oka Prinarjaya wrote: > > Hi, > > This is my updated code: https://pastebin.com/D9SAPUG8 please review again. > > Please give me the pseudo code clue if there's more incorrectness to fix in my code. > > And this is the output when i run my erlang program > > Erlang/OTP 21 [erts-10.2] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] > > Eshell V10.2 (abort with ^G) > 1> c(procslinked). > Recompiling /Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/procslinked.erl > /Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/procslinked.erl:2: Warning: export_all flag enabled - all functions will be exported > {ok,procslinked} > 2> procslinked:starter(). > Receive init_done from P1 > Receive init_done from P2 > Receive init_done from P3 > {<0.91.0>,okbeud} > 3> procslinked:call_the_first(). > {<0.91.0>,"the_first_p()","Halo first p!"} > 4> procslinked:call_the_second(). > {<0.92.0>,"the_second_p()","Halo second p!"} > 5> procslinked:call_the_third(). > {<0.93.0>,"the_third_p()","Halo third p!"} > 6> procslinked:call_the_first(). > {<0.91.0>,"the_first_p()","Halo first p!"} > 7> procslinked:call_the_second(). > {<0.92.0>,"the_second_p()","Halo second p!"} > 8> procslinked:call_the_third(). > {<0.93.0>,"the_third_p()","Halo third p!"} > 9> > > Thank you :) > > > > > > Pada tanggal Sel, 12 Mar 2019 pukul 02.13 bengt > menulis: > Greetings, > > The race is that starter/0 will return before any of the three processes have started. If you add a timer:sleep( 60000 ) before the calls to register/0 you will see this even if you do call_the_first/0 manually. > > The pseudo code would be > My_pid = erlang:self(), > P = spawn(?MODULE, the_first_p, [My_pid]), > receive > {P, init_done} -> ok > end. > > And then sending {erlang:self(), init_done} to My_pid (the process that started the_first_p). > > >> On 11 Mar 2019, at 12:03, I Gusti Ngurah Oka Prinarjaya > wrote: >> >> Hi Andreas Schultz, >> >> >> The reason is that there is no guarantee that `call_the_third()` will be executed after any of the spawn has succeeded or the register was invoked. >> 1. Did you mean this code? https://pastebin.com/ECf3jhZ2 >> 2. and did you mean spawn_link/3 and register/2 is racy? >> 3. I've test this code many times, and never get error in each call_the_* function, even call_the_third/0 function. >> >> Here: https://learnyousomeerlang.com/the-hitchhikers-guide-to-concurrency , and here: https://learnyousomeerlang.com/more-on-multiprocessing and >> here: https://learnyousomeerlang.com/errors-and-processes teach me to do that. Oh My God, where in this earth i can read the best erlang process tutorial ? so i can use erlang in the right way. >> >> >> In order to get ordering guarantees you need to wait for the processes to be past the init stage. >> >> The normal way to do that is to wait for a message from the init function of you child process. >> Please give me a short pseudo-code clue to do this. I do really shocked because of this code: https://pastebin.com/ECf3jhZ2 still not correct after 2 times revision. >> >> Thank you :) >> >> >> >> Pada tanggal Sen, 11 Mar 2019 pukul 14.55 Andreas Schultz > menulis: >> You do realize that your code is still "racy" ? >> >> Invoking it like >> >> 2> procslinked:starter(), procslinked:call_the_third(). >> >> has a good chance of not producing the expected result. Most times it will simply fail with: >> >> ** exception error: bad argument >> in function procslinked:call_the_third/0 (procslinked.erl, line 54) >> >> The reason is that there is no guarantee that `call_the_third()` will be executed after any of the spawn has succeeded or the register was invoked. >> In order to get ordering guarantees you need to wait for the processes to be past the init stage. The normal way to do that is to wait for a message from the init function of you child process. >> >> BTW: this is exactly what proc_lib:init_ack does, but I guess you are trying to implement that yourself as a learning exercise. >> >> Andreas >> >> I Gusti Ngurah Oka Prinarjaya > schrieb am So., 10. M?rz 2019 um 23:38 Uhr: >> Hi Bengt, >> >> Thank you very much for all of your hints and suggestions. It's clear now. >> >> >> >> Pada tanggal Sen, 11 Mar 2019 05.20, bengt > menulis: >> I think your code is about learning erlang. Do that first. OTP is the next step. >> >> Yes, splitting a gen_server into callback module and interface module is not the OTP way (as described in documentation), so while good for a beginner it can be considered bad style by experienced programmers. >> >> Sorry, but I have not seen any tutorial about how to avoid thinking the same function/module is always in the same process. It is a very fundamental concept (them not being) in Erlang, so just keep it in mind. One way would be to try and make all your three functions the same function, just have different arguments to the loop. Then you must think about it. >> >> >>> On 10 Mar 2019, at 11:11, I Gusti Ngurah Oka Prinarjaya > wrote: >>> >>> Hi Bengt, >>> >>> Thank you for your review :) >>> >>> I don't quite understand with some of your thought. Then i hope you not mind to give more explanation. >>> >>> >> Seasoned Erlang programmers will tell you this is not the OTP way, or a waste of modules >>> Did you mean my code here: https://pastebin.com/ECf3jhZ2 wasn't the OTP way? >>> I learn from here: https://learnyousomeerlang.com/errors-and-processes and i do really a beginner at programming with erlang. >>> >>> >> So only do this until you have a better understanding. >>> What is that? Did you mean doing one module with the interface functions to a gen_server and one module for the gen_server callbacks.? >>> or what? >>> >>> >> Conflating the function (or even more often, module) and the process is a common mistake in the beginning. When my fellow programmers are experienced, but not used >> to process oriented programming. >>> Any tutorials / reference for me to avoid this mistake ? >>> >>> Thank you :) >>> >>> >>> >>> >>> >>> >>> >>> >>> Pada tanggal Min, 10 Mar 2019 pukul 14.49 bengt > menulis: >>> Conflating the function (or even more often, module) and the process is a common mistake in the beginning. When my fellow programmers are experienced, but not used to process oriented programming, I have found that it helps to put the code that is run in different process in different modules. Ex: one module with the interface functions to a gen_server and one module for the gen_server callbacks. Seasoned Erlang programmers will tell you this is not the OTP way, or a waste of modules. So only do this until you have a better understanding. >>> >>> bengt >>> >>>> On 10 Mar 2019, at 04:57, I Gusti Ngurah Oka Prinarjaya > wrote: >>>> >>>> Hi Bengt, >>>> >>>> Thank you for the idea, >>>> >>>> I've implement your idea, from performance side, i think using two version of function will have better performance because there's no need to checking using IF statement. >>>> >>>> I worry at first to implement this idea, because i think different version of function will have different PID, hahaha it turns out exactly have same PID. >>>> this is my new code https://pastebin.com/ECf3jhZ2 . Please review if there's any improvement needs. >>>> >>>> Thank you >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Pada tanggal Min, 10 Mar 2019 pukul 05.23 bengt > menulis: >>>> Greetings, >>>> >>>> The error happens the second time any of the three processes call erlang:register/2. They already registered themselves the first time. If you want this structure, but not the error, you have to do the register before starting the loop. Eg, split the functions into two. One that do the register and then calls the second that does the loop. >>>> >>>> bengt >>>> >>>>> On 9 Mar 2019, at 14:41, I Gusti Ngurah Oka Prinarjaya > wrote: >>>>> >>>>> Hi Attila Rajmund Nohl, >>>>> >>>>> After i implement your suggestion, i get error when execute any of function call_the_*_p() >>>>> for example: >>>>> >>>>> 3> newbie:starter(). >>>>> <0.112.0> >>>>> 4> newbie:call_the_second(). >>>>> =ERROR REPORT==== 9-Mar-2019::20:35:15.069388 === >>>>> Error in process <0.113.0> with exit value: >>>>> {badarg,[{erlang,register,[pidsecondp,<0.113.0>],[]}, >>>>> {newbie,the_second_p,0, >>>>> [{file,"/Users/okaprinarjaya/Oprek/Erlang-Oprek/oprek-lagi/src/newbie.erl"}, >>>>> {line,17}]}]} >>>>> >>>>> {<0.113.0>,"the_second_p()","Halo second p!"} >>>>> >>>>> This is my new modified code https://pastebin.com/iYCxkkuz >>>>> >>>>> >>>>> Pada tanggal Jum, 8 Mar 2019 pukul 21.03 Attila Rajmund Nohl > menulis: >>>>> I Gusti Ngurah Oka Prinarjaya > ezt ?rta >>>>> (id?pont: 2019. m?rc. 8., P, 12:11): >>>>> > >>>>> > Hi Folks, >>>>> > >>>>> > I need your help to review my code. I create and linking 3 process manually without using recursive. And inside p1 and p2 i using IF statement to check to make sure spawning process will only once. >>>>> > >>>>> > I mean, is part code below is a good idea? >>>>> > >>>>> > IsPidExists = whereis(xxx), >>>>> > if IsPidExists =:= undefined -> >>>>> > Pid = spawn_link(?MODULE, the_p, []), >>>>> > register(xxx, Pid); >>>>> > true -> true >>>>> > end, >>>>> >>>>> Generally this is not a good idea, there's a race condition between >>>>> checking that the process is registered (the whereis/1 call) and >>>>> registering the new process. A better idea is to start the process and >>>>> let the process itself to register. If register fails, it means that >>>>> there's already a process registered, so the just started process can >>>>> terminate. So your code could look like something like this: >>>>> >>>>> starter() -> >>>>> spawn(?MODULE, the_first_p, []). >>>>> >>>>> the_first_p() -> >>>>> register(pidfirstp, self()), >>>>> spawn_link(?MODULE, the_second_p, []), >>>>> ... >>>>> the_first_p(). >>>>> >>>>> Actually if the register call fails, it throws a badarg and the >>>>> process dies automatically, simplifying the code. >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> -- >> -- >> Dipl.-Inform. Andreas Schultz >> >> ----------------------- enabling your networks ---------------------- >> Travelping GmbH Phone: +49-391-81 90 99 0 >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 >> 39108 Magdeburg Email: info@REDACTED >> GERMANY Web: http://www.travelping.com >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 >> --------------------------------------------------------------------- > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Sat Mar 16 18:31:59 2019 From: bob@REDACTED (Bob Ippolito) Date: Sat, 16 Mar 2019 10:31:59 -0700 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: <20190316113207.GE10520@carfax.org.uk> References: <20190315225209.GD10520@carfax.org.uk> <20190316113207.GE10520@carfax.org.uk> Message-ID: While it's more code, the most straightforward way would be to parse the whole float for that spec into its constituent parts and reassemble (with defaults where necessary) to parse with float_to_list. On Sat, Mar 16, 2019 at 4:32 AM Hugo Mills wrote: > Hi, Bob, > > On Fri, Mar 15, 2019 at 05:32:54PM -0700, Bob Ippolito wrote: > > If you dive into the implementation it's effectively a wrapper around > > strtod from C with a validation pass that is more strict than the strtod > > standard. > > > > > https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54 > > > https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732 > > > > So as far as a regex goes it would be something like this: > > > > [+-]?\d+[.,]\d+([eE][+-]?\d+) > > > > The major differences between this and other popular float grammars are: > > > > * At least one digit is required in each part > > * Both integer and fractional parts are required, even if there's an > > exponent part (so "1", ".1", "1e-1" would not be valid) > > * The decimal separator is either , or . (the implementation will try the > > other if necessary to compensate for a different locale) > > Thanks for the confirmation. That's more or less what I discovered > while playing around with list_to_float. It's the first two cases that > are the problems for me, because the spec I'm working to(*) says that > "1." and ".3" are valid floats, for example, as is "1e-1". > > Just for the record, here's the code I'm using to convert a Turtle > double or decimal (the former in scientific notation; the latter > without the E) into a form suitable for list_to_float/1: > > [...] > % W3C's description of a float is wider than erlang's. We need to > % split up the number into a few parts to add extra characters > % where necessary so that list_to_float/1 will work right. > F = case string:lexemes(Text, "eE") of > [M, E] -> > fixup_decimal(M) ++ "e" ++ E; > [M] -> > fixup_decimal(M) > end, > O = lagra_model:new_literal(list_to_float(F)), > [...] > > -spec fixup_decimal(string()) -> string(). > fixup_decimal(M) -> > case string:lexemes(M, ".") of > [I] -> > I++".0"; > [I, ""] -> > I++".0"; > ["", J] -> > "0."++J; > [I, J] -> > M > end. > > Hugo. > > (*) W3C's Turtle recommendation. > > > > On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills wrote: > > > > > Where in the manual is the set of allowable string representations > > > of floating point numbers documented? I'd have expected it to be here: > > > > > > http://erlang.org/doc/reference_manual/data_types.html > > > > > > ... but apparently not. > > > > > > Specifically, I'm trying to use list_to_float/1, and I've been > > > trying to reverse engineer it: > > > > > > 1> list_to_float("-1"). > > > ** exception error: bad argument > > > in function list_to_float/1 > > > called as list_to_float("-1") > > > 2> list_to_float("-1.0"). > > > -1.0 > > > 3> list_to_float("-1.0e-23"). > > > -1.0e-23 > > > 4> list_to_float("-1e-23"). > > > ** exception error: bad argument > > > in function list_to_float/1 > > > called as list_to_float("-1e-23") > > > 5> list_to_float(".3"). > > > ** exception error: bad argument > > > in function list_to_float/1 > > > called as list_to_float(".3") > > > > > > An actual written specification would be really handy here. Even > > > just a regex or EBNF for them. I'm writing a parser for something > > > where the definition of floating point literals isn't quite the same > > > as Erlang's, and it's a bit painful. > > > > > > Hugo. > > > > > -- > Hugo Mills | Nostalgia isn't what it used to be. > hugo@REDACTED carfax.org.uk | > http://carfax.org.uk/ | > PGP: E2AB1DE4 | > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBAgAGBQJcjN62AAoJEFheFHXiqx3kiPAP/3V2SC+mFVSIjRw0moQC6keJ > x8A+005H7+SO030G5/a0TYXEe9wxn1KEtQEEyG2yt6A1XASeERRFuAPeeFMEhti+ > trr1oYJmbSTUgvRs1i5jhSH7KmUEt09I+JgS3u0Xs92LkmNyfFde8K3z6uA1XKwp > 7tIHihrXYpk/jMamWXTNGYPlHtxcVxAToNK8ajQTz6dElurZYdHwHtnFv7Ya7jcf > 7w9fKG4XcIoQZHMBrnZF8g2UQIgWiMpz7eo5lko91Zbjetgv1qkKaiNonA+rai4b > CVIXJ+YIT1dHNEQ76uVqJQuuklUB0M5B+FCX/zuS5Zd7mta9ljzBHefGLzQYT+EE > Y4En5n+YvL5OUCqw0EBBXBTYcsdn8rP0+jSy3nFiX6zV4Ty49NrKCSN0LGQJVpkz > wv1Sl05QBC2JcyCYqrCoMdudPNdcgK/TvB+H7KYcZDy3mgoZJ55U12Ys6Ng80tIa > 3eUis3W4vZLdS9Gfn8GY4A42APvv6X3W9bVN5JEISUlF3CdKui/RItZiQ8whx4iF > 6E+KzkO6AgmgyGKbAXK5N8S0MWuNT3g/V/tm7siY3GDG6cDIQNZRxevMXhAZ9nIv > S3kAiz1JBUKIMWv3RCz77+gKPI7AiUBHlfmXsjudSbnJ9r6nxhbCjbbypmHOzZYx > 5uMAhklJZ0OnQgmxOfVU > =0Eaq > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From starbelly@REDACTED Sat Mar 16 18:35:40 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sat, 16 Mar 2019 12:35:40 -0500 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: References: <20190315225209.GD10520@carfax.org.uk> <20190316113207.GE10520@carfax.org.uk> Message-ID: <4b5b55d2-5c7a-4a7d-99f2-dd5249a073d7@pobox.com> ?All of this begs the question of why there is no decimal lib in otp... I'm sure there's a good reason... ? On 3/16/19 12:31 PM, Bob Ippolito wrote: > While it's more code, the most straightforward way would be to parse > the whole float for that spec into its constituent parts and > reassemble (with defaults where necessary) to parse with float_to_list. > > > > > On Sat, Mar 16, 2019 at 4:32 AM Hugo Mills > wrote: > > ? ?Hi, Bob, > > On Fri, Mar 15, 2019 at 05:32:54PM -0700, Bob Ippolito wrote: > > If you dive into the implementation it's effectively a wrapper > around > > strtod from C with a validation pass that is more strict than > the strtod > > standard. > > > > > https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54 > > > https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732 > > > > So as far as a regex goes it would be something like this: > > > > [+-]?\d+[.,]\d+([eE][+-]?\d+) > > > > The major differences between this and other popular float > grammars are: > > > > * At least one digit is required in each part > > * Both integer and fractional parts are required, even if there's an > > exponent part (so "1", ".1", "1e-1" would not be valid) > > * The decimal separator is either , or . (the implementation > will try the > > other if necessary to compensate for a different locale) > > ? ?Thanks for the confirmation. That's more or less what I discovered > while playing around with list_to_float. It's the first two cases that > are the problems for me, because the spec I'm working to(*) says that > "1." and ".3" are valid floats, for example, as is "1e-1". > > ? ?Just for the record, here's the code I'm using to convert a Turtle > double or decimal (the former in scientific notation; the latter > without the E) into a form suitable for list_to_float/1: > > ? ? [...] > ? ? % W3C's description of a float is wider than erlang's. We need to > ? ? % split up the number into a few parts to add extra characters > ? ? % where necessary so that list_to_float/1 will work right. > ? ? F = case string:lexemes(Text, "eE") of > ? ? ? ? [M, E] -> > ? ? ? ? ? ? fixup_decimal(M) ++ "e" ++ E; > ? ? ? ? [M] -> > ? ? ? ? ? ? fixup_decimal(M) > ? ? end, > ? ? O = lagra_model:new_literal(list_to_float(F)), > ? ? [...] > > -spec fixup_decimal(string()) -> string(). > fixup_decimal(M) -> > ? ? case string:lexemes(M, ".") of > ? ? ? ? [I] -> > ? ? ? ? ? ? I++".0"; > ? ? ? ? [I, ""] -> > ? ? ? ? ? ? I++".0"; > ? ? ? ? ["", J] -> > ? ? ? ? ? ? "0."++J; > ? ? ? ? [I, J] -> > ? ? ? ? ? ? M > ? ? end. > > ? ?Hugo. > > (*) W3C's Turtle recommendation. > > > > On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills > wrote: > > > > >? ? Where in the manual is the set of allowable string > representations > > > of floating point numbers documented? I'd have expected it to > be here: > > > > > > http://erlang.org/doc/reference_manual/data_types.html > > > > > > ... but apparently not. > > > > > >? ? Specifically, I'm trying to use list_to_float/1, and I've been > > > trying to reverse engineer it: > > > > > > 1> list_to_float("-1"). > > > ** exception error: bad argument > > >? ? ? in function? list_to_float/1 > > >? ? ? ? ?called as list_to_float("-1") > > > 2> list_to_float("-1.0"). > > > -1.0 > > > 3> list_to_float("-1.0e-23"). > > > -1.0e-23 > > > 4> list_to_float("-1e-23"). > > > ** exception error: bad argument > > >? ? ? in function? list_to_float/1 > > >? ? ? ? ?called as list_to_float("-1e-23") > > > 5> list_to_float(".3"). > > > ** exception error: bad argument > > >? ? ? in function? list_to_float/1 > > >? ? ? ? ?called as list_to_float(".3") > > > > > >? ? An actual written specification would be really handy here. > Even > > > just a regex or EBNF for them. I'm writing a parser for something > > > where the definition of floating point literals isn't quite > the same > > > as Erlang's, and it's a bit painful. > > > > > >? ? Hugo. > > > > > -- > Hugo Mills? ? ? ? ? ? ?| Nostalgia isn't what it used to be. > hugo@REDACTED carfax.org.uk | > http://carfax.org.uk/? | > PGP: E2AB1DE4? ? ? ? ? | > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBAgAGBQJcjN62AAoJEFheFHXiqx3kiPAP/3V2SC+mFVSIjRw0moQC6keJ > x8A+005H7+SO030G5/a0TYXEe9wxn1KEtQEEyG2yt6A1XASeERRFuAPeeFMEhti+ > trr1oYJmbSTUgvRs1i5jhSH7KmUEt09I+JgS3u0Xs92LkmNyfFde8K3z6uA1XKwp > 7tIHihrXYpk/jMamWXTNGYPlHtxcVxAToNK8ajQTz6dElurZYdHwHtnFv7Ya7jcf > 7w9fKG4XcIoQZHMBrnZF8g2UQIgWiMpz7eo5lko91Zbjetgv1qkKaiNonA+rai4b > CVIXJ+YIT1dHNEQ76uVqJQuuklUB0M5B+FCX/zuS5Zd7mta9ljzBHefGLzQYT+EE > Y4En5n+YvL5OUCqw0EBBXBTYcsdn8rP0+jSy3nFiX6zV4Ty49NrKCSN0LGQJVpkz > wv1Sl05QBC2JcyCYqrCoMdudPNdcgK/TvB+H7KYcZDy3mgoZJ55U12Ys6Ng80tIa > 3eUis3W4vZLdS9Gfn8GY4A42APvv6X3W9bVN5JEISUlF3CdKui/RItZiQ8whx4iF > 6E+KzkO6AgmgyGKbAXK5N8S0MWuNT3g/V/tm7siY3GDG6cDIQNZRxevMXhAZ9nIv > S3kAiz1JBUKIMWv3RCz77+gKPI7AiUBHlfmXsjudSbnJ9r6nxhbCjbbypmHOzZYx > 5uMAhklJZ0OnQgmxOfVU > =0Eaq > -----END PGP SIGNATURE----- > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Bryan Paxton -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Sun Mar 17 07:29:21 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Sun, 17 Mar 2019 19:29:21 +1300 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: <4b5b55d2-5c7a-4a7d-99f2-dd5249a073d7@pobox.com> References: <20190315225209.GD10520@carfax.org.uk> <20190316113207.GE10520@carfax.org.uk> <4b5b55d2-5c7a-4a7d-99f2-dd5249a073d7@pobox.com> Message-ID: What do you mean by "a decimal lib"? On Sun, 17 Mar 2019 at 06:35, Bryan Paxton wrote: > All of this begs the question of why there is no decimal lib in otp... > I'm sure there's a good reason... ? > > > On 3/16/19 12:31 PM, Bob Ippolito wrote: > > While it's more code, the most straightforward way would be to parse the > whole float for that spec into its constituent parts and reassemble (with > defaults where necessary) to parse with float_to_list. > > > > > On Sat, Mar 16, 2019 at 4:32 AM Hugo Mills wrote: > >> Hi, Bob, >> >> On Fri, Mar 15, 2019 at 05:32:54PM -0700, Bob Ippolito wrote: >> > If you dive into the implementation it's effectively a wrapper around >> > strtod from C with a validation pass that is more strict than the strtod >> > standard. >> > >> > >> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54 >> > >> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732 >> > >> > So as far as a regex goes it would be something like this: >> > >> > [+-]?\d+[.,]\d+([eE][+-]?\d+) >> > >> > The major differences between this and other popular float grammars are: >> > >> > * At least one digit is required in each part >> > * Both integer and fractional parts are required, even if there's an >> > exponent part (so "1", ".1", "1e-1" would not be valid) >> > * The decimal separator is either , or . (the implementation will try >> the >> > other if necessary to compensate for a different locale) >> >> Thanks for the confirmation. That's more or less what I discovered >> while playing around with list_to_float. It's the first two cases that >> are the problems for me, because the spec I'm working to(*) says that >> "1." and ".3" are valid floats, for example, as is "1e-1". >> >> Just for the record, here's the code I'm using to convert a Turtle >> double or decimal (the former in scientific notation; the latter >> without the E) into a form suitable for list_to_float/1: >> >> [...] >> % W3C's description of a float is wider than erlang's. We need to >> % split up the number into a few parts to add extra characters >> % where necessary so that list_to_float/1 will work right. >> F = case string:lexemes(Text, "eE") of >> [M, E] -> >> fixup_decimal(M) ++ "e" ++ E; >> [M] -> >> fixup_decimal(M) >> end, >> O = lagra_model:new_literal(list_to_float(F)), >> [...] >> >> -spec fixup_decimal(string()) -> string(). >> fixup_decimal(M) -> >> case string:lexemes(M, ".") of >> [I] -> >> I++".0"; >> [I, ""] -> >> I++".0"; >> ["", J] -> >> "0."++J; >> [I, J] -> >> M >> end. >> >> Hugo. >> >> (*) W3C's Turtle recommendation. >> >> >> > On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills wrote: >> > >> > > Where in the manual is the set of allowable string representations >> > > of floating point numbers documented? I'd have expected it to be here: >> > > >> > > http://erlang.org/doc/reference_manual/data_types.html >> > > >> > > ... but apparently not. >> > > >> > > Specifically, I'm trying to use list_to_float/1, and I've been >> > > trying to reverse engineer it: >> > > >> > > 1> list_to_float("-1"). >> > > ** exception error: bad argument >> > > in function list_to_float/1 >> > > called as list_to_float("-1") >> > > 2> list_to_float("-1.0"). >> > > -1.0 >> > > 3> list_to_float("-1.0e-23"). >> > > -1.0e-23 >> > > 4> list_to_float("-1e-23"). >> > > ** exception error: bad argument >> > > in function list_to_float/1 >> > > called as list_to_float("-1e-23") >> > > 5> list_to_float(".3"). >> > > ** exception error: bad argument >> > > in function list_to_float/1 >> > > called as list_to_float(".3") >> > > >> > > An actual written specification would be really handy here. Even >> > > just a regex or EBNF for them. I'm writing a parser for something >> > > where the definition of floating point literals isn't quite the same >> > > as Erlang's, and it's a bit painful. >> > > >> > > Hugo. >> > > >> >> -- >> Hugo Mills | Nostalgia isn't what it used to be. >> hugo@REDACTED carfax.org.uk | >> http://carfax.org.uk/ | >> PGP: E2AB1DE4 | >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iQIcBAEBAgAGBQJcjN62AAoJEFheFHXiqx3kiPAP/3V2SC+mFVSIjRw0moQC6keJ >> x8A+005H7+SO030G5/a0TYXEe9wxn1KEtQEEyG2yt6A1XASeERRFuAPeeFMEhti+ >> trr1oYJmbSTUgvRs1i5jhSH7KmUEt09I+JgS3u0Xs92LkmNyfFde8K3z6uA1XKwp >> 7tIHihrXYpk/jMamWXTNGYPlHtxcVxAToNK8ajQTz6dElurZYdHwHtnFv7Ya7jcf >> 7w9fKG4XcIoQZHMBrnZF8g2UQIgWiMpz7eo5lko91Zbjetgv1qkKaiNonA+rai4b >> CVIXJ+YIT1dHNEQ76uVqJQuuklUB0M5B+FCX/zuS5Zd7mta9ljzBHefGLzQYT+EE >> Y4En5n+YvL5OUCqw0EBBXBTYcsdn8rP0+jSy3nFiX6zV4Ty49NrKCSN0LGQJVpkz >> wv1Sl05QBC2JcyCYqrCoMdudPNdcgK/TvB+H7KYcZDy3mgoZJ55U12Ys6Ng80tIa >> 3eUis3W4vZLdS9Gfn8GY4A42APvv6X3W9bVN5JEISUlF3CdKui/RItZiQ8whx4iF >> 6E+KzkO6AgmgyGKbAXK5N8S0MWuNT3g/V/tm7siY3GDG6cDIQNZRxevMXhAZ9nIv >> S3kAiz1JBUKIMWv3RCz77+gKPI7AiUBHlfmXsjudSbnJ9r6nxhbCjbbypmHOzZYx >> 5uMAhklJZ0OnQgmxOfVU >> =0Eaq >> -----END PGP SIGNATURE----- >> > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > > -- > > Bryan Paxton > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From starbelly@REDACTED Sun Mar 17 09:17:57 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sun, 17 Mar 2019 03:17:57 -0500 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: References: <20190315225209.GD10520@carfax.org.uk> <20190316113207.GE10520@carfax.org.uk> <4b5b55d2-5c7a-4a7d-99f2-dd5249a073d7@pobox.com> Message-ID: A library that implements IEEE-754:??http://speleotrove.com/decimal/ Example implementations in Erlang: https://github.com/tim/erlang-decimal https://github.com/egobrain/decimal On 3/17/19 1:29 AM, Richard O'Keefe wrote: > What do you mean by "a decimal lib"? > > On Sun, 17 Mar 2019 at 06:35, Bryan Paxton > wrote: > > ?All of this begs the question of why there is no decimal lib in > otp... I'm sure there's a good reason... ? > > > On 3/16/19 12:31 PM, Bob Ippolito wrote: >> While it's more code, the most straightforward way would be to >> parse the whole float for that spec into its constituent parts >> and reassemble (with defaults where necessary) to parse with >> float_to_list. >> >> >> >> >> On Sat, Mar 16, 2019 at 4:32 AM Hugo Mills > > wrote: >> >> ? ?Hi, Bob, >> >> On Fri, Mar 15, 2019 at 05:32:54PM -0700, Bob Ippolito wrote: >> > If you dive into the implementation it's effectively a >> wrapper around >> > strtod from C with a validation pass that is more strict >> than the strtod >> > standard. >> > >> > >> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54 >> > >> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732 >> > >> > So as far as a regex goes it would be something like this: >> > >> > [+-]?\d+[.,]\d+([eE][+-]?\d+) >> > >> > The major differences between this and other popular float >> grammars are: >> > >> > * At least one digit is required in each part >> > * Both integer and fractional parts are required, even if >> there's an >> > exponent part (so "1", ".1", "1e-1" would not be valid) >> > * The decimal separator is either , or . (the >> implementation will try the >> > other if necessary to compensate for a different locale) >> >> ? ?Thanks for the confirmation. That's more or less what I >> discovered >> while playing around with list_to_float. It's the first two >> cases that >> are the problems for me, because the spec I'm working to(*) >> says that >> "1." and ".3" are valid floats, for example, as is "1e-1". >> >> ? ?Just for the record, here's the code I'm using to convert >> a Turtle >> double or decimal (the former in scientific notation; the latter >> without the E) into a form suitable for list_to_float/1: >> >> ? ? [...] >> ? ? % W3C's description of a float is wider than erlang's. We >> need to >> ? ? % split up the number into a few parts to add extra >> characters >> ? ? % where necessary so that list_to_float/1 will work right. >> ? ? F = case string:lexemes(Text, "eE") of >> ? ? ? ? [M, E] -> >> ? ? ? ? ? ? fixup_decimal(M) ++ "e" ++ E; >> ? ? ? ? [M] -> >> ? ? ? ? ? ? fixup_decimal(M) >> ? ? end, >> ? ? O = lagra_model:new_literal(list_to_float(F)), >> ? ? [...] >> >> -spec fixup_decimal(string()) -> string(). >> fixup_decimal(M) -> >> ? ? case string:lexemes(M, ".") of >> ? ? ? ? [I] -> >> ? ? ? ? ? ? I++".0"; >> ? ? ? ? [I, ""] -> >> ? ? ? ? ? ? I++".0"; >> ? ? ? ? ["", J] -> >> ? ? ? ? ? ? "0."++J; >> ? ? ? ? [I, J] -> >> ? ? ? ? ? ? M >> ? ? end. >> >> ? ?Hugo. >> >> (*) W3C's Turtle recommendation. >> >> >> > On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills >> > wrote: >> > >> > >? ? Where in the manual is the set of allowable string >> representations >> > > of floating point numbers documented? I'd have expected >> it to be here: >> > > >> > > http://erlang.org/doc/reference_manual/data_types.html >> > > >> > > ... but apparently not. >> > > >> > >? ? Specifically, I'm trying to use list_to_float/1, and >> I've been >> > > trying to reverse engineer it: >> > > >> > > 1> list_to_float("-1"). >> > > ** exception error: bad argument >> > >? ? ? in function? list_to_float/1 >> > >? ? ? ? ?called as list_to_float("-1") >> > > 2> list_to_float("-1.0"). >> > > -1.0 >> > > 3> list_to_float("-1.0e-23"). >> > > -1.0e-23 >> > > 4> list_to_float("-1e-23"). >> > > ** exception error: bad argument >> > >? ? ? in function? list_to_float/1 >> > >? ? ? ? ?called as list_to_float("-1e-23") >> > > 5> list_to_float(".3"). >> > > ** exception error: bad argument >> > >? ? ? in function? list_to_float/1 >> > >? ? ? ? ?called as list_to_float(".3") >> > > >> > >? ? An actual written specification would be really handy >> here. Even >> > > just a regex or EBNF for them. I'm writing a parser for >> something >> > > where the definition of floating point literals isn't >> quite the same >> > > as Erlang's, and it's a bit painful. >> > > >> > >? ? Hugo. >> > > >> >> -- >> Hugo Mills? ? ? ? ? ? ?| Nostalgia isn't what it used to be. >> hugo@REDACTED carfax.org.uk | >> http://carfax.org.uk/? | >> PGP: E2AB1DE4? ? ? ? ? | >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iQIcBAEBAgAGBQJcjN62AAoJEFheFHXiqx3kiPAP/3V2SC+mFVSIjRw0moQC6keJ >> x8A+005H7+SO030G5/a0TYXEe9wxn1KEtQEEyG2yt6A1XASeERRFuAPeeFMEhti+ >> trr1oYJmbSTUgvRs1i5jhSH7KmUEt09I+JgS3u0Xs92LkmNyfFde8K3z6uA1XKwp >> 7tIHihrXYpk/jMamWXTNGYPlHtxcVxAToNK8ajQTz6dElurZYdHwHtnFv7Ya7jcf >> 7w9fKG4XcIoQZHMBrnZF8g2UQIgWiMpz7eo5lko91Zbjetgv1qkKaiNonA+rai4b >> CVIXJ+YIT1dHNEQ76uVqJQuuklUB0M5B+FCX/zuS5Zd7mta9ljzBHefGLzQYT+EE >> Y4En5n+YvL5OUCqw0EBBXBTYcsdn8rP0+jSy3nFiX6zV4Ty49NrKCSN0LGQJVpkz >> wv1Sl05QBC2JcyCYqrCoMdudPNdcgK/TvB+H7KYcZDy3mgoZJ55U12Ys6Ng80tIa >> 3eUis3W4vZLdS9Gfn8GY4A42APvv6X3W9bVN5JEISUlF3CdKui/RItZiQ8whx4iF >> 6E+KzkO6AgmgyGKbAXK5N8S0MWuNT3g/V/tm7siY3GDG6cDIQNZRxevMXhAZ9nIv >> S3kAiz1JBUKIMWv3RCz77+gKPI7AiUBHlfmXsjudSbnJ9r6nxhbCjbbypmHOzZYx >> 5uMAhklJZ0OnQgmxOfVU >> =0Eaq >> -----END PGP SIGNATURE----- >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > > Bryan Paxton > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Sun Mar 17 09:40:53 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Sun, 17 Mar 2019 21:40:53 +1300 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: References: <20190315225209.GD10520@carfax.org.uk> <20190316113207.GE10520@carfax.org.uk> <4b5b55d2-5c7a-4a7d-99f2-dd5249a073d7@pobox.com> Message-ID: Me, I'd have taken Cowlishaw's reference implementation in C or the Intel library https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library and wrapped a NIF around it. If I needed it. z/Series and POWER have decimal FP in their instruction sets, but on other machines it's emulation or nothing. Erlang/OTP is very much influenced by its users' needs. (It doesn't always move *fast*, you understand, but when you want to develop long-lived systems that can be a good thing.) Why not write up an EEP? On Sun, 17 Mar 2019 at 21:18, Bryan Paxton wrote: > A library that implements IEEE-754: http://speleotrove.com/decimal/ > > Example implementations in Erlang: > > https://github.com/tim/erlang-decimal > > https://github.com/egobrain/decimal > > > On 3/17/19 1:29 AM, Richard O'Keefe wrote: > > What do you mean by "a decimal lib"? > > On Sun, 17 Mar 2019 at 06:35, Bryan Paxton wrote: > >> All of this begs the question of why there is no decimal lib in otp... >> I'm sure there's a good reason... ? >> >> >> On 3/16/19 12:31 PM, Bob Ippolito wrote: >> >> While it's more code, the most straightforward way would be to parse the >> whole float for that spec into its constituent parts and reassemble (with >> defaults where necessary) to parse with float_to_list. >> >> >> >> >> On Sat, Mar 16, 2019 at 4:32 AM Hugo Mills wrote: >> >>> Hi, Bob, >>> >>> On Fri, Mar 15, 2019 at 05:32:54PM -0700, Bob Ippolito wrote: >>> > If you dive into the implementation it's effectively a wrapper around >>> > strtod from C with a validation pass that is more strict than the >>> strtod >>> > standard. >>> > >>> > >>> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54 >>> > >>> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732 >>> > >>> > So as far as a regex goes it would be something like this: >>> > >>> > [+-]?\d+[.,]\d+([eE][+-]?\d+) >>> > >>> > The major differences between this and other popular float grammars >>> are: >>> > >>> > * At least one digit is required in each part >>> > * Both integer and fractional parts are required, even if there's an >>> > exponent part (so "1", ".1", "1e-1" would not be valid) >>> > * The decimal separator is either , or . (the implementation will try >>> the >>> > other if necessary to compensate for a different locale) >>> >>> Thanks for the confirmation. That's more or less what I discovered >>> while playing around with list_to_float. It's the first two cases that >>> are the problems for me, because the spec I'm working to(*) says that >>> "1." and ".3" are valid floats, for example, as is "1e-1". >>> >>> Just for the record, here's the code I'm using to convert a Turtle >>> double or decimal (the former in scientific notation; the latter >>> without the E) into a form suitable for list_to_float/1: >>> >>> [...] >>> % W3C's description of a float is wider than erlang's. We need to >>> % split up the number into a few parts to add extra characters >>> % where necessary so that list_to_float/1 will work right. >>> F = case string:lexemes(Text, "eE") of >>> [M, E] -> >>> fixup_decimal(M) ++ "e" ++ E; >>> [M] -> >>> fixup_decimal(M) >>> end, >>> O = lagra_model:new_literal(list_to_float(F)), >>> [...] >>> >>> -spec fixup_decimal(string()) -> string(). >>> fixup_decimal(M) -> >>> case string:lexemes(M, ".") of >>> [I] -> >>> I++".0"; >>> [I, ""] -> >>> I++".0"; >>> ["", J] -> >>> "0."++J; >>> [I, J] -> >>> M >>> end. >>> >>> Hugo. >>> >>> (*) W3C's Turtle recommendation. >>> >>> >>> > On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills wrote: >>> > >>> > > Where in the manual is the set of allowable string representations >>> > > of floating point numbers documented? I'd have expected it to be >>> here: >>> > > >>> > > http://erlang.org/doc/reference_manual/data_types.html >>> > > >>> > > ... but apparently not. >>> > > >>> > > Specifically, I'm trying to use list_to_float/1, and I've been >>> > > trying to reverse engineer it: >>> > > >>> > > 1> list_to_float("-1"). >>> > > ** exception error: bad argument >>> > > in function list_to_float/1 >>> > > called as list_to_float("-1") >>> > > 2> list_to_float("-1.0"). >>> > > -1.0 >>> > > 3> list_to_float("-1.0e-23"). >>> > > -1.0e-23 >>> > > 4> list_to_float("-1e-23"). >>> > > ** exception error: bad argument >>> > > in function list_to_float/1 >>> > > called as list_to_float("-1e-23") >>> > > 5> list_to_float(".3"). >>> > > ** exception error: bad argument >>> > > in function list_to_float/1 >>> > > called as list_to_float(".3") >>> > > >>> > > An actual written specification would be really handy here. Even >>> > > just a regex or EBNF for them. I'm writing a parser for something >>> > > where the definition of floating point literals isn't quite the same >>> > > as Erlang's, and it's a bit painful. >>> > > >>> > > Hugo. >>> > > >>> >>> -- >>> Hugo Mills | Nostalgia isn't what it used to be. >>> hugo@REDACTED carfax.org.uk | >>> http://carfax.org.uk/ | >>> PGP: E2AB1DE4 | >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.12 (GNU/Linux) >>> >>> iQIcBAEBAgAGBQJcjN62AAoJEFheFHXiqx3kiPAP/3V2SC+mFVSIjRw0moQC6keJ >>> x8A+005H7+SO030G5/a0TYXEe9wxn1KEtQEEyG2yt6A1XASeERRFuAPeeFMEhti+ >>> trr1oYJmbSTUgvRs1i5jhSH7KmUEt09I+JgS3u0Xs92LkmNyfFde8K3z6uA1XKwp >>> 7tIHihrXYpk/jMamWXTNGYPlHtxcVxAToNK8ajQTz6dElurZYdHwHtnFv7Ya7jcf >>> 7w9fKG4XcIoQZHMBrnZF8g2UQIgWiMpz7eo5lko91Zbjetgv1qkKaiNonA+rai4b >>> CVIXJ+YIT1dHNEQ76uVqJQuuklUB0M5B+FCX/zuS5Zd7mta9ljzBHefGLzQYT+EE >>> Y4En5n+YvL5OUCqw0EBBXBTYcsdn8rP0+jSy3nFiX6zV4Ty49NrKCSN0LGQJVpkz >>> wv1Sl05QBC2JcyCYqrCoMdudPNdcgK/TvB+H7KYcZDy3mgoZJ55U12Ys6Ng80tIa >>> 3eUis3W4vZLdS9Gfn8GY4A42APvv6X3W9bVN5JEISUlF3CdKui/RItZiQ8whx4iF >>> 6E+KzkO6AgmgyGKbAXK5N8S0MWuNT3g/V/tm7siY3GDG6cDIQNZRxevMXhAZ9nIv >>> S3kAiz1JBUKIMWv3RCz77+gKPI7AiUBHlfmXsjudSbnJ9r6nxhbCjbbypmHOzZYx >>> 5uMAhklJZ0OnQgmxOfVU >>> =0Eaq >>> -----END PGP SIGNATURE----- >>> >> >> _______________________________________________ >> erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions >> >> >> -- >> >> Bryan Paxton >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t6sn7gt@REDACTED Sun Mar 17 17:10:43 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Sun, 17 Mar 2019 12:10:43 -0400 Subject: [erlang-questions] Recommendations re beam files [SOLVED] In-Reply-To: References: Message-ID: <981ab431-f7d8-aff4-e9e2-16f3a48d2830@aim.com> Thanks everyone for your help with this.? The solution was to be found in one of Joe's posts: http://erlang.org/pipermail/erlang-questions/2012-October/070217.html Simplifying it for my needs (running the Linux subsystem in Windows 10), it consists of making a file .erlang in my home directory comprising one line: code:add_patha("/home/das/Development/erlang/library/beams"). (It verges on magic!) Don From starbelly@REDACTED Sun Mar 17 17:28:34 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sun, 17 Mar 2019 11:28:34 -0500 Subject: [erlang-questions] String representations of floating point numbers In-Reply-To: References: <20190315225209.GD10520@carfax.org.uk> <20190316113207.GE10520@carfax.org.uk> <4b5b55d2-5c7a-4a7d-99f2-dd5249a073d7@pobox.com> Message-ID: <7cc90bf4-5f73-58dc-3d55-260b20f4af0a@pobox.com> On 3/17/19 3:40 AM, Richard O'Keefe wrote: > Me, I'd have taken Cowlishaw's reference implementation in C or the > Intel library > https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library > and wrapped a NIF around it. ?Interesting. I'll dive deeper into that for sure. > > If I needed it.? z/Series and POWER have decimal FP in their > instruction sets, but on other machines it's emulation or nothing. > > Erlang/OTP is very much influenced by its users' needs. > (It doesn't always move *fast*, you understand, but when you > want to develop long-lived systems that can be a good thing.) ?I agree :) 100% > Why not write up an EEP? ?Maybe ;) I think there are a few others in the community who are better suited for such a thing, but we shall see! Thanks RoK! -- Bryan > > > > > On Sun, 17 Mar 2019 at 21:18, Bryan Paxton > wrote: > > A library that implements IEEE-754:??http://speleotrove.com/decimal/ > > Example implementations in Erlang: > > https://github.com/tim/erlang-decimal > > https://github.com/egobrain/decimal > > > On 3/17/19 1:29 AM, Richard O'Keefe wrote: >> What do you mean by "a decimal lib"? >> >> On Sun, 17 Mar 2019 at 06:35, Bryan Paxton > > wrote: >> >> ?All of this begs the question of why there is no decimal lib >> in otp... I'm sure there's a good reason... ? >> >> >> On 3/16/19 12:31 PM, Bob Ippolito wrote: >>> While it's more code, the most straightforward way would be >>> to parse the whole float for that spec into its constituent >>> parts and reassemble (with defaults where necessary) to >>> parse with float_to_list. >>> >>> >>> >>> >>> On Sat, Mar 16, 2019 at 4:32 AM Hugo Mills >>> > wrote: >>> >>> ? ?Hi, Bob, >>> >>> On Fri, Mar 15, 2019 at 05:32:54PM -0700, Bob Ippolito >>> wrote: >>> > If you dive into the implementation it's effectively a >>> wrapper around >>> > strtod from C with a validation pass that is more >>> strict than the strtod >>> > standard. >>> > >>> > >>> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/win32/sys_float.c#L54 >>> > >>> https://github.com/erlang/otp/blob/OTP-21.3/erts/emulator/sys/unix/sys_float.c#L732 >>> > >>> > So as far as a regex goes it would be something like this: >>> > >>> > [+-]?\d+[.,]\d+([eE][+-]?\d+) >>> > >>> > The major differences between this and other popular >>> float grammars are: >>> > >>> > * At least one digit is required in each part >>> > * Both integer and fractional parts are required, even >>> if there's an >>> > exponent part (so "1", ".1", "1e-1" would not be valid) >>> > * The decimal separator is either , or . (the >>> implementation will try the >>> > other if necessary to compensate for a different locale) >>> >>> ? ?Thanks for the confirmation. That's more or less what >>> I discovered >>> while playing around with list_to_float. It's the first >>> two cases that >>> are the problems for me, because the spec I'm working >>> to(*) says that >>> "1." and ".3" are valid floats, for example, as is "1e-1". >>> >>> ? ?Just for the record, here's the code I'm using to >>> convert a Turtle >>> double or decimal (the former in scientific notation; >>> the latter >>> without the E) into a form suitable for list_to_float/1: >>> >>> ? ? [...] >>> ? ? % W3C's description of a float is wider than >>> erlang's. We need to >>> ? ? % split up the number into a few parts to add extra >>> characters >>> ? ? % where necessary so that list_to_float/1 will work >>> right. >>> ? ? F = case string:lexemes(Text, "eE") of >>> ? ? ? ? [M, E] -> >>> ? ? ? ? ? ? fixup_decimal(M) ++ "e" ++ E; >>> ? ? ? ? [M] -> >>> ? ? ? ? ? ? fixup_decimal(M) >>> ? ? end, >>> ? ? O = lagra_model:new_literal(list_to_float(F)), >>> ? ? [...] >>> >>> -spec fixup_decimal(string()) -> string(). >>> fixup_decimal(M) -> >>> ? ? case string:lexemes(M, ".") of >>> ? ? ? ? [I] -> >>> ? ? ? ? ? ? I++".0"; >>> ? ? ? ? [I, ""] -> >>> ? ? ? ? ? ? I++".0"; >>> ? ? ? ? ["", J] -> >>> ? ? ? ? ? ? "0."++J; >>> ? ? ? ? [I, J] -> >>> ? ? ? ? ? ? M >>> ? ? end. >>> >>> ? ?Hugo. >>> >>> (*) W3C's Turtle recommendation. >>> >>> >>> > On Fri, Mar 15, 2019 at 3:52 PM Hugo Mills >>> > wrote: >>> > >>> > >? ? Where in the manual is the set of allowable >>> string representations >>> > > of floating point numbers documented? I'd have >>> expected it to be here: >>> > > >>> > > http://erlang.org/doc/reference_manual/data_types.html >>> > > >>> > > ... but apparently not. >>> > > >>> > >? ? Specifically, I'm trying to use list_to_float/1, >>> and I've been >>> > > trying to reverse engineer it: >>> > > >>> > > 1> list_to_float("-1"). >>> > > ** exception error: bad argument >>> > >? ? ? in function? list_to_float/1 >>> > >? ? ? ? ?called as list_to_float("-1") >>> > > 2> list_to_float("-1.0"). >>> > > -1.0 >>> > > 3> list_to_float("-1.0e-23"). >>> > > -1.0e-23 >>> > > 4> list_to_float("-1e-23"). >>> > > ** exception error: bad argument >>> > >? ? ? in function? list_to_float/1 >>> > >? ? ? ? ?called as list_to_float("-1e-23") >>> > > 5> list_to_float(".3"). >>> > > ** exception error: bad argument >>> > >? ? ? in function? list_to_float/1 >>> > >? ? ? ? ?called as list_to_float(".3") >>> > > >>> > >? ? An actual written specification would be really >>> handy here. Even >>> > > just a regex or EBNF for them. I'm writing a parser >>> for something >>> > > where the definition of floating point literals >>> isn't quite the same >>> > > as Erlang's, and it's a bit painful. >>> > > >>> > >? ? Hugo. >>> > > >>> >>> -- >>> Hugo Mills? ? ? ? ? ? ?| Nostalgia isn't what it used to be. >>> hugo@REDACTED carfax.org.uk | >>> http://carfax.org.uk/? | >>> PGP: E2AB1DE4? ? ? ? ? | >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.12 (GNU/Linux) >>> >>> iQIcBAEBAgAGBQJcjN62AAoJEFheFHXiqx3kiPAP/3V2SC+mFVSIjRw0moQC6keJ >>> x8A+005H7+SO030G5/a0TYXEe9wxn1KEtQEEyG2yt6A1XASeERRFuAPeeFMEhti+ >>> trr1oYJmbSTUgvRs1i5jhSH7KmUEt09I+JgS3u0Xs92LkmNyfFde8K3z6uA1XKwp >>> 7tIHihrXYpk/jMamWXTNGYPlHtxcVxAToNK8ajQTz6dElurZYdHwHtnFv7Ya7jcf >>> 7w9fKG4XcIoQZHMBrnZF8g2UQIgWiMpz7eo5lko91Zbjetgv1qkKaiNonA+rai4b >>> CVIXJ+YIT1dHNEQ76uVqJQuuklUB0M5B+FCX/zuS5Zd7mta9ljzBHefGLzQYT+EE >>> Y4En5n+YvL5OUCqw0EBBXBTYcsdn8rP0+jSy3nFiX6zV4Ty49NrKCSN0LGQJVpkz >>> wv1Sl05QBC2JcyCYqrCoMdudPNdcgK/TvB+H7KYcZDy3mgoZJ55U12Ys6Ng80tIa >>> 3eUis3W4vZLdS9Gfn8GY4A42APvv6X3W9bVN5JEISUlF3CdKui/RItZiQ8whx4iF >>> 6E+KzkO6AgmgyGKbAXK5N8S0MWuNT3g/V/tm7siY3GDG6cDIQNZRxevMXhAZ9nIv >>> S3kAiz1JBUKIMWv3RCz77+gKPI7AiUBHlfmXsjudSbnJ9r6nxhbCjbbypmHOzZYx >>> 5uMAhklJZ0OnQgmxOfVU >>> =0Eaq >>> -----END PGP SIGNATURE----- >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> -- >> >> Bryan Paxton >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Sun Mar 17 18:51:53 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 17 Mar 2019 13:51:53 -0400 Subject: [erlang-questions] =?utf-8?q?Process_migration=E2=80=94_Mickey-th?= =?utf-8?q?e-Dunce_dives_in_over_his_head?= Message-ID: <1E70646C-B4A7-49C6-8D50-80B54DB82131@writersglen.com> Process migration ? Mickey-the-Dunce dives in over his head In the spirit of dilettantish curiosity I looked into Linux containers. Wow, I thought? Linux computers, as many as I want that I can move around across hardware hosts as freely as I want, subject to availability of suitable host nodes. Naive, yes, I know. That intellectual sojourn led me to Kubernetes. Way cool! Now we can automate cluster management and optimize and resource allocation and ensure scalability and reliability, at least so far as I understand it. And more, all the cool kids are well on board, cheering. But then, I started wondering about Erlang processes? how do they compare and contrast with Linux containers? What might a Kubernetes-like system based on Erlang processes look like? Is such a beast even possible? My friend Google turned up these links: https://github.com/michalwski/proc_mobility https://dl.acm.org/citation.cfm?id=2505312&dl=ACM&coll=DL Sadly, behind a paywall http://erlang.org/pipermail/erlang-questions/2012-July/068317.html http://www.release-project.eu Along the way, I stumbled through many posts and papers dealing with the challenges of distributed computing. I understood the challenges part well enough, but the proposed solutions not so much. So my questions: Is any on-going work along these lines either academic or commercial? Is it a fruitful line to pursue? If so, are the technical challenges? All the best, LRP Sent from my iPad -------------- next part -------------- An HTML attachment was scrubbed... URL: From awsafrahman1704@REDACTED Sun Mar 17 19:52:01 2019 From: awsafrahman1704@REDACTED (Awsaf Rahman) Date: Sun, 17 Mar 2019 19:52:01 +0100 Subject: [erlang-questions] Beam compiler starts slow Message-ID: Hello, I wrote a few simple programs like the Fibonacci Sequence, matrix multiplication and executed each for a 1000 times and recorded the execution times required for each iteration in nanoseconds. What I found was that for the first 50 odd iterations, the execution times were much higher than the rest of the timings. The execution times at the starting was much higher but as the iterations went on, it came down to a stable runtime. Can anyone tell me why that is? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petergi@REDACTED Tue Mar 19 03:24:37 2019 From: petergi@REDACTED (Peter J Etheridge) Date: Tue, 19 Mar 2019 13:24:37 +1100 Subject: [erlang-questions] computers doing maths Message-ID: <046f827f4ed1737c342aa14a073bee8cfc8c8f4c@webmail.iinet.net.au> Dear Erlangers,If other novices enjoyed Bryan & RoK's recent discussion about decimals computed in binary machines as much as i did, you might find this 14:24 clip interesting; https://www.youtube.com/watch?v=pQs_wx8eoQ8&t=744s it might be poorly titled, but the content is well presented. happy coding,peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Tue Mar 19 05:12:57 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Tue, 19 Mar 2019 17:12:57 +1300 Subject: [erlang-questions] computers doing maths In-Reply-To: <046f827f4ed1737c342aa14a073bee8cfc8c8f4c@webmail.iinet.net.au> References: <046f827f4ed1737c342aa14a073bee8cfc8c8f4c@webmail.iinet.net.au> Message-ID: I wish people wouldn't say "computers are binary" as though this was true of all computers. IBM 650: sign + 10 decimal digits in biquinary IBM 1620: decimal arithmetic up to the size of store IBM 360 and up: decimal arithmetic up to 31 digits Burroughs Medium Systems (2500 to 4900): decimal arithmetic with up to 100 decimal digits, this included decimal floats with up to 100 mantissa digits. VAX: decimal string instructions Some kind of decimal support for COBOL was actually quite common. For that matter, ANSI Smalltalk includes ScaledDecimal. Sadly, the ANSI standard defers to the Language-Independent-Arithmetic standard for the semantics of ScaledDecimal, something about which LIA-1, LIA-2, and LIA-3 are by intention completely silent about, with the result that there are some truly bizarre implementations out there. Squeak is one of them: it's ScaledDecimal numbers do decimal *formatting* of rational numbers, which rather misses the point: 1/3 asScaledDecimal: 1 ==> 0.3s1 0.3s1 * s ==> 0.9s1 BUT (1/3 asScaledDecimal: 1) * 3 ==> 1.0s1 which is rather startling. And Pharo does the same. On Tue, 19 Mar 2019 at 15:24, Peter J Etheridge wrote: > Dear Erlangers, > If other novices enjoyed Bryan & RoK's recent discussion about decimals > computed in binary machines as much as i did, you might find this 14:24 > clip interesting; > > https://www.youtube.com/watch?v=pQs_wx8eoQ8&t=744s > > it might be poorly titled, but the content is well presented. > > happy coding, > peter > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve@REDACTED Tue Mar 19 11:56:44 2019 From: steve@REDACTED (Steve Strong) Date: Tue, 19 Mar 2019 10:56:44 +0000 Subject: [erlang-questions] Erlang 21 Logger Configuration Message-ID: <5B850A60-B4E9-4B32-9DDA-A8E7F7FC3CFA@srstrong.com> Hi All, Quick question regarding the handling of configuration changes for the disk_log hander in the new Logger framework, and specifically how it handles max_no_bytes. Given a clean directory, I can do the following: > erl Erlang/OTP 21 [erts-10.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe] Eshell V10.3 (abort with ^G) 1> logger:add_handler(disk_log, logger_disk_log_h, #{config => #{file => "log/debug.log", type => wrap, max_no_files => 10, max_no_bytes => 10000}, level => all}). ok 2>q(). That creates me a log folder with a debug.log.1, debug.log.idx and debug.log.siz. If I then start a new shell and try to create the handler but with a different max_no_bytes, I get the following: > erl Erlang/OTP 21 [erts-10.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe] Eshell V10.3 (abort with ^G) 1> logger:add_handler(disk_log, logger_disk_log_h, #{config => #{file => "log/debug.log", type => wrap, max_no_files => 10, max_no_bytes => 15000}, level => all}). {error,{handler_not_added,{size_mismatch,{10000,10}, {15000,10}}}} 2> q(). Due to the change in the max_no_bytes parameter, the handler fails to start. What is the recommended way to deal with adjusting config value such as this, particularly for handlers that may be added / removed dynamically? Right now, we are needing to archive the entire log directory prior to changing values, which is a real pain. Cheers, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott_ribe@REDACTED Tue Mar 19 12:56:40 2019 From: scott_ribe@REDACTED (Scott Ribe) Date: Tue, 19 Mar 2019 05:56:40 -0600 Subject: [erlang-questions] computers doing maths In-Reply-To: References: <046f827f4ed1737c342aa14a073bee8cfc8c8f4c@webmail.iinet.net.au> Message-ID: <5A44F5B5-1C82-4A4B-9ECB-F0261C3C6CD8@elevated-dev.com> Well, they're still binary at the foundation, even if they use some form of binary coded decimal. -- Scott Ribe scott_ribe@REDACTED https://www.linkedin.com/in/scottribe/ > On Mar 18, 2019, at 10:12 PM, Richard O'Keefe wrote: > > I wish people wouldn't say "computers are binary" > as though this was true of all computers. > IBM 650: sign + 10 decimal digits in biquinary > IBM 1620: decimal arithmetic up to the size of store > IBM 360 and up: decimal arithmetic up to 31 digits > Burroughs Medium Systems (2500 to 4900): decimal > arithmetic with up to 100 decimal digits, this > included decimal floats with up to 100 mantissa > digits. > VAX: decimal string instructions > Some kind of decimal support for COBOL was actually > quite common. > For that matter, ANSI Smalltalk includes > ScaledDecimal. Sadly, the ANSI standard > defers to the Language-Independent-Arithmetic > standard for the semantics of ScaledDecimal, > something about which LIA-1, LIA-2, and LIA-3 > are by intention completely silent about, with > the result that there are some truly bizarre > implementations out there. Squeak is one of > them: it's ScaledDecimal numbers do decimal > *formatting* of rational numbers, which rather > misses the point: > 1/3 asScaledDecimal: 1 ==> 0.3s1 > 0.3s1 * s ==> 0.9s1 > BUT > (1/3 asScaledDecimal: 1) * 3 ==> 1.0s1 > which is rather startling. And Pharo does the same. > > > On Tue, 19 Mar 2019 at 15:24, Peter J Etheridge wrote: > Dear Erlangers, > If other novices enjoyed Bryan & RoK's recent discussion about decimals computed in binary machines as much as i did, you might find this 14:24 clip interesting; > > https://www.youtube.com/watch?v=pQs_wx8eoQ8&t=744s > > it might be poorly titled, but the content is well presented. > > happy coding, > peter > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From borja.deregil@REDACTED Tue Mar 19 13:30:59 2019 From: borja.deregil@REDACTED (Borja de Regil) Date: Tue, 19 Mar 2019 13:30:59 +0100 Subject: [erlang-questions] Erlang TCP throughput slowdown Message-ID: Hi everyone, this is a long email, so apologies in advance. I?m currently benchmarking an Erlang service that consists of a set of client and servers, distributed among sites. Clients distribute their requests uniformly among all the servers, irrespective of the site they are in. The initial results, where all the clients and servers are located in the same site, showed a combined maximum throughput of ~620k requests per second, with a mean latency of ~7.4 ms. This is already past the saturation point of the service, but it illustrates the baseline performance. The mean round-trip latency between clients and servers here is of around 0.25 ms. However, as I distribute the same number of physical machines among sites, the throughput decreases (I?ve only tested this with two sites, but it seems to decrease linearly). In the same configuration, but with a 10ms rtt latency between the sites, the throughput decreases to ~350k requests per second, with a ~12ms mean latency (again, past the saturation point). Apart from the increase in latency between sites, no other configuration is changed. My initial expectation was that the throughput would stay the same, even if the base latency would increase, and that the saturation point would be reached at approximately the same number of requests per second. To rule out any application-specific configurations, I replicated the experiment with a simple TCP echo server (the results are almost the same). I?ve detailed the experiment below, in case someone wants to take a closer look. I?m by no means an expert at Erlang, or know very much about TCP, but I?m puzzled by how this could be, and I?ve already lost way too many hours trying to figure out where the performance is going. So any piece of advice would be extremely appreciated. Cheers, Borja Experiment details follow: # Technical setup All machines (Dell Poweredge R430, http://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell-PowerEdge-R430-Spec-Sheet.pdf) running Ubuntu 16.04.1 LTS and Erlang/OTP 19 [erts-8.3.5] [source] [64-bit] [smp:32:32], with: * Two 2.4 GHz 64-bit 8-Core Xeon E5-2630v3 processors, 8.0 GT/s, 20 MB cache * 64 GB 2133 MT/s DDR4 RAM (8 x 8GB modules) * 2-4 Intel i350 GbE NICs # Experiment setup Servers and clients are partitioned in sites. Inside a single site, all servers and client machines are linked to a single LAN. To connect between sites, a single physical machine is used as a switch between all the LANs on the different sites. Artificial latency is added on this switch node using `tc`. The servers don't know about each other, and only implement a simple TCP echo server using ranch as an acceptor pool. Each client node (using basho_bench) will create several worker processes to execute a simple ping-pong benchmark. At the beginning of the benchmark, a worker process will open TCP connections to each of the servers, and re-use them for requests throughout the entire benchmark. For each request, it will choose a server at random (in an uniform fashion), send a random payload of 1KB, and wait synchronously for the same payload to be sent back. Code is available on github for the server (https://github.com/ergl/ranch_test), the client (https://github.com/ergl/lasp-bench/blob/coord/src/ranch_test_bench.erl) and the benchmark settings (https://github.com/ergl/lasp-bench/blob/coord/examples/ranch_test.config). # Tuning Options Several socket options: * Ranch acceptor pool options `[{num_acceptors, erlang:system_info(schedulers_online)}, {max_connections, infinity}]` (The number of schedulers is 32, in this case). * Server socket options `[{active, once}, {packet, 2}]` * Client socket options `[binary, {active, false}, {packet, 2}, {nodelay, true}]` Erlang options on the server nodes (some of these options are chosen to replicate the original application): ``` +K true +A 5 -env ERL_MAX_PORTS 4096 -env ERL_FULLSWEEP_AFTER 10 -env ERL_MAX_ETS_TABLES 50000 +zdbbl 32768 +C no_time_warp +hmax 12500000 +hmaxk false +stbt tnnps ``` # The Problem For this experiment, we have two sites, with two server and two client machines each. We distinguish two scenarios: one with no latency added between sites (0.25 ms rtt), and another with an extra 10ms added (10ms rtt). Several 5-minute runs are performed, each with an increasing number of concurrent connections (from 50 up to 1000, so each server is holding 200 to 4000 concurrent connections). The results are in the following tables: Scenario A, no latency added | Clients | Total Clients | Max Throughput (reqs/sec) | Mean Latency (ms) | | 50 | 200 | 457,279.5 | 0.4397939 | | 100 | 400 | 514,436.5 | 0.7933541 | | 500 | 2,000 | 594,367.7 | 3.524144 | | 750 | 3,000 | 613,786.7 | 5.600492 | | 1,000 | 4,000 | 627,434.9 | 7.39232 | Scenario B, 10ms rtt | Clients | Total Clients | Max Throughput (reqs/sec) | Mean Latency (ms) | | 50 | 200 | 38,660.02 | 5.182687 | | 100 | 400 | 77,619.95 | 5.167778 | | 500 | 2,000 | 348,516.5 | 5.901048 | | 750 | 3,000 | 344,605.3 | 8.961493 | | 1,000 | 4,000 | 340,299.5 | 12.05045 | From erlangsiri@REDACTED Tue Mar 19 13:58:01 2019 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 19 Mar 2019 13:58:01 +0100 Subject: [erlang-questions] Erlang 21 Logger Configuration In-Reply-To: <5B850A60-B4E9-4B32-9DDA-A8E7F7FC3CFA@srstrong.com> References: <5B850A60-B4E9-4B32-9DDA-A8E7F7FC3CFA@srstrong.com> Message-ID: Hi Steve, I'm sorry to say that there is a bit left to do in the logger_disk_log_h handler. The error message you see actually comes from disk_log, and the handler is not implemented to take care of that. Also, for simplicity (due to lack of time) we decided to keep the max_no_bytes and max_no_files read-only in this handler, which means that you can not changes these options during run-time either :( It seems you are running OTP 21.3, so if it's an option for you, you may try the new rotation mechanism which is added to the logger_std_h handler in that release. It has a rotation scheme that does not rely on any .idx or .siz files. The log current log is always the one with the configured name, and the rotated archives have .0, .1, ... extensions. And with this handler you may change the max_no_files and max_no_bytes as you wish during run-time or when re-opening an existing log file. Kind Regards /siri Den tir. 19. mar. 2019 kl. 11:56 skrev Steve Strong : > Hi All, > > Quick question regarding the handling of configuration changes for the > disk_log hander in the new Logger framework, and specifically how it > handles max_no_bytes. > > Given a clean directory, I can do the following: > > > erl > Erlang/OTP 21 [erts-10.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] > [async-threads:1] [hipe] > > Eshell V10.3 (abort with ^G) > 1> logger:add_handler(disk_log, logger_disk_log_h, #{config => #{file => > "log/debug.log", type => wrap, max_no_files => 10, max_no_bytes => 10000}, > level => all}). > ok > 2>q(). > > That creates me a log folder with a debug.log.1, debug.log.idx and > debug.log.siz. If I then start a new shell and try to create the handler > but with a different max_no_bytes, I get the following: > > > erl > Erlang/OTP 21 [erts-10.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] > [async-threads:1] [hipe] > > Eshell V10.3 (abort with ^G) > 1> logger:add_handler(disk_log, logger_disk_log_h, #{config => #{file => > "log/debug.log", type => wrap, max_no_files => 10, max_no_bytes => 15000}, > level => all}). > {error,{handler_not_added,{size_mismatch,{10000,10}, > {15000,10}}}} > 2> q(). > > Due to the change in the max_no_bytes parameter, the handler fails to > start. What is the recommended way to deal with adjusting config value > such as this, particularly for handlers that may be added / removed > dynamically? Right now, we are needing to archive the entire log directory > prior to changing values, which is a real pain. > > > Cheers, > > Steve > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve@REDACTED Tue Mar 19 14:00:10 2019 From: steve@REDACTED (Steve Strong) Date: Tue, 19 Mar 2019 13:00:10 +0000 Subject: [erlang-questions] Erlang 21 Logger Configuration In-Reply-To: References: <5B850A60-B4E9-4B32-9DDA-A8E7F7FC3CFA@srstrong.com> Message-ID: Thanks Siri, 21.3 is an option so I?ll take a look as suggested. Cheers, Steve > On 19 Mar 2019, at 12:58, Siri Hansen wrote: > > Hi Steve, > > I'm sorry to say that there is a bit left to do in the logger_disk_log_h handler. The error message you see actually comes from disk_log, and the handler is not implemented to take care of that. Also, for simplicity (due to lack of time) we decided to keep the max_no_bytes and max_no_files read-only in this handler, which means that you can not changes these options during run-time either :( > > It seems you are running OTP 21.3, so if it's an option for you, you may try the new rotation mechanism which is added to the logger_std_h handler in that release. It has a rotation scheme that does not rely on any .idx or .siz files. The log current log is always the one with the configured name, and the rotated archives have .0, .1, ... extensions. And with this handler you may change the max_no_files and max_no_bytes as you wish during run-time or when re-opening an existing log file. > > Kind Regards > /siri > > Den tir. 19. mar. 2019 kl. 11:56 skrev Steve Strong >: > Hi All, > > Quick question regarding the handling of configuration changes for the disk_log hander in the new Logger framework, and specifically how it handles max_no_bytes. > > Given a clean directory, I can do the following: > > > erl > Erlang/OTP 21 [erts-10.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe] > > Eshell V10.3 (abort with ^G) > 1> logger:add_handler(disk_log, logger_disk_log_h, #{config => #{file => "log/debug.log", type => wrap, max_no_files => 10, max_no_bytes => 10000}, level => all}). > ok > 2>q(). > > That creates me a log folder with a debug.log.1, debug.log.idx and debug.log.siz. If I then start a new shell and try to create the handler but with a different max_no_bytes, I get the following: > > > erl > Erlang/OTP 21 [erts-10.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe] > > Eshell V10.3 (abort with ^G) > 1> logger:add_handler(disk_log, logger_disk_log_h, #{config => #{file => "log/debug.log", type => wrap, max_no_files => 10, max_no_bytes => 15000}, level => all}). > {error,{handler_not_added,{size_mismatch,{10000,10}, > {15000,10}}}} > 2> q(). > > Due to the change in the max_no_bytes parameter, the handler fails to start. What is the recommended way to deal with adjusting config value such as this, particularly for handlers that may be added / removed dynamically? Right now, we are needing to archive the entire log directory prior to changing values, which is a real pain. > > > Cheers, > > Steve > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Tue Mar 19 14:28:47 2019 From: otp@REDACTED (Erlang/OTP) Date: Tue, 19 Mar 2019 14:28:47 +0100 Subject: [erlang-questions] Patch Package OTP 21.3.1 Released Message-ID: <20190319132847.GA52077@erix.ericsson.se> Patch Package: OTP 21.3.1 Git Tag: OTP-21.3.1 Date: 2019-03-19 Trouble Report Id: OTP-14701, OTP-15676, OTP-15679 Seq num: ERL-861, ERL-881, ERL-883, ERL-884 System: OTP Release: 21 Application: erl_interface-3.11.1, ssl-9.2.1 Predecessor: OTP 21.3 Check out the git tag OTP-21.3.1, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- erl_interface-3.11.1 -------------------------------------------- --------------------------------------------------------------------- The erl_interface-3.11.1 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15676 Application(s): erl_interface Related Id(s): ERL-881, OTP-15442 Fixed two bugs in the erl_call program. A missing initialization (introduced in erl_interface-3.11) which either caused a crash or failure to connect to or start a node, and an incorrectly calculated timeout which could cause failure to start an erlang node. These bugs only caused failures on some platforms. --------------------------------------------------------------------- --- ssl-9.2.1 ------------------------------------------------------- --------------------------------------------------------------------- The ssl-9.2.1 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-14701 Application(s): ssl Related Id(s): ERL-883, ERL-884 The timeout for a passive receive was sometimes not cancelled and later caused a server crash. This bug has now been corrected. OTP-15679 Application(s): ssl Related Id(s): ERL-861 Add tag for passive message (active N) in cb_info to retain transport transparency. Full runtime dependencies of ssl-9.2.1: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From jesper.louis.andersen@REDACTED Tue Mar 19 16:04:51 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 19 Mar 2019 16:04:51 +0100 Subject: [erlang-questions] Erlang TCP throughput slowdown In-Reply-To: References: Message-ID: On Tue, Mar 19, 2019 at 1:35 PM Borja de Regil wrote: > > Apart from the increase in latency between sites, no other configuration > is changed. My initial expectation was that the throughput would stay the > same, even if the base latency would increase, and that the saturation > point would be reached at approximately the same number of requests per > second. > > In your scenarios, this assumption needs amendment. Your client code sends a single message and then waits for a reply, so at most one message is on the line at a given time, and you have implemented a stop and go protocol on top of TCP. In such a protocol, an increase in network delay/latency incurs a loss of bandwidth. Your A and B experiments uses an RTT of 0.25ms and 10ms respectively. This is a 40 times increase in latency, and it will affect the bandwidth between the peers. In this case it puts an artificial limit on how much data you can transfer. You keep your messages at 1 kilobyte, so the req/s is essentially a bandwidth measurement of bytes/sec. The problem is the same as when you are doing e.g., satellite communications: geosynchronous orbit is around 550ms away in practice. It is also linked to the so-called bandwidth*delay product (BDP). Some napkin math: Suppose you have 1 connection. You have a lower RTT of 10ms. At most, this is 100 req/s on that connection. Suppose we have 500 of those connections. Then the maximal req/s is 500*100 = 50,000. A way I often approach these questions is by creating an extreme scenario: I have 1 connection and 3 seconds of latency. What happens? The goal is to identify the shadow constraints of the system so you can understand to where the bottleneck moves once the apparent first bottleneck is found and eliminated. The other problem is that your load generator coordinates which leads to coordinated omission[0]. The load generator only issues the next request once the previous one completes. It is usually better to keep the bandwidth usage contant and then measure latency, counting a late request against the system. The astute reader will also observe you measure the mean latency. This is not very useful, and you should look at either a boxplot, kernel density plot, histogram. or the like. If you know the data is normally distributed with the same standard deviation, then your average latency makes sense as a comparable value. But this requires you plot the data, look at it and make sure they have that shape. Otherwise you can be led astray. As an example suppose I have 2 fair dice. One die has faces 1,2,3,4,5,6. The other has faces 1,1,1,6,6,6. These two dice have the same mean (3.5), but you would not argue they are the same in distribution. In fact, the latter die has no observation close to 3.5 ever! Now to solutions: The problem has to do with physics, more-so than Erlang. Information travels as a wave in a medium such as copper wire or fiber. This speed has an upper limit, which is the speed of light as information cannot travel faster than that. In practice, fiber is roughly 2/3 of light speed, and you can assume that relatively constant. You need to employ latency hiding tricks to circumvent this limit. Batching is an option. Collect multiple requests and send them all off at the same time.This effectively makes sure you can have multiple requests inflight, which gets you around the delay constant. It also allows a smart server to process multiple requests simultaneously, thus shedding load. Microbatching is alluring here: when the first request arrives, set a cork for 5ms. Upon having read either 500 reqs or the timer triggering, process whatever you have in the batch. Then start all over. This is used by e.g., Kafka and TensorFlow, the latter to avoid the memory bottleneck between DRAM and GPU. Pipelining is another option. Send multiple requests back to back, so they are all in the network. Interlace your receive loop with new requests being sent, so you can keep the work going. You should consider tagging messages with unique identifiers so they can be told apart. This allows out-of-order processing. See plan9's 9p protocol, RabbitMQ/AMQP's correlation IDs, or HTTP/2. Quick implementation: Loic Hoguin's Cowboy/Gun combo works wonders here, and uses the same code base (cowlib). This will avoid the wait time effectively. [0] See e.g., Gil Tene's work on this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Wed Mar 20 09:22:17 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Wed, 20 Mar 2019 09:22:17 +0100 Subject: [erlang-questions] Port drivers vs nifs Message-ID: Hi, How does Nifs compare to Port drivers in OTP 21 and beyond..? It used to be that port drivers were more suited for threaded c libraries etc, but it seems to me now you can do anything with with either. Will port drivers be deprecated? Which should I choose when starting a new hardware driver (assuming I have ruled out ports and c nodes, I'm aware of the implications)? --Albin -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Wed Mar 20 09:32:49 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Wed, 20 Mar 2019 09:32:49 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: I looked at GnuTLS and they have the option to use a pull and a push callback function when the SSL stack wants data and wants to send data respectively. I think it's a nice idea because it decouples the SSL stack completely from the underlying socket. It seems this is sometimes desirable.. --Albin On Sat, Mar 16, 2019, 11:53 Albin Stig? wrote: > True... A callback receiving {udp, Socket, IP, InPortNo, Packet} and > deciding whether to use the the ssl demuxer or pass it on to another > process might be enough. The STUN packets could come from any IP > unsolicited when doing ICE nat traversal path discovery (as described by > WebRTC). > > > --Albin > > On Sat, Mar 16, 2019, 11:00 Ingela Andin wrote: > >> >> Hi! >> >> Den l?r 16 mars 2019 kl 10:21 skrev Albin Stig? : >> >>> Ok sorry about the confusion. What's needed is a second level of >>> demultiplexing after the first... But I realize now this will be very >>> difficult to achieve with the current implementation because that relies on >>> one socket per connection. Otherwise you won't know which process to send >>> the none DTLS packets to... Or am i missing something? >>> >>> >> You will have to extend the demultiplexor process so that it sends >> packets to different processes depending on some criteria. It is ok to >> change the internals of >> the process if that is necessary. But we like the basic functionality to >> be the framework of the process and then add extended features mainly >> through callbacks. >> >> Regards Ingela Erlang/OTP Team - Ericsson AB >> >> >>> I might have to attempt a separate DTLS use_srtp app just for this >>> application... >>> >>> >>> --Albin >>> >>> On Sat, Mar 16, 2019, 09:05 Ingela Andin wrote: >>> >>>> Hi Albin! >>>> >>>> Den fre 15 mars 2019 kl 17:25 skrev Albin Stig? >>> >: >>>> >>>>> Ok thanks! >>>>> >>>>> Maybe demultiplexing should just be default when the use_srtp >>>>> extension is used, since that's how it's supposed to be used anyway... or a >>>>> rfc7983_demux option... >>>>> >>>>> >>>> ? A DTLS server will always have a demultiplexing process as UDP does >>>> not have a connection concept. >>>> >>>> >>>> >>>>> What's the name in the #state that holds the pid of the controlling >>>>> process (the process that receives {ssl.. data)? >>>>> >>>>> >>>> It is part of the "user" in the state of the TLS/DTLS connection >>>> process. You should not have to care. You set the controlling process with >>>> ssl:controlling_process/2. >>>> >>>> I guess what you care about is the demultiplexing process and which Pid >>>> it sends the incoming UDP packets to. All the code is defined in the >>>> dtls_packet_demux.erl >>>> >>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>> >>>> >>>>> --Albin >>>>> >>>>> On Fri, Mar 15, 2019, 17:01 Ingela Andin >>>>> wrote: >>>>> >>>>>> Hi Albin! >>>>>> >>>>>> There is the handshake_compleation option together with the >>>>>> handshake_continue functions that let you pause the handshake and retrieve >>>>>> the hello extensions and possibly provide more options before >>>>>> continuing the handshake. >>>>>> >>>>>> Den fre 15 mars 2019 kl 13:20 skrev Albin Stig? < >>>>>> albin.stigo@REDACTED>: >>>>>> >>>>>>> Am I right to assume this is the single point of udp receive for >>>>>>> dtls? >>>>>>> >>>>>>> >>>>>>> https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906 >>>>>>> >>>>>>> >>>>>>> >>>>>> If you want to multiplex UDP packets to other processes than the DTLS >>>>>> connection process that is not encrypted under DTLS you >>>>>> should not look at the DTLS connection process but at the >>>>>> >>>>>> >>>>>> https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140 >>>>>> >>>>>> Regards Ingela Erlang/OTP team Ericsson AB >>>>>> >>>>>> >>>>>>> --Albin >>>>>>> >>>>>>> On Fri, Mar 15, 2019 at 1:10 PM Albin Stig? >>>>>>> wrote: >>>>>>> > >>>>>>> > There're all kinds of abuse of DTLS it seems :-) >>>>>>> > >>>>>>> > I still think the use cases are orthogonal though... Demuxing as >>>>>>> > described in https://tools.ietf.org/html/rfc7983 is trivial and >>>>>>> > requires no state. A demux_fun would solve that problem. >>>>>>> > >>>>>>> > DTLS packets wrapped in extra headers with the need of state >>>>>>> > information is much more complicated... Maybe what is needed are >>>>>>> two >>>>>>> > different approaches? Especially since you will need forward and >>>>>>> > backwards transform..? >>>>>>> > >>>>>>> > Ingela, is there already an API for getting the key data from >>>>>>> use_srtp >>>>>>> > (when implemented) or will that have to be added also? >>>>>>> > >>>>>>> > >>>>>>> > --Albin >>>>>>> > >>>>>>> > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz >>>>>>> > wrote: >>>>>>> > > >>>>>>> > > Albin Stig? schrieb am Do., 14. M?rz >>>>>>> 2019 um 18:49 Uhr: >>>>>>> > >> >>>>>>> > >> Hi Ingela and Andreas, >>>>>>> > >> >>>>>>> > >> > No, that's not enough. Some protocols put additional headers >>>>>>> in front of the DTLS packets. So there needs to be a way to strip >>>>>>> > >> > headers on Rx and add it on Tx (with session information if >>>>>>> needed). >>>>>>> > >> >>>>>>> > >> I have to admit I have not encountered this practice... do you >>>>>>> have a >>>>>>> > >> particular protocol in mind or is it a part of dtls-srtp I have >>>>>>> > >> missed? One could argue that if you add additional headers and >>>>>>> > >> maintain some kind of state you are actually dealing with a >>>>>>> different >>>>>>> > >> transport layer...? >>>>>>> > > >>>>>>> > > >>>>>>> > > CAPWAP is doing that >>>>>>> https://tools.ietf.org/html/rfc5415#section-4.1 >>>>>>> > > >>>>>>> > >> I would very much like a way where filtered out packages were >>>>>>> sent to >>>>>>> > >> the controlling process as {udp,Socket instead of {ssl, >>>>>>> Socket... The >>>>>>> > >> question in the latter case is if Socket should be the ssl >>>>>>> socket or >>>>>>> > >> the transport socket. Messing with the transport socket could be >>>>>>> > >> detrimental to dtls. >>>>>>> > >> >>>>>>> > >> One could also extend the filter_fun idea to a transform_fun >>>>>>> where one >>>>>>> > >> could transform in packet in addition to demultiplexing, but >>>>>>> like I >>>>>>> > >> said, I think additional headers to dtls packets belong to the >>>>>>> > >> transport layer. >>>>>>> > > >>>>>>> > > >>>>>>> > > Passing a State in and out of such a transform would be good. >>>>>>> > > >>>>>>> > > Andreas >>>>>>> > > >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> I don't have in-depth knowledge of the ssl app but it seems >>>>>>> adding a >>>>>>> > >> filter_fun would be almost trivial? >>>>>>> > >> >>>>>>> > >> > Maybe transport_send as compared to the existing >>>>>>> transport_accept. Would only work for DTLS. >>>>>>> > >> >>>>>>> > >> Well either that or some way of accessing the transport socket, >>>>>>> but >>>>>>> > >> transport_send for sure plays well with existing API! >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> --Albin >>>>>>> > >> >>>>>>> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin < >>>>>>> ingela.andin@REDACTED> wrote: >>>>>>> > >> > >>>>>>> > >> > Hi! >>>>>>> > >> > >>>>>>> > >> > Andreas, see comment below. >>>>>>> > >> > >>>>>>> > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < >>>>>>> andreas.schultz@REDACTED>: >>>>>>> > >> >> >>>>>>> > >> >> Hi >>>>>>> > >> >> >>>>>>> > >> >> Ingela Andin schrieb am Do., 14. >>>>>>> M?rz 2019 um 17:34 Uhr: >>>>>>> > >> >>> >>>>>>> > >> >>> Hi Albin! >>>>>>> > >> >>> >>>>>>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? < >>>>>>> albin.stigo@REDACTED>: >>>>>>> > >> >>>> >>>>>>> > >> >>>> Hi Ingela, >>>>>>> > >> >>>> >>>>>>> > >> >>>> Thanks for the quick reply! >>>>>>> > >> >>>> >>>>>>> > >> >>>> While cb_info certainly is one way of doing it, it feels a >>>>>>> bit >>>>>>> > >> >>>> complicated... specifically if switching between active >>>>>>> and passive >>>>>>> > >> >>>> mode. Not sure if ssl ever use passive mode internally? >>>>>>> Demuxing is a >>>>>>> > >> >>>> different use case, I think.. >>>>>>> > >> >>>> >>>>>>> > >> >>> >>>>>>> > >> >>> The cb_info is intended so that you may replace the >>>>>>> transport layer, with most likely, an SCTP transport (can be done for both >>>>>>> TLS and DTLS although there are some extensions needed for the DLTS version >>>>>>> to work properly). I think some people also use it to implement WebSockets. >>>>>>> > >> >>> >>>>>>> > >> >>> ssl internally uses active n for TLS (since latest release) >>>>>>> and active once for DTLS (we might change it) but an OTP supervised process >>>>>>> will not use passive recv as we do not want it to block. >>>>>>> > >> >>> >>>>>>> > >> >>> >>>>>>> > >> >>>> >>>>>>> > >> >>>> Something that IMHO would be fantastic and simple (?) >>>>>>> would be a >>>>>>> > >> >>>> dtls_filter_fun option. If true packet is passed up the >>>>>>> ssl stack, >>>>>>> > >> >>>> otherwise passed on like a normal udp packet! >>>>>>> > >> >>>> >>>>>>> > >> >>> >>>>>>> > >> >>> Sounds reasonable. Otherwise sent to some other Erlang >>>>>>> process than the "DTLS-connection" process that is. >>>>>>> > >> >> >>>>>>> > >> >> >>>>>>> > >> >> No, that's not enough. Some protocols put additional headers >>>>>>> in front of the DTLS packets. So there needs to be a way to strip headers >>>>>>> on Rx and add it on Tx (with session information if needed). >>>>>>> > >> >> >>>>>>> > >> > >>>>>>> > >> > Maybe the demultiplexor process can have a "packet mode" that >>>>>>> is set to "no packet" default and needs a callback handler for anything >>>>>>> else? >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>> > >> > >>>>>>> > >> >> >>>>>>> > >> >> Andreas >>>>>>> > >> >> >>>>>>> > >> >>> >>>>>>> > >> >>> >>>>>>> > >> >>>> >>>>>>> > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, >>>>>>> it basically >>>>>>> > >> >>>> boils down to looking at the first byte of the packet, if >>>>>>> it's >>>>>>> > >> >>>> [20..63] it should be treated as DTLS otherwise something >>>>>>> else. So >>>>>>> > >> >>>> this would be absolutely trivial to implement if there was >>>>>>> a >>>>>>> > >> >>>> dtls_filter_fun... >>>>>>> > >> >>>> >>>>>>> > >> >>>> https://tools.ietf.org/html/rfc7983 >>>>>>> > >> >>>> >>>>>>> > >> >>>> Then of course there also has to be a way to bypass DTLS >>>>>>> when sending >>>>>>> > >> >>>> data... maybe send/3 (Socket, Data, Options)... >>>>>>> > >> >>>> >>>>>>> > >> >>> >>>>>>> > >> >>> Maybe transport_send as compared to the existing >>>>>>> transport_accept. Would only work for DTLS. >>>>>>> > >> >>> >>>>>>> > >> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>> > >> >>> >>>>>>> > >> >>>> >>>>>>> > >> >>>> What do you think? >>>>>>> > >> >>>> >>>>>>> > >> >>>> >>>>>>> > >> >>>> --Albin >>>>>>> > >> >>>> >>>>>>> > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin < >>>>>>> ingela.andin@REDACTED> wrote: >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > Hi! >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < >>>>>>> albin.stigo@REDACTED>: >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> Hi, >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send >>>>>>> audio/video to >>>>>>> > >> >>>> >> the browser). >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> 1. The use_srtp extension for key exchange. >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > We will be implementing this as part of TLS-1.3 that we >>>>>>> are currently working on, and we will have something runnable for OTP-22.0, >>>>>>> although we are not promising that it will complete or that use_srtp will >>>>>>> be part of OTP-22.0 >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the socket. >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> I know there's been work towards use_srtp and it's even >>>>>>> in the source, >>>>>>> > >> >>>> >> but commented out. Ingela has been working on it for >>>>>>> OTP 2, I believe, >>>>>>> > >> >>>> >> is there an ETA on this feature? >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> Is multiplexing on the DTLS socket already possible >>>>>>> using the cb_info? >>>>>>> > >> >>>> >> Has anyone tried that? >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> >>>>>>> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > The code has been written to make such extensions >>>>>>> possible. There might be a need for more callbacks. I have not really had >>>>>>> time to work on that as >>>>>>> > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS >>>>>>> has been prioritized higher. Suggestions are welcome. >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > >>>>>>> > >> >>>> > >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> >>>>>>> > >> >>>> >> --Albin >>>>>>> > >> >>>> >> _______________________________________________ >>>>>>> > >> >>>> >> erlang-questions mailing list >>>>>>> > >> >>>> >> erlang-questions@REDACTED >>>>>>> > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>> > >> >>> >>>>>>> > >> >>> _______________________________________________ >>>>>>> > >> >>> erlang-questions mailing list >>>>>>> > >> >>> erlang-questions@REDACTED >>>>>>> > >> >>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>> > >> >> >>>>>>> > >> >> -- >>>>>>> > >> >> -- >>>>>>> > >> >> Dipl.-Inform. Andreas Schultz >>>>>>> > >> >> >>>>>>> > >> >> ----------------------- enabling your networks >>>>>>> ---------------------- >>>>>>> > >> >> Travelping GmbH Phone: +49-391-81 90 99 >>>>>>> 0 >>>>>>> > >> >> Roentgenstr. 13 Fax: +49-391-81 90 99 >>>>>>> 299 >>>>>>> > >> >> 39108 Magdeburg Email: >>>>>>> info@REDACTED >>>>>>> > >> >> GERMANY Web: >>>>>>> http://www.travelping.com >>>>>>> > >> >> >>>>>>> > >> >> Company Registration: Amtsgericht Stendal Reg No.: >>>>>>> HRB 10578 >>>>>>> > >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>>>>> DE236673780 >>>>>>> > >> >> >>>>>>> --------------------------------------------------------------------- >>>>>>> > > >>>>>>> > > -- >>>>>>> > > -- >>>>>>> > > Dipl.-Inform. Andreas Schultz >>>>>>> > > >>>>>>> > > ----------------------- enabling your networks >>>>>>> ---------------------- >>>>>>> > > Travelping GmbH Phone: +49-391-81 90 99 0 >>>>>>> > > Roentgenstr. 13 Fax: +49-391-81 90 99 299 >>>>>>> > > 39108 Magdeburg Email: info@REDACTED >>>>>>> > > GERMANY Web: >>>>>>> http://www.travelping.com >>>>>>> > > >>>>>>> > > Company Registration: Amtsgericht Stendal Reg No.: HRB >>>>>>> 10578 >>>>>>> > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>>>>> DE236673780 >>>>>>> > > >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Wed Mar 20 10:51:49 2019 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 20 Mar 2019 10:51:49 +0100 Subject: [erlang-questions] Port drivers vs nifs In-Reply-To: References: Message-ID: On Wed, Mar 20, 2019 at 9:22 AM Albin Stig? wrote: > Hi, > > How does Nifs compare to Port drivers in OTP 21 and beyond..? It used to > be that port drivers were more suited for threaded c libraries etc, but it > seems to me now you can do anything with with either. > > Will port drivers be deprecated? > No. > > Which should I choose when starting a new hardware driver (assuming I have > ruled out ports and c nodes, I'm aware of the implications)? > I would do it in a NIF. NIFs have a larger API, work on dirty schedulers and are in most cases more performant than port drivers. > > > --Albin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Wed Mar 20 11:30:49 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Wed, 20 Mar 2019 11:30:49 +0100 Subject: [erlang-questions] Port drivers vs nifs In-Reply-To: References: Message-ID: Thanks! The documentation should maybe be updated to reflect this... or maybe I just missed it. On Wed, Mar 20, 2019, 10:52 Lukas Larsson wrote: > > > On Wed, Mar 20, 2019 at 9:22 AM Albin Stig? wrote: > >> Hi, >> >> How does Nifs compare to Port drivers in OTP 21 and beyond..? It used to >> be that port drivers were more suited for threaded c libraries etc, but it >> seems to me now you can do anything with with either. >> >> Will port drivers be deprecated? >> > > No. > > >> >> Which should I choose when starting a new hardware driver (assuming I >> have ruled out ports and c nodes, I'm aware of the implications)? >> > > I would do it in a NIF. NIFs have a larger API, work on dirty schedulers > and are in most cases more performant than port drivers. > > >> >> >> --Albin >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silviu.cpp@REDACTED Wed Mar 20 22:12:08 2019 From: silviu.cpp@REDACTED (Caragea Silviu) Date: Wed, 20 Mar 2019 23:12:08 +0200 Subject: [erlang-questions] VM crash on OTP 21.1 Message-ID: Hello, After upgrading to OTP 21.1 from 19.3 I got a VM crash in production which seems similar with https://bugs.erlang.org/browse/ERL-486 #0 0x000000000051547f in ethr_native_atomic64_add_return_mb (incr=-1, var=0x11) at ../include/internal/x86_64/../i386/atomic.h:240 #1 ethr_atomic_add_read (val=-1, var=0x11) at ../include/internal/ethr_atomics.h:4219 #2 ethr_atomic_dec_read (var=0x11) at ../include/internal/ethr_atomics.h:4806 #3 erts_refc_dectest (min_val=0, refcp=0x11) at beam/sys.h:962 #4 erts_deref_node_entry (np=0x1) at beam/erl_node_tables.h:234 #5 erts_cleanup_offheap (offheap=offheap@REDACTED=0x7f527153fdc0) at beam/erl_message.c:184 #6 0x00000000005157b5 in erts_cleanup_messages (msgp=) at beam/erl_message.c:227 #7 0x000000000046f5a5 in delete_process (p=0x7f527141d768) at beam/erl_process.c:11843 #8 erts_continue_exit_process (p=0x7f527141d768) at beam/erl_process.c:12487 #9 erts_do_exit_process () at beam/erl_process.c:12210 #10 0x00000000004681da in terminate_proc (Value=523, c_p=0x7f527141d768) at beam/beam_emu.c:1613 #11 handle_error (c_p=0x7f527141d768, pc=, reg=, bif_mfa=) at beam/beam_emu.c:1467 #12 0x000000000046424b in process_main () at x86_64-unknown-linux-gnu/opt/smp/beam_hot.h:349 #13 0x000000000044ef0b in sched_thread_func (vesdp=0x7f54446ac500) at beam/erl_process.c:8332 #14 0x00000000006880e9 in thr_wrapper (vtwd=0x7ffe80d6b8d0) at pthread/ethread.c:118 #15 0x00007f548c0b06ba in start_thread (arg=0x7f5440c39700) at pthread_create.c:333 #16 0x00007f548bbde41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Anyone any idea from where can come ? Silviu -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve@REDACTED Thu Mar 21 16:36:00 2019 From: steve@REDACTED (Steve Strong) Date: Thu, 21 Mar 2019 15:36:00 +0000 Subject: [erlang-questions] UNC filename handling Message-ID: <835BC11C-811B-4A06-9C9B-8DC3602D0CDA@srstrong.com> Hi, Seeing a strange thing on Windows systems: (foo@REDACTED)55> file:list_dir("z:/Signal-53-mp4/frame_store"). {ok,["100","2124","2142","2161"]} (foo@REDACTED)56> file:list_dir("//HB-SVR/Video/Signal-53-mp4/frame_store"). {ok,["frame_store"]} Z: is mapped to //HB-SVR/Video, so I would have expected these two commands to produce the same result, but the one going through the UNC form is giving the wrong answer (the contents of the frame_store folder are ?100?, ?2121?, ?2142" and ?2161? as the call through the mapped drive correctly returned). This issue, in turn, causes other commands such as filelib:wildcard to return the incorrect results when handed UNC paths. This is running Erlang 21.2 / erts 10.2 Is this a known issue, or am I misunderstanding how the UNC paths should behave? Cheers, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Thu Mar 21 17:50:01 2019 From: john@REDACTED (John =?ISO-8859-1?Q?H=F6gberg?=) Date: Thu, 21 Mar 2019 17:50:01 +0100 Subject: [erlang-questions] UNC filename handling In-Reply-To: <835BC11C-811B-4A06-9C9B-8DC3602D0CDA@srstrong.com> References: <835BC11C-811B-4A06-9C9B-8DC3602D0CDA@srstrong.com> Message-ID: <7d94e770c8c3d61f792f875d68e4ad42bde26e88.camel@erlang.org> Hi Steve, Thanks for reporting this, I can confirm that it's a bug in our UNC path handling. I've included a fix in our nightly builds, and it'll be released in OTP 22-rc2 if all goes well. Regards,John H?gberg On Thu, 2019-03-21 at 15:36 +0000, Steve Strong wrote: > Hi, > Seeing a strange thing on Windows systems: > > (foo@REDACTED)55> file:list_dir("z:/Signal-53-mp4/frame_store"). > > {ok,["100","2124","2142","2161"]} > > > (foo@REDACTED)56> file:list_dir("//HB-SVR/Video/Signal-53- > mp4/frame_store"). > {ok,["frame_store"]} > > > Z: is mapped to //HB-SVR/Video, so I would have expected these two > commands to produce the same result, but the one going through the > UNC form is giving the wrong answer (the contents of the frame_store > folder are ?100?, ?2121?, ?2142" and ?2161? as the call through the > mapped drive correctly returned). This issue, in turn, causes other > commands such as filelib:wildcard to return the incorrect results > when handed UNC paths. > > This is running Erlang 21.2 / erts 10.2 > > Is this a known issue, or am I misunderstanding how the UNC paths > should behave? > > Cheers, > > Steve > _______________________________________________erlang-questions > mailing listerlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Thu Mar 21 21:28:03 2019 From: otp@REDACTED (Erlang/OTP) Date: Thu, 21 Mar 2019 21:28:03 +0100 Subject: [erlang-questions] Patch Package OTP 21.3.2 Released Message-ID: <20190321202803.GA9513@erix.ericsson.se> Patch Package: OTP 21.3.2 Git Tag: OTP-21.3.2 Date: 2019-03-21 Trouble Report Id: OTP-15684, OTP-15685, OTP-15688, OTP-15690 Seq num: ERL-475, ERL-837 System: OTP Release: 21 Application: erts-10.3.1, xmerl-1.3.20 Predecessor: OTP 21.3.1 Check out the git tag OTP-21.3.2, and build a full OTP system including documentation. Apply one or more applications from this build as patches to your installation using the 'otp_patch_apply' tool. For information on install requirements, see descriptions for each application version below. --------------------------------------------------------------------- --- erts-10.3.1 ----------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.3.1 application can *not* be applied independently of other applications on an arbitrary OTP 21 installation. On a full OTP 21 installation, also the following runtime dependencies have to be satisfied: -- kernel-6.1 (first satisfied in OTP 21.1) -- sasl-3.3 (first satisfied in OTP 21.2) --- Fixed Bugs and Malfunctions --- OTP-15688 Application(s): erts If a suspend/resume signal pair was sent to a process while it was executing dirty, the receiving process could later end up in a suspended state indefinitely. This bug was introduced in ERTS version 10.0 (OTP 21.0). Suspend/resume signals are sent from erlang:suspend_process()/erlang:resume_process(). The dbg trace tool utilize this functionality and could thus trigger this bug. OTP-15690 Application(s): erts Related Id(s): PR-2172 Fix a possible deadlock when terminating the ERTS caused by a dirty scheduler not releasing it's run-queue lock when terminating. Full runtime dependencies of erts-10.3.1: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- xmerl-1.3.20 ---------------------------------------------------- --------------------------------------------------------------------- The xmerl-1.3.20 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15684 Application(s): xmerl Related Id(s): ERL-837 Handling of character references in attributes are fixed. OTP-15685 Application(s): xmerl Related Id(s): ERL-475 Normalization of whitespace characters in attributes are fixed so it works when character references are used. Full runtime dependencies of xmerl-1.3.20: erts-6.0, kernel-3.0, stdlib-2.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From frank.muller.erl@REDACTED Fri Mar 22 00:40:07 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Fri, 22 Mar 2019 00:40:07 +0100 Subject: [erlang-questions] Erlang 21.3: erl_call crashing In-Reply-To: References: Message-ID: Hi Rickard Trying with 21.3.2 (Ubuntu 18.04.1 LTS, 64GB RAM, 12-Core Xeon): # echo "erlang:memory(). | /opt/txn/erts-10.3.1/bin/erl_call -name txn_app@REDACTED -c my_cookie -e 2>/dev/null [ hangs for a minutes then returns nothing ] # echo $? 1 Any idea? /Frank Hi Rickard > > Works perfectly. Thanks for the quick fix. > > /Frank > > On Fri, Mar 15, 2019 at 6:35 AM Frank Muller >> wrote: >> > >> > Hi guys >> > >> > We switched to 21.3 to generate our release and noticed that we can?t >> use erl_call shipped with 21.3 anymore. It always crashes with SIGSEGV. >> > >> > Simply overwriting the erl_call binary with the one from 21.2.4 fixed >> the problem even in release generated with 21.3. >> > >> > Any idea? Did the Erlang team change erl_call in 21.3? >> > >> > /Frank >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> Please try fix in pull request 2183 < >> https://github.com/erlang/otp/pull/2183>. >> >> Regards, >> Rickard >> -- >> Rickard Green, Erlang/OTP, Ericsson AB >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Fri Mar 22 01:20:05 2019 From: rickard@REDACTED (Rickard Green) Date: Fri, 22 Mar 2019 01:20:05 +0100 Subject: [erlang-questions] Erlang 21.3: erl_call crashing In-Reply-To: References: Message-ID: On 2019-03-22 00:40, Frank Muller wrote: > Hi Rickard > > Trying with 21.3.2 (Ubuntu 18.04.1 LTS, 64GB RAM, 12-Core Xeon): > > # echo "erlang:memory(). | /opt/txn/erts-10.3.1/bin/erl_call -name > txn_app@REDACTED -c my_cookie -e 2>/dev/null > > [ hangs for a minutes then returns nothing ] > > # echo $? > 1 > > Any idea? > > /Frank > No and I'm not able to reproduce it either. If you are able to reproduce it. Please file an issue at https://bugs.erlang.org and provide some more info. For example, output when setting EI_TRACELEVEL=5. Regards, Rickard From frank.muller.erl@REDACTED Fri Mar 22 05:07:32 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Fri, 22 Mar 2019 05:07:32 +0100 Subject: [erlang-questions] Erlang 21.3: erl_call crashing In-Reply-To: References: Message-ID: Thanks for the tip. Rebooting the machine fixed the DNS issue. /Frank On 2019-03-22 00:40, Frank Muller wrote: > > Hi Rickard > > > > Trying with 21.3.2 (Ubuntu 18.04.1 LTS, 64GB RAM, 12-Core Xeon): > > > > # echo "erlang:memory(). | /opt/txn/erts-10.3.1/bin/erl_call -name > > txn_app@REDACTED -c my_cookie -e 2>/dev/null > > > > [ hangs for a minutes then returns nothing ] > > > > # echo $? > > 1 > > > > Any idea? > > > > /Frank > > > > No and I'm not able to reproduce it either. > > If you are able to reproduce it. Please file an issue at > https://bugs.erlang.org and provide some more info. For example, output > when setting EI_TRACELEVEL=5. > > Regards, > Rickard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From borja.deregil@REDACTED Fri Mar 22 01:42:55 2019 From: borja.deregil@REDACTED (Borja de Regil) Date: Fri, 22 Mar 2019 01:42:55 +0100 Subject: [erlang-questions] Erlang TCP throughput slowdown In-Reply-To: References: Message-ID: Thanks for the great reply, Jesper! Please see some updated comments below > On 19 Mar 2019, at 16:04, Jesper Louis Andersen wrote: > > Some napkin math: Suppose you have 1 connection. You have a lower RTT of 10ms. At most, this is 100 req/s on that connection. Suppose we have 500 of those connections. Then the maximal req/s is 500*100 = 50,000. Right, I had the intuition that with a larger latency, I?d need more clients to reach the same throughput. In the numbers I shared in the previous email, you can see that I?ve almost reached the maximum number of req/s with 4,000 connections (with your calculations, it should be 400,000 req/s, and I get 340,000). In this benchmark, the clients can either route requests to a node on another site (10ms RTT), or stay within a site (0.2 ms RTT), so the upper bound will be larger, depending on the distribution. But the thing is, 4,000 concurrent connections don?t sound like a lot (especially so if they?re not doing a lot), so I?m surprised that even at 340k req/s, I?m hitting a mean latency of 12ms (and with a 99th percentile of 230ms, to boot). Why is it so overloaded? I would expect a beefy machine to cope with that load (the actual saturation point seems to be reached at 2000 concurrent connections, as the throughput drops after that). > The other problem is that your load generator coordinates which leads to coordinated omission[0]. The load generator only issues the next request once the previous one completes. It is usually better to keep the bandwidth usage constant and then measure latency, counting a late request against the system. > > The astute reader will also observe you measure the mean latency. This is not very useful, and you should look at either a boxplot, kernel density plot, histogram. or the like. If you know the data is normally distributed with the same standard deviation, then your average latency makes sense as a comparable value. But this requires you plot the data, look at it and make sure they have that shape. Otherwise you can be led astray. Thank you for pointing this out. I was not very clear on my first email about this. The bench is storing the results in a histogram, and performing statistics on a sliding window of 5 secs. For each client machine, I get the mean, and the 50th, 95, 99 and 99.9th percentile. However, when aggregating all the results for all the client machines, I only report the min, mean and max values, since I can?t meaningfully aggregate the other results (but they are still useful to see if one machine is performing worse than the other). In all these tests I?m forcing an uniform distribution of requests, but for future tests this would change. As for the coordinated omission problem, thanks for reminding me! I?ve watched Gil Tene?s talk a few times, but it?s one of those things that you forget if you don?t work on benchmarking very often. I know hdrhistogram can sort of compensate for missing values if you know the expected intervals between requests, but afaik folsom (https://github.com/folsom-project/folsom), the library basho bench uses, can?t do that. > Now to solutions: > > [?] > > Batching is an option. Collect multiple requests and send them all off at the same time.This effectively makes sure you can have multiple requests inflight, which gets you around the delay constant. It also allows a smart server to process multiple requests simultaneously, thus shedding load. Microbatching is alluring here: when the first request arrives, set a cork for 5ms. Upon having read either 500 reqs or the timer triggering, process whatever you have in the batch. Then start all over. This is used by e.g., Kafka and TensorFlow, the latter to avoid the memory bottleneck between DRAM and GPU. This sounds interesting. I?d have to rethink the architecture of the server, and I?d be worried about potentially introducing a bottleneck in the system if not implementing this correctly (as I?d need to push all client requests through a single process acting as a buffer to keep track of them?), but I?ll keep it mind. > Pipelining is another option. Send multiple requests back to back, so they are all in the network. Interlace your receive loop with new requests being sent, so you can keep the work going. You should consider tagging messages with unique identifiers so they can be told apart. This allows out-of-order processing. See plan9's 9p protocol, RabbitMQ/AMQP's correlation IDs, or HTTP/2. Quick implementation: Loic Hoguin's Cowboy/Gun combo works wonders here, and uses the same code base (cowlib). This will avoid the wait time effectively. Thanks for the suggestion. I?m not 100% tied to TCP only, and could probably use HTTP so I can use Cowboy and Gun and avoid having to implement pipelining myself. Again, thanks for all the help! Cheers, Borja From frank.muller.erl@REDACTED Fri Mar 22 09:18:44 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Fri, 22 Mar 2019 09:18:44 +0100 Subject: [erlang-questions] Patch Package OTP 21.3.2 Released In-Reply-To: <20190321202803.GA9513@erix.ericsson.se> References: <20190321202803.GA9513@erix.ericsson.se> Message-ID: Why I can?t see 21.3.2 tarball release on GitHub (like 21.2.7)? Thank you /Frank Patch Package: OTP 21.3.2 > Git Tag: OTP-21.3.2 > Date: 2019-03-21 > Trouble Report Id: OTP-15684, OTP-15685, OTP-15688, OTP-15690 > Seq num: ERL-475, ERL-837 > System: OTP > Release: 21 > Application: erts-10.3.1, xmerl-1.3.20 > Predecessor: OTP 21.3.1 > > Check out the git tag OTP-21.3.2, and build a full OTP system > including documentation. Apply one or more applications from this > build as patches to your installation using the 'otp_patch_apply' > tool. For information on install requirements, see descriptions for > each application version below. > > --------------------------------------------------------------------- > --- erts-10.3.1 ----------------------------------------------------- > --------------------------------------------------------------------- > > Note! The erts-10.3.1 application can *not* be applied independently > of other applications on an arbitrary OTP 21 installation. > > On a full OTP 21 installation, also the following runtime > dependencies have to be satisfied: > -- kernel-6.1 (first satisfied in OTP 21.1) > -- sasl-3.3 (first satisfied in OTP 21.2) > > > --- Fixed Bugs and Malfunctions --- > > OTP-15688 Application(s): erts > > If a suspend/resume signal pair was sent to a process > while it was executing dirty, the receiving process > could later end up in a suspended state indefinitely. > This bug was introduced in ERTS version 10.0 (OTP > 21.0). > > Suspend/resume signals are sent from > erlang:suspend_process()/erlang:resume_process(). The > dbg trace tool utilize this functionality and could > thus trigger this bug. > > > OTP-15690 Application(s): erts > Related Id(s): PR-2172 > > Fix a possible deadlock when terminating the ERTS > caused by a dirty scheduler not releasing it's > run-queue lock when terminating. > > > Full runtime dependencies of erts-10.3.1: kernel-6.1, sasl-3.3, > stdlib-3.5 > > > --------------------------------------------------------------------- > --- xmerl-1.3.20 ---------------------------------------------------- > --------------------------------------------------------------------- > > The xmerl-1.3.20 application can be applied independently of other > applications on a full OTP 21 installation. > > --- Fixed Bugs and Malfunctions --- > > OTP-15684 Application(s): xmerl > Related Id(s): ERL-837 > > Handling of character references in attributes are > fixed. > > > OTP-15685 Application(s): xmerl > Related Id(s): ERL-475 > > Normalization of whitespace characters in attributes > are fixed so it works when character references are > used. > > > Full runtime dependencies of xmerl-1.3.20: erts-6.0, kernel-3.0, > stdlib-2.5 > > > --------------------------------------------------------------------- > --------------------------------------------------------------------- > --------------------------------------------------------------------- > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth@REDACTED Fri Mar 22 09:30:33 2019 From: kenneth@REDACTED (Kenneth Lundin) Date: Fri, 22 Mar 2019 09:30:33 +0100 Subject: [erlang-questions] Patch Package OTP 21.3.2 Released In-Reply-To: References: <20190321202803.GA9513@erix.ericsson.se> Message-ID: Well I can see it among the erlang/otp releases and the URL to it is here https://github.com/erlang/otp/archive/OTP-21.3.2.tar.gz This is something that github creates automatically for every git tag /Kenneth Erlang/OTP On Fri, Mar 22, 2019 at 9:19 AM Frank Muller wrote: > Why I can?t see 21.3.2 tarball release on GitHub (like 21.2.7)? > > Thank you > /Frank > > Patch Package: OTP 21.3.2 >> Git Tag: OTP-21.3.2 >> Date: 2019-03-21 >> Trouble Report Id: OTP-15684, OTP-15685, OTP-15688, OTP-15690 >> Seq num: ERL-475, ERL-837 >> System: OTP >> Release: 21 >> Application: erts-10.3.1, xmerl-1.3.20 >> Predecessor: OTP 21.3.1 >> >> Check out the git tag OTP-21.3.2, and build a full OTP system >> including documentation. Apply one or more applications from this >> build as patches to your installation using the 'otp_patch_apply' >> tool. For information on install requirements, see descriptions for >> each application version below. >> >> --------------------------------------------------------------------- >> --- erts-10.3.1 ----------------------------------------------------- >> --------------------------------------------------------------------- >> >> Note! The erts-10.3.1 application can *not* be applied independently >> of other applications on an arbitrary OTP 21 installation. >> >> On a full OTP 21 installation, also the following runtime >> dependencies have to be satisfied: >> -- kernel-6.1 (first satisfied in OTP 21.1) >> -- sasl-3.3 (first satisfied in OTP 21.2) >> >> >> --- Fixed Bugs and Malfunctions --- >> >> OTP-15688 Application(s): erts >> >> If a suspend/resume signal pair was sent to a process >> while it was executing dirty, the receiving process >> could later end up in a suspended state indefinitely. >> This bug was introduced in ERTS version 10.0 (OTP >> 21.0). >> >> Suspend/resume signals are sent from >> erlang:suspend_process()/erlang:resume_process(). The >> dbg trace tool utilize this functionality and could >> thus trigger this bug. >> >> >> OTP-15690 Application(s): erts >> Related Id(s): PR-2172 >> >> Fix a possible deadlock when terminating the ERTS >> caused by a dirty scheduler not releasing it's >> run-queue lock when terminating. >> >> >> Full runtime dependencies of erts-10.3.1: kernel-6.1, sasl-3.3, >> stdlib-3.5 >> >> >> --------------------------------------------------------------------- >> --- xmerl-1.3.20 ---------------------------------------------------- >> --------------------------------------------------------------------- >> >> The xmerl-1.3.20 application can be applied independently of other >> applications on a full OTP 21 installation. >> >> --- Fixed Bugs and Malfunctions --- >> >> OTP-15684 Application(s): xmerl >> Related Id(s): ERL-837 >> >> Handling of character references in attributes are >> fixed. >> >> >> OTP-15685 Application(s): xmerl >> Related Id(s): ERL-475 >> >> Normalization of whitespace characters in attributes >> are fixed so it works when character references are >> used. >> >> >> Full runtime dependencies of xmerl-1.3.20: erts-6.0, kernel-3.0, >> stdlib-2.5 >> >> >> --------------------------------------------------------------------- >> --------------------------------------------------------------------- >> --------------------------------------------------------------------- >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve@REDACTED Fri Mar 22 09:50:50 2019 From: steve@REDACTED (Steve Strong) Date: Fri, 22 Mar 2019 08:50:50 +0000 Subject: [erlang-questions] UNC filename handling In-Reply-To: <7d94e770c8c3d61f792f875d68e4ad42bde26e88.camel@erlang.org> References: <835BC11C-811B-4A06-9C9B-8DC3602D0CDA@srstrong.com> <7d94e770c8c3d61f792f875d68e4ad42bde26e88.camel@erlang.org> Message-ID: Excellent, many thanks John > On 21 Mar 2019, at 16:50, John H?gberg wrote: > > Hi Steve, > > Thanks for reporting this, I can confirm that it's a bug in our UNC path handling. I've included a fix in our nightly builds, and it'll be released in OTP 22-rc2 if all goes well. > > Regards, > John H?gberg > > On Thu, 2019-03-21 at 15:36 +0000, Steve Strong wrote: >> Hi, >> >> Seeing a strange thing on Windows systems: >> >> (foo@REDACTED )55> file:list_dir("z:/Signal-53-mp4/frame_store"). >> {ok,["100","2124","2142","2161"]} >> >> (foo@REDACTED )56> file:list_dir("//HB-SVR/Video/Signal-53-mp4/frame_store"). >> {ok,["frame_store"]} >> >> >> Z: is mapped to //HB-SVR/Video, so I would have expected these two commands to produce the same result, but the one going through the UNC form is giving the wrong answer (the contents of the frame_store folder are ?100?, ?2121?, ?2142" and ?2161? as the call through the mapped drive correctly returned). This issue, in turn, causes other commands such as filelib:wildcard to return the incorrect results when handed UNC paths. >> >> This is running Erlang 21.2 / erts 10.2 >> >> Is this a known issue, or am I misunderstanding how the UNC paths should behave? >> >> Cheers, >> >> Steve >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth@REDACTED Fri Mar 22 15:42:39 2019 From: kenneth@REDACTED (Kenneth Lundin) Date: Fri, 22 Mar 2019 15:42:39 +0100 Subject: [erlang-questions] HiPE in OTP 22 Message-ID: In OTP 22 HiPE (the native code generator) is not fully functional. The reasons for this are: 1. We have introduced new beam instructions which the HiPE native code compiler does not handle. 2. The new optimizations in the beam compiler create new combinations of instructions that HiPE does not handle correctly. 3. Until now HiPE has been developed by Kostis Sagonas and his students at Uppsala University and Technial University of Athens. But now other projects take up all of their resources. 4. The OTP team at Ericsson can't prioritize to address these issues either since - there is no use of HiPE among our primary customers - the effort needed to gainthe competence to addess the problems above is quite high. In OTP 22 we have therefore decided to do a workaround for HiPE (native code gen) in such a way that invokations of `erlc +native erlfile.erl` or `erlc +native erlfile.beam` will automatically fall back to producing a .beam file without native code if any of the new binary matching instructions are used. A warning will also be produced when this happens. The new beam instructions are used for binary matching so it is mostly (or only) modules containing binary matching expressions which will fail the native code generation. Notably is that the native code generations that Dialyzer does on the fly will still work since the modules chosen do not contain binary matching. Native code generation of Dialyzer makes the analysis about 40% faster. Building OTP with the configure option `--enable-native-libs` will still work in OTP 22 but a note about potential instability when running native code will be output, since we have noticed issues in our test when running these builds. We have no idea about who are using HiPE and for what, but in order to keep HiPE in shape and as part of the OTP releases we need help in maintaining it. Volunteers are welcome /Kenneth, Erlang/OTP Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmytro.lytovchenko@REDACTED Fri Mar 22 15:57:51 2019 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Fri, 22 Mar 2019 14:57:51 +0000 Subject: [erlang-questions] HiPE in OTP 22 In-Reply-To: References: Message-ID: My existing VM source knowledge and low level programming competence are probably close to the arcane knowledge required to make HiPE work. Just registering my name on the waiting list, I am 100% busy at least until the Code Beam STO, possibly also a few weeks after. Sometimes I do get paid time to assist the OTP team with whatever task is on the table, or HiPE might become a larger project, either my personal or between my employer and Ericsson's OTP team. Who knows. On Fri, 22 Mar 2019 at 14:43, Kenneth Lundin wrote: > In OTP 22 HiPE (the native code generator) is not fully functional. > > The reasons for this are: > > 1. We have introduced new beam instructions which the HiPE native code > compiler does not handle. > 2. The new optimizations in the beam compiler create new combinations > of instructions that HiPE does not handle correctly. > 3. Until now HiPE has been developed by Kostis Sagonas and his > students at Uppsala University and Technial University of Athens. But now > other projects take up all of their resources. > 4. The OTP team at Ericsson can't prioritize to address these issues > either since > - there is no use of HiPE among our primary customers > - the effort needed to gainthe competence to addess the problems > above is quite high. > > In OTP 22 we have therefore decided to do a workaround for HiPE (native > code gen) in such a way that invokations of `erlc +native erlfile.erl` or > `erlc +native erlfile.beam` will automatically fall back to producing a > .beam file without native code if any of the new binary matching > instructions are used. A warning will also be produced when this happens. > > The new beam instructions are used for binary matching so it is mostly (or > only) modules containing binary matching expressions which will fail the > native code generation. Notably is that the native code generations that > Dialyzer does on the fly will still work since the modules chosen do not > contain binary matching. Native code generation of Dialyzer makes the > analysis about 40% faster. > > Building OTP with the configure option `--enable-native-libs` will still > work in OTP 22 but a note about potential instability when running native > code will be output, since we have noticed issues in our test when running > these builds. > > We have no idea about who are using HiPE and for what, but in order to > keep HiPE in shape and as part of the OTP releases we need help in > maintaining it. > Volunteers are welcome > > /Kenneth, Erlang/OTP Ericsson > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silviu.cpp@REDACTED Sat Mar 23 07:35:33 2019 From: silviu.cpp@REDACTED (Caragea Silviu) Date: Sat, 23 Mar 2019 08:35:33 +0200 Subject: [erlang-questions] Travis issues while searching for lager Message-ID: Hello, Recently my Travis Jobs are failing on linux with : ===> Package not found in any repo: lager 3.6.9 The command "rebar3 compile" exited with 1. My config is here https://travis-ci.org/silviucpp/erlcass/jobs/510229662/config Any idea what can cause this ? Silviu -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgallaire@REDACTED Sat Mar 23 04:24:28 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Sat, 23 Mar 2019 04:24:28 +0100 Subject: [erlang-questions] Guards syntax for multiple values Message-ID: Hello everybody, I'm not very experimented in Erlang but I read carefully books and official documention. It seems to me that the guards syntax is not as good as it should be, i.e. too much verbose for multiple values. do(val1) -> val1; do(val2) -> val2; do(val3) -> val3; do(val4) -> val4; do(val5) -> val5. do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; Val =:= val5 -> Val. It's boring and error prone to write. Has a "in tuple" syntax already be considered ? Something like : do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. Cheers Florent -- FLOSS Engineer & Lawyer From frank.muller.erl@REDACTED Sat Mar 23 10:31:18 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Sat, 23 Mar 2019 10:31:18 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: You?re probably new to Erlang. You can achieve the same with parse_transform: https://github.com/mad-cocktail/gin/blob/master/README.rst There?s no point to add new syntax to the language. /Frank Hello everybody, > > I'm not very experimented in Erlang but I read carefully books and > official documention. > > It seems to me that the guards syntax is not as good as it should be, > i.e. too much verbose for multiple values. > > do(val1) -> val1; > do(val2) -> val2; > do(val3) -> val3; > do(val4) -> val4; > do(val5) -> val5. > > do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > Val =:= val5 -> Val. > > It's boring and error prone to write. > > Has a "in tuple" syntax already be considered ? Something like : > > do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > > Cheers > > Florent > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sat Mar 23 15:16:12 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 23 Mar 2019 10:16:12 -0400 Subject: [erlang-questions] Travis issues while searching for lager In-Reply-To: References: Message-ID: <20190323141612.GC2243@ferdmbp.local> On 03/23, Caragea Silviu wrote: >Hello, > >Recently my Travis Jobs are failing on linux with : > >===> Package not found in any repo: lager 3.6.9 >The command "rebar3 compile" exited with 1. > I found https://github.com/silviucpp/erlcass/ The rebar3_hex plugin should be something you install globally, not something you put in your repo. The latest rebar3_hex version only works with rebar 3.9.1 and later due to vendoring issues of core libraries interacting with hex.pm. We had the first problems with this around January, and finally solved it (with the help of community contribution) in a way that should be safe later. It unfortunately still causes issues when interacting with older rebar3 versions. You will therefore want to either use an older rebar3_hex version, or a newer rebar3 version. From arif@REDACTED Sat Mar 23 17:13:41 2019 From: arif@REDACTED (arif@REDACTED) Date: Sat, 23 Mar 2019 09:13:41 -0700 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. Message-ID: <440d9cf994e56dc295035922e40066c1@riseup.net> Yesterday I attended the Code Beam Lite conference in Bologna, Italy. It ended with a keynote by an Elixir Core Team member, entitled "Elixir Architecture 101". At the end of an otherwise interesting talk, which started with the presenter saying he hated Erlang (some in the audience found it funny) and in which he occasionally made fun of Joe and of the perceived shortcomings of Erlang, I couldn?t help wonder where Elixir was in all that talk, since the ?Elixir? architecture presented, was practically OTP. I find this very much in bad taste and not helpful towards a beneficial sharing and spreading of knowledge. I don?t know if the Code of Conduct of the Code Beam conferences contemplates this, but I would favour forbidding it. If Elixir has something good to offer, and I think it has, let its community showcase that, advance the common good and knowledge, and not promote its cause through what, in my eyes, would amount to plagiarism, viz. letting things pass for Elixir, when they are Erlang/OTP, nor through ridiculing anyone or anything, least of all the very things or persons that made it even possible. It not only looks childish to me, I believe it is also damaging to the many excellent minds in the very Elixir community. Elixir community, please be more responsible; Erlang community, please demand it. From starbelly@REDACTED Sat Mar 23 17:36:32 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sat, 23 Mar 2019 11:36:32 -0500 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: <440d9cf994e56dc295035922e40066c1@riseup.net> References: <440d9cf994e56dc295035922e40066c1@riseup.net> Message-ID: ?Who was the speaker? On 3/23/19 11:13 AM, arif@REDACTED wrote: > Yesterday I attended the Code Beam Lite conference in Bologna, Italy. It > ended with a keynote by an Elixir Core Team member, entitled "Elixir > Architecture 101". > > At the end of an otherwise interesting talk, which started with the > presenter saying he hated Erlang (some in the audience found it funny) > and in which he occasionally made fun of Joe and of the perceived > shortcomings of Erlang, I couldn?t help wonder where Elixir was in all > that talk, since the ?Elixir? architecture presented, was practically > OTP. > > I find this very much in bad taste and not helpful towards a beneficial > sharing and spreading of knowledge. I don?t know if the Code of Conduct > of the Code Beam conferences contemplates this, but I would favour > forbidding it. > > If Elixir has something good to offer, and I think it has, let its > community showcase that, advance the common good and knowledge, and not > promote its cause through what, in my eyes, would amount to plagiarism, > viz. letting things pass for Elixir, when they are Erlang/OTP, nor > through ridiculing anyone or anything, least of all the very things or > persons that made it even possible. It not only looks childish to me, I > believe it is also damaging to the many excellent minds in the very > Elixir community. > > Elixir community, please be more responsible; Erlang community, please > demand it. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From Oliver.Korpilla@REDACTED Sat Mar 23 17:44:17 2019 From: Oliver.Korpilla@REDACTED (Oliver Korpilla) Date: Sat, 23 Mar 2019 17:44:17 +0100 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <440d9cf994e56dc295035922e40066c1@riseup.net> Message-ID: An HTML attachment was scrubbed... URL: From starbelly@REDACTED Sat Mar 23 17:46:21 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sat, 23 Mar 2019 11:46:21 -0500 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <440d9cf994e56dc295035922e40066c1@riseup.net> Message-ID: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> ?I hear ya... I was being lazy :) I see who it is and I have to wonder if some of what he said was in gest? Maybe just didn't come across right? I hope so :( -- Bryan ? On 3/23/19 11:44 AM, Oliver Korpilla wrote: > I'd prefer no calling out of the name, what good will that do? > ? > *Gesendet:*?Samstag, 23. M?rz 2019 um 17:36 Uhr > *Von:*?"Bryan Paxton" > *An:*?arif@REDACTED, erlang-questions@REDACTED > *Betreff:*?Re: [erlang-questions] Elixir community, please be more > responsible; Erlang community, please demand it. > ?Who was the speaker? > > On 3/23/19 11:13 AM, arif@REDACTED wrote: > > Yesterday I attended the Code Beam Lite conference in Bologna, Italy. It > > ended with a keynote by an Elixir Core Team member, entitled "Elixir > > Architecture 101". > > > > At the end of an otherwise interesting talk, which started with the > > presenter saying he hated Erlang (some in the audience found it funny) > > and in which he occasionally made fun of Joe and of the perceived > > shortcomings of Erlang, I couldn?t help wonder where Elixir was in all > > that talk, since the ?Elixir? architecture presented, was practically > > OTP. > > > > I find this very much in bad taste and not helpful towards a beneficial > > sharing and spreading of knowledge. I don?t know if the Code of Conduct > > of the Code Beam conferences contemplates this, but I would favour > > forbidding it. > > > > If Elixir has something good to offer, and I think it has, let its > > community showcase that, advance the common good and knowledge, and not > > promote its cause through what, in my eyes, would amount to plagiarism, > > viz. letting things pass for Elixir, when they are Erlang/OTP, nor > > through ridiculing anyone or anything, least of all the very things or > > persons that made it even possible. It not only looks childish to me, I > > believe it is also damaging to the many excellent minds in the very > > Elixir community. > > > > Elixir community, please be more responsible; Erlang community, please > > demand it. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oliver.Korpilla@REDACTED Sat Mar 23 17:57:14 2019 From: Oliver.Korpilla@REDACTED (Oliver Korpilla) Date: Sat, 23 Mar 2019 17:57:14 +0100 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> References: <440d9cf994e56dc295035922e40066c1@riseup.net> <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> Message-ID: An HTML attachment was scrubbed... URL: From starbelly@REDACTED Sat Mar 23 18:22:29 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sat, 23 Mar 2019 12:22:29 -0500 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <440d9cf994e56dc295035922e40066c1@riseup.net> <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> Message-ID: ?FWIW the speaker in question has never come across to me as being hostile towards Erlang, etc. They have always been very laid back, open to ideas, erlang, etc. In fact, I was talking to them about Erlang earlier this week and they encouraged me to talk about Erlang in an Elixir dominated environment :) So, I have to assume that things came across the wrong way due to language barriers, etc.? Jokes in particular get lost in translation easily and can be seen as something hostile or malicious...? The folly of language. ?Then there's always the possibility the talk was a behavioral experiment :) ?? But I'm glad we got a line of communication open as that's the only way that squashes these issues. The BEAM communities need group therapy sometimes IMO :) ?There's been a lot of hostility from the Erlang community towards Elixir in the past... and I wonder if the echoes of all that are so ingrained in some of us that we have knee jerk reactions sometimes (i.e., we hear something from an Elixir speaker and absolutely take it the wrong way). Having come from Elixir to Erlang I very much have seen both sides of that coin. I know this much.... ?The main thing... Elixir is Erlang, LFE is Elang, Efene is Erlang, Gleam is Erlang, etc.... While from one side it appears Elixir is another language... I don't think many, especially in the Elixir community feel that way... especially core members, syntactical differences aside Elixir is erlang. BEAM on! -- Bryan On 3/23/19 11:57 AM, Oliver Korpilla wrote: > I hear you. One can only hope. Those things always happen, though, > almost invariably. I guess it has mostly to do with the desire to > carve one's own niche. > ? > *Gesendet:*?Samstag, 23. M?rz 2019 um 17:46 Uhr > *Von:*?"Bryan Paxton" > *An:*?"Oliver Korpilla" > *Cc:*?arif@REDACTED, erlang-questions@REDACTED > *Betreff:*?Re: Aw: Re: [erlang-questions] Elixir community, please be > more responsible; Erlang community, please demand it. > > ?I hear ya... I was being lazy :) I see who it is and I have to wonder > if some of what he said was in gest? Maybe just didn't come across > right? I hope so :( > > ? > > -- > > Bryan > > ? > > ? > > On 3/23/19 11:44 AM, Oliver Korpilla wrote: > > I'd prefer no calling out of the name, what good will that do? > ? > *Gesendet:*?Samstag, 23. M?rz 2019 um 17:36 Uhr > *Von:*?"Bryan Paxton" > *An:*?arif@REDACTED, erlang-questions@REDACTED > *Betreff:*?Re: [erlang-questions] Elixir community, please be more > responsible; Erlang community, please demand it. > ?Who was the speaker? > > On 3/23/19 11:13 AM, arif@REDACTED wrote: > > Yesterday I attended the Code Beam Lite conference in Bologna, > Italy. It > > ended with a keynote by an Elixir Core Team member, entitled "Elixir > > Architecture 101". > > > > At the end of an otherwise interesting talk, which started with the > > presenter saying he hated Erlang (some in the audience found it > funny) > > and in which he occasionally made fun of Joe and of the perceived > > shortcomings of Erlang, I couldn?t help wonder where Elixir was > in all > > that talk, since the ?Elixir? architecture presented, was > practically > > OTP. > > > > I find this very much in bad taste and not helpful towards a > beneficial > > sharing and spreading of knowledge. I don?t know if the Code of > Conduct > > of the Code Beam conferences contemplates this, but I would favour > > forbidding it. > > > > If Elixir has something good to offer, and I think it has, let its > > community showcase that, advance the common good and knowledge, > and not > > promote its cause through what, in my eyes, would amount to > plagiarism, > > viz. letting things pass for Elixir, when they are Erlang/OTP, nor > > through ridiculing anyone or anything, least of all the very > things or > > persons that made it even possible. It not only looks childish > to me, I > > believe it is also damaging to the many excellent minds in the very > > Elixir community. > > > > Elixir community, please be more responsible; Erlang community, > please > > demand it. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arif@REDACTED Sat Mar 23 19:15:46 2019 From: arif@REDACTED (arif) Date: Sat, 23 Mar 2019 19:15:46 +0100 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <440d9cf994e56dc295035922e40066c1@riseup.net> <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> Message-ID: <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> ok. i?ll take your word for it. it?s quite possible i got it wrong and i?m sorry to have triggered this then. thanks for sharing your thoughts Arif > On 23 Mar 2019, at 18:22, Bryan Paxton wrote: > > FWIW the speaker in question has never come across to me as being hostile towards Erlang, etc. They have always been very laid back, open to ideas, erlang, etc. In fact, I was talking to them about Erlang earlier this week and they encouraged me to talk about Erlang in an Elixir dominated environment :) So, I have to assume that things came across the wrong way due to language barriers, etc. Jokes in particular get lost in translation easily and can be seen as something hostile or malicious... The folly of language. > > Then there's always the possibility the talk was a behavioral experiment :) > > But I'm glad we got a line of communication open as that's the only way that squashes these issues. The BEAM communities need group therapy sometimes IMO :) > > There's been a lot of hostility from the Erlang community towards Elixir in the past... and I wonder if the echoes of all that are so ingrained in some of us that we have knee jerk reactions sometimes (i.e., we hear something from an Elixir speaker and absolutely take it the wrong way). Having come from Elixir to Erlang I very much have seen both sides of that coin. I know this much.... > > The main thing... Elixir is Erlang, LFE is Elang, Efene is Erlang, Gleam is Erlang, etc.... While from one side it appears Elixir is another language... I don't think many, especially in the Elixir community feel that way... especially core members, syntactical differences aside Elixir is erlang. BEAM on! > > > > -- > > Bryan > > > >> On 3/23/19 11:57 AM, Oliver Korpilla wrote: >> I hear you. One can only hope. Those things always happen, though, almost invariably. I guess it has mostly to do with the desire to carve one's own niche. >> >> Gesendet: Samstag, 23. M?rz 2019 um 17:46 Uhr >> Von: "Bryan Paxton" >> An: "Oliver Korpilla" >> Cc: arif@REDACTED, erlang-questions@REDACTED >> Betreff: Re: Aw: Re: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. >> I hear ya... I was being lazy :) I see who it is and I have to wonder if some of what he said was in gest? Maybe just didn't come across right? I hope so :( >> >> >> >> -- >> >> Bryan >> >> >> >> >> >> On 3/23/19 11:44 AM, Oliver Korpilla wrote: >> I'd prefer no calling out of the name, what good will that do? >> >> Gesendet: Samstag, 23. M?rz 2019 um 17:36 Uhr >> Von: "Bryan Paxton" >> An: arif@REDACTED, erlang-questions@REDACTED >> Betreff: Re: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. >> Who was the speaker? >> >> On 3/23/19 11:13 AM, arif@REDACTED wrote: >> > Yesterday I attended the Code Beam Lite conference in Bologna, Italy. It >> > ended with a keynote by an Elixir Core Team member, entitled "Elixir >> > Architecture 101". >> > >> > At the end of an otherwise interesting talk, which started with the >> > presenter saying he hated Erlang (some in the audience found it funny) >> > and in which he occasionally made fun of Joe and of the perceived >> > shortcomings of Erlang, I couldn?t help wonder where Elixir was in all >> > that talk, since the ?Elixir? architecture presented, was practically >> > OTP. >> > >> > I find this very much in bad taste and not helpful towards a beneficial >> > sharing and spreading of knowledge. I don?t know if the Code of Conduct >> > of the Code Beam conferences contemplates this, but I would favour >> > forbidding it. >> > >> > If Elixir has something good to offer, and I think it has, let its >> > community showcase that, advance the common good and knowledge, and not >> > promote its cause through what, in my eyes, would amount to plagiarism, >> > viz. letting things pass for Elixir, when they are Erlang/OTP, nor >> > through ridiculing anyone or anything, least of all the very things or >> > persons that made it even possible. It not only looks childish to me, I >> > believe it is also damaging to the many excellent minds in the very >> > Elixir community. >> > >> > Elixir community, please be more responsible; Erlang community, please >> > demand it. >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From starbelly@REDACTED Sat Mar 23 19:22:39 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sat, 23 Mar 2019 13:22:39 -0500 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> References: <440d9cf994e56dc295035922e40066c1@riseup.net> <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> Message-ID: <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> ?No, no... no triggering happened :) It's better to talk than to internalize... so I'm glad you brought this up. Communication is the only way to resolve misunderstanding :) :heart: -- Bryan On 3/23/19 1:15 PM, arif wrote: > ok. i?ll take your word for it. it?s quite possible i got it wrong > ?and i?m sorry to have triggered this then.? > thanks for sharing your thoughts? > Arif > > > > On 23 Mar 2019, at 18:22, Bryan Paxton > wrote: > >> ?FWIW the speaker in question has never come across to me as being >> hostile towards Erlang, etc. They have always been very laid back, >> open to ideas, erlang, etc. In fact, I was talking to them about >> Erlang earlier this week and they encouraged me to talk about Erlang >> in an Elixir dominated environment :) So, I have to assume that >> things came across the wrong way due to language barriers, etc.? >> Jokes in particular get lost in translation easily and can be seen as >> something hostile or malicious...? The folly of language. >> >> ?Then there's always the possibility the talk was a behavioral >> experiment :) >> >> ?? But I'm glad we got a line of communication open as that's the >> only way that squashes these issues. The BEAM communities need group >> therapy sometimes IMO :) >> >> ?There's been a lot of hostility from the Erlang community towards >> Elixir in the past... and I wonder if the echoes of all that are so >> ingrained in some of us that we have knee jerk reactions sometimes >> (i.e., we hear something from an Elixir speaker and absolutely take >> it the wrong way). Having come from Elixir to Erlang I very much have >> seen both sides of that coin. I know this much.... >> >> ?The main thing... Elixir is Erlang, LFE is Elang, Efene is Erlang, >> Gleam is Erlang, etc.... While from one side it appears Elixir is >> another language... I don't think many, especially in the Elixir >> community feel that way... especially core members, syntactical >> differences aside Elixir is erlang. BEAM on! >> >> >> -- >> >> Bryan >> >> >> On 3/23/19 11:57 AM, Oliver Korpilla wrote: >>> I hear you. One can only hope. Those things always happen, though, >>> almost invariably. I guess it has mostly to do with the desire to >>> carve one's own niche. >>> ? >>> *Gesendet:*?Samstag, 23. M?rz 2019 um 17:46 Uhr >>> *Von:*?"Bryan Paxton" >>> *An:*?"Oliver Korpilla" >>> *Cc:*?arif@REDACTED, erlang-questions@REDACTED >>> *Betreff:*?Re: Aw: Re: [erlang-questions] Elixir community, please >>> be more responsible; Erlang community, please demand it. >>> >>> ?I hear ya... I was being lazy :) I see who it is and I have to >>> wonder if some of what he said was in gest? Maybe just didn't come >>> across right? I hope so :( >>> >>> ? >>> >>> -- >>> >>> Bryan >>> >>> ? >>> >>> ? >>> >>> On 3/23/19 11:44 AM, Oliver Korpilla wrote: >>> >>> I'd prefer no calling out of the name, what good will that do? >>> ? >>> *Gesendet:*?Samstag, 23. M?rz 2019 um 17:36 Uhr >>> *Von:*?"Bryan Paxton" >>> *An:*?arif@REDACTED, erlang-questions@REDACTED >>> *Betreff:*?Re: [erlang-questions] Elixir community, please be >>> more responsible; Erlang community, please demand it. >>> ?Who was the speaker? >>> >>> On 3/23/19 11:13 AM, arif@REDACTED wrote: >>> > Yesterday I attended the Code Beam Lite conference in Bologna, >>> Italy. It >>> > ended with a keynote by an Elixir Core Team member, entitled >>> "Elixir >>> > Architecture 101". >>> > >>> > At the end of an otherwise interesting talk, which started >>> with the >>> > presenter saying he hated Erlang (some in the audience found >>> it funny) >>> > and in which he occasionally made fun of Joe and of the perceived >>> > shortcomings of Erlang, I couldn?t help wonder where Elixir >>> was in all >>> > that talk, since the ?Elixir? architecture presented, was >>> practically >>> > OTP. >>> > >>> > I find this very much in bad taste and not helpful towards a >>> beneficial >>> > sharing and spreading of knowledge. I don?t know if the Code >>> of Conduct >>> > of the Code Beam conferences contemplates this, but I would favour >>> > forbidding it. >>> > >>> > If Elixir has something good to offer, and I think it has, let its >>> > community showcase that, advance the common good and >>> knowledge, and not >>> > promote its cause through what, in my eyes, would amount to >>> plagiarism, >>> > viz. letting things pass for Elixir, when they are Erlang/OTP, nor >>> > through ridiculing anyone or anything, least of all the very >>> things or >>> > persons that made it even possible. It not only looks childish >>> to me, I >>> > believe it is also damaging to the many excellent minds in the >>> very >>> > Elixir community. >>> > >>> > Elixir community, please be more responsible; Erlang >>> community, please >>> > demand it. >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex@REDACTED Sat Mar 23 20:21:35 2019 From: alex@REDACTED (alex@REDACTED) Date: Sat, 23 Mar 2019 15:21:35 -0400 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> References: <440d9cf994e56dc295035922e40066c1@riseup.net> <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> Message-ID: WTF!? They are messing up with Joe?!? No triggering...internalize what?? What's his name and address?!! I'm flying in.? Need a bottle of scotch and a map in that same order.? LOL! On 3/23/19 2:22 PM, Bryan Paxton wrote: > > ?No, no... no triggering happened :) It's better to talk than to > internalize... so I'm glad you brought this up. Communication is the > only way to resolve misunderstanding :) :heart: > > -- > > Bryan > > > On 3/23/19 1:15 PM, arif wrote: >> ok. i?ll take your word for it. it?s quite possible i got it wrong >> ?and i?m sorry to have triggered this then. >> thanks for sharing your thoughts >> Arif >> >> >> >> On 23 Mar 2019, at 18:22, Bryan Paxton > > wrote: >> >>> ?FWIW the speaker in question has never come across to me as being >>> hostile towards Erlang, etc. They have always been very laid back, >>> open to ideas, erlang, etc. In fact, I was talking to them about >>> Erlang earlier this week and they encouraged me to talk about Erlang >>> in an Elixir dominated environment :) So, I have to assume that >>> things came across the wrong way due to language barriers, etc. >>> Jokes in particular get lost in translation easily and can be seen >>> as something hostile or malicious...? The folly of language. >>> >>> ?Then there's always the possibility the talk was a behavioral >>> experiment :) >>> >>> ?? But I'm glad we got a line of communication open as that's the >>> only way that squashes these issues. The BEAM communities need group >>> therapy sometimes IMO :) >>> >>> ?There's been a lot of hostility from the Erlang community towards >>> Elixir in the past... and I wonder if the echoes of all that are so >>> ingrained in some of us that we have knee jerk reactions sometimes >>> (i.e., we hear something from an Elixir speaker and absolutely take >>> it the wrong way). Having come from Elixir to Erlang I very much >>> have seen both sides of that coin. I know this much.... >>> >>> ?The main thing... Elixir is Erlang, LFE is Elang, Efene is Erlang, >>> Gleam is Erlang, etc.... While from one side it appears Elixir is >>> another language... I don't think many, especially in the Elixir >>> community feel that way... especially core members, syntactical >>> differences aside Elixir is erlang. BEAM on! >>> >>> >>> -- >>> >>> Bryan >>> >>> >>> On 3/23/19 11:57 AM, Oliver Korpilla wrote: >>>> I hear you. One can only hope. Those things always happen, though, >>>> almost invariably. I guess it has mostly to do with the desire to >>>> carve one's own niche. >>>> *Gesendet:*?Samstag, 23. M?rz 2019 um 17:46 Uhr >>>> *Von:*?"Bryan Paxton" >>>> *An:*?"Oliver Korpilla" >>>> *Cc:* arif@REDACTED, erlang-questions@REDACTED >>>> *Betreff:*?Re: Aw: Re: [erlang-questions] Elixir community, please >>>> be more responsible; Erlang community, please demand it. >>>> >>>> ?I hear ya... I was being lazy :) I see who it is and I have to >>>> wonder if some of what he said was in gest? Maybe just didn't come >>>> across right? I hope so :( >>>> >>>> -- >>>> >>>> Bryan >>>> >>>> On 3/23/19 11:44 AM, Oliver Korpilla wrote: >>>> >>>> I'd prefer no calling out of the name, what good will that do? >>>> *Gesendet:*?Samstag, 23. M?rz 2019 um 17:36 Uhr >>>> *Von:*?"Bryan Paxton" >>>> *An:* arif@REDACTED, erlang-questions@REDACTED >>>> *Betreff:*?Re: [erlang-questions] Elixir community, please be >>>> more responsible; Erlang community, please demand it. >>>> ?Who was the speaker? >>>> >>>> On 3/23/19 11:13 AM, arif@REDACTED wrote: >>>> > Yesterday I attended the Code Beam Lite conference in >>>> Bologna, Italy. It >>>> > ended with a keynote by an Elixir Core Team member, entitled >>>> "Elixir >>>> > Architecture 101". >>>> > >>>> > At the end of an otherwise interesting talk, which started >>>> with the >>>> > presenter saying he hated Erlang (some in the audience found >>>> it funny) >>>> > and in which he occasionally made fun of Joe and of the perceived >>>> > shortcomings of Erlang, I couldn?t help wonder where Elixir >>>> was in all >>>> > that talk, since the ?Elixir? architecture presented, was >>>> practically >>>> > OTP. >>>> > >>>> > I find this very much in bad taste and not helpful towards a >>>> beneficial >>>> > sharing and spreading of knowledge. I don?t know if the Code >>>> of Conduct >>>> > of the Code Beam conferences contemplates this, but I would >>>> favour >>>> > forbidding it. >>>> > >>>> > If Elixir has something good to offer, and I think it has, >>>> let its >>>> > community showcase that, advance the common good and >>>> knowledge, and not >>>> > promote its cause through what, in my eyes, would amount to >>>> plagiarism, >>>> > viz. letting things pass for Elixir, when they are >>>> Erlang/OTP, nor >>>> > through ridiculing anyone or anything, least of all the very >>>> things or >>>> > persons that made it even possible. It not only looks >>>> childish to me, I >>>> > believe it is also damaging to the many excellent minds in >>>> the very >>>> > Elixir community. >>>> > >>>> > Elixir community, please be more responsible; Erlang >>>> community, please >>>> > demand it. >>>> > _______________________________________________ >>>> > erlang-questions mailing list >>>> > erlang-questions@REDACTED >>>> > http://erlang.org/mailman/listinfo/erlang-questions >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From starbelly@REDACTED Sat Mar 23 20:27:12 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sat, 23 Mar 2019 14:27:12 -0500 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <440d9cf994e56dc295035922e40066c1@riseup.net> <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> Message-ID: <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> ? You need a lagom bottles of scotch :) On 3/23/19 2:21 PM, alex@REDACTED wrote: > > WTF!? They are messing up with Joe?!? No triggering...internalize > what?? What's his name and address?!!? I'm flying in.? Need a bottle > of scotch and a map in that same order.? LOL! > > On 3/23/19 2:22 PM, Bryan Paxton wrote: >> >> ?No, no... no triggering happened :) It's better to talk than to >> internalize... so I'm glad you brought this up. Communication is the >> only way to resolve misunderstanding :) :heart: >> >> -- >> >> Bryan >> >> >> On 3/23/19 1:15 PM, arif wrote: >>> ok. i?ll take your word for it. it?s quite possible i got it wrong >>> ?and i?m sorry to have triggered this then.? >>> thanks for sharing your thoughts? >>> Arif >>> >>> >>> >>> On 23 Mar 2019, at 18:22, Bryan Paxton >> > wrote: >>> >>>> ?FWIW the speaker in question has never come across to me as being >>>> hostile towards Erlang, etc. They have always been very laid back, >>>> open to ideas, erlang, etc. In fact, I was talking to them about >>>> Erlang earlier this week and they encouraged me to talk about >>>> Erlang in an Elixir dominated environment :) So, I have to assume >>>> that things came across the wrong way due to language barriers, >>>> etc.? Jokes in particular get lost in translation easily and can be >>>> seen as something hostile or malicious...? The folly of language. >>>> >>>> ?Then there's always the possibility the talk was a behavioral >>>> experiment :) >>>> >>>> ?? But I'm glad we got a line of communication open as that's the >>>> only way that squashes these issues. The BEAM communities need >>>> group therapy sometimes IMO :) >>>> >>>> ?There's been a lot of hostility from the Erlang community towards >>>> Elixir in the past... and I wonder if the echoes of all that are so >>>> ingrained in some of us that we have knee jerk reactions sometimes >>>> (i.e., we hear something from an Elixir speaker and absolutely take >>>> it the wrong way). Having come from Elixir to Erlang I very much >>>> have seen both sides of that coin. I know this much.... >>>> >>>> ?The main thing... Elixir is Erlang, LFE is Elang, Efene is Erlang, >>>> Gleam is Erlang, etc.... While from one side it appears Elixir is >>>> another language... I don't think many, especially in the Elixir >>>> community feel that way... especially core members, syntactical >>>> differences aside Elixir is erlang. BEAM on! >>>> >>>> >>>> -- >>>> >>>> Bryan >>>> >>>> >>>> On 3/23/19 11:57 AM, Oliver Korpilla wrote: >>>>> I hear you. One can only hope. Those things always happen, though, >>>>> almost invariably. I guess it has mostly to do with the desire to >>>>> carve one's own niche. >>>>> ? >>>>> *Gesendet:*?Samstag, 23. M?rz 2019 um 17:46 Uhr >>>>> *Von:*?"Bryan Paxton" >>>>> *An:*?"Oliver Korpilla" >>>>> *Cc:*?arif@REDACTED, erlang-questions@REDACTED >>>>> *Betreff:*?Re: Aw: Re: [erlang-questions] Elixir community, please >>>>> be more responsible; Erlang community, please demand it. >>>>> >>>>> ?I hear ya... I was being lazy :) I see who it is and I have to >>>>> wonder if some of what he said was in gest? Maybe just didn't come >>>>> across right? I hope so :( >>>>> >>>>> ? >>>>> >>>>> -- >>>>> >>>>> Bryan >>>>> >>>>> ? >>>>> >>>>> ? >>>>> >>>>> On 3/23/19 11:44 AM, Oliver Korpilla wrote: >>>>> >>>>> I'd prefer no calling out of the name, what good will that do? >>>>> ? >>>>> *Gesendet:*?Samstag, 23. M?rz 2019 um 17:36 Uhr >>>>> *Von:*?"Bryan Paxton" >>>>> *An:*?arif@REDACTED, erlang-questions@REDACTED >>>>> *Betreff:*?Re: [erlang-questions] Elixir community, please be >>>>> more responsible; Erlang community, please demand it. >>>>> ?Who was the speaker? >>>>> >>>>> On 3/23/19 11:13 AM, arif@REDACTED wrote: >>>>> > Yesterday I attended the Code Beam Lite conference in >>>>> Bologna, Italy. It >>>>> > ended with a keynote by an Elixir Core Team member, entitled >>>>> "Elixir >>>>> > Architecture 101". >>>>> > >>>>> > At the end of an otherwise interesting talk, which started >>>>> with the >>>>> > presenter saying he hated Erlang (some in the audience found >>>>> it funny) >>>>> > and in which he occasionally made fun of Joe and of the >>>>> perceived >>>>> > shortcomings of Erlang, I couldn?t help wonder where Elixir >>>>> was in all >>>>> > that talk, since the ?Elixir? architecture presented, was >>>>> practically >>>>> > OTP. >>>>> > >>>>> > I find this very much in bad taste and not helpful towards a >>>>> beneficial >>>>> > sharing and spreading of knowledge. I don?t know if the Code >>>>> of Conduct >>>>> > of the Code Beam conferences contemplates this, but I would >>>>> favour >>>>> > forbidding it. >>>>> > >>>>> > If Elixir has something good to offer, and I think it has, >>>>> let its >>>>> > community showcase that, advance the common good and >>>>> knowledge, and not >>>>> > promote its cause through what, in my eyes, would amount to >>>>> plagiarism, >>>>> > viz. letting things pass for Elixir, when they are >>>>> Erlang/OTP, nor >>>>> > through ridiculing anyone or anything, least of all the very >>>>> things or >>>>> > persons that made it even possible. It not only looks >>>>> childish to me, I >>>>> > believe it is also damaging to the many excellent minds in >>>>> the very >>>>> > Elixir community. >>>>> > >>>>> > Elixir community, please be more responsible; Erlang >>>>> community, please >>>>> > demand it. >>>>> > _______________________________________________ >>>>> > erlang-questions mailing list >>>>> > erlang-questions@REDACTED >>>>> > http://erlang.org/mailman/listinfo/erlang-questions >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sun Mar 24 11:40:34 2019 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 24 Mar 2019 11:40:34 +0100 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> References: <440d9cf994e56dc295035922e40066c1@riseup.net> <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> Message-ID: Well I can't really comment on the talk since I wasn't there - so all I can comment on are the comments I've read here. I for one welcome all the things the Elixir folks are doing - but I have noticed the following: - Elixir folks are re-using Erlang libraries - Erlang folks are not (it seems to me) reusing Elixir libraries The "how to call Erlang from Elixir" documentation is great - the opposite "how to call Elixir from Elixir" is not (or have I missed something) Things like nerves, scenic, Phoenix etc. look great to me - but seem to be used almost exclusively by Elixir folks. Has anybody made, for example, a pure Erlang interface to scenic? As for things said in talks that upset people - I have done this myself on several occasions - you say something that gets misinterpreted and then everybody gets upset and they don't talk about the subject of the talk but about the thing that annoyed them. Andrea mailed me off-list with an apology - funny really when somebody mails you apologising for something that you didn't even know had happened but nice of him to do so ... I'm just curious - has anybody made a pure Erlang interface to scenic? And since this is the erlang list - how about joining the elixir forum so you can get an idea of what's going on over there - lot's of fun stuff I see Cheers /Joe On Sat, Mar 23, 2019 at 8:27 PM Bryan Paxton wrote: > > You need a lagom bottles of scotch :) > > On 3/23/19 2:21 PM, alex@REDACTED wrote: > > WTF! They are messing up with Joe?! No triggering...internalize what? What's his name and address?!! I'm flying in. Need a bottle of scotch and a map in that same order. LOL! > > On 3/23/19 2:22 PM, Bryan Paxton wrote: > > No, no... no triggering happened :) It's better to talk than to internalize... so I'm glad you brought this up. Communication is the only way to resolve misunderstanding :) :heart: > > -- > > Bryan > > > On 3/23/19 1:15 PM, arif wrote: > > ok. i?ll take your word for it. it?s quite possible i got it wrong and i?m sorry to have triggered this then. > thanks for sharing your thoughts > Arif > > > > On 23 Mar 2019, at 18:22, Bryan Paxton wrote: > > FWIW the speaker in question has never come across to me as being hostile towards Erlang, etc. They have always been very laid back, open to ideas, erlang, etc. In fact, I was talking to them about Erlang earlier this week and they encouraged me to talk about Erlang in an Elixir dominated environment :) So, I have to assume that things came across the wrong way due to language barriers, etc. Jokes in particular get lost in translation easily and can be seen as something hostile or malicious... The folly of language. > > Then there's always the possibility the talk was a behavioral experiment :) > > But I'm glad we got a line of communication open as that's the only way that squashes these issues. The BEAM communities need group therapy sometimes IMO :) > > There's been a lot of hostility from the Erlang community towards Elixir in the past... and I wonder if the echoes of all that are so ingrained in some of us that we have knee jerk reactions sometimes (i.e., we hear something from an Elixir speaker and absolutely take it the wrong way). Having come from Elixir to Erlang I very much have seen both sides of that coin. I know this much.... > > The main thing... Elixir is Erlang, LFE is Elang, Efene is Erlang, Gleam is Erlang, etc.... While from one side it appears Elixir is another language... I don't think many, especially in the Elixir community feel that way... especially core members, syntactical differences aside Elixir is erlang. BEAM on! > > > -- > > Bryan > > > On 3/23/19 11:57 AM, Oliver Korpilla wrote: > > I hear you. One can only hope. Those things always happen, though, almost invariably. I guess it has mostly to do with the desire to carve one's own niche. > > Gesendet: Samstag, 23. M?rz 2019 um 17:46 Uhr > Von: "Bryan Paxton" > An: "Oliver Korpilla" > Cc: arif@REDACTED, erlang-questions@REDACTED > Betreff: Re: Aw: Re: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. > > I hear ya... I was being lazy :) I see who it is and I have to wonder if some of what he said was in gest? Maybe just didn't come across right? I hope so :( > > > > -- > > Bryan > > > > > > On 3/23/19 11:44 AM, Oliver Korpilla wrote: > > I'd prefer no calling out of the name, what good will that do? > > Gesendet: Samstag, 23. M?rz 2019 um 17:36 Uhr > Von: "Bryan Paxton" > An: arif@REDACTED, erlang-questions@REDACTED > Betreff: Re: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. > Who was the speaker? > > On 3/23/19 11:13 AM, arif@REDACTED wrote: > > Yesterday I attended the Code Beam Lite conference in Bologna, Italy. It > > ended with a keynote by an Elixir Core Team member, entitled "Elixir > > Architecture 101". > > > > At the end of an otherwise interesting talk, which started with the > > presenter saying he hated Erlang (some in the audience found it funny) > > and in which he occasionally made fun of Joe and of the perceived > > shortcomings of Erlang, I couldn?t help wonder where Elixir was in all > > that talk, since the ?Elixir? architecture presented, was practically > > OTP. > > > > I find this very much in bad taste and not helpful towards a beneficial > > sharing and spreading of knowledge. I don?t know if the Code of Conduct > > of the Code Beam conferences contemplates this, but I would favour > > forbidding it. > > > > If Elixir has something good to offer, and I think it has, let its > > community showcase that, advance the common good and knowledge, and not > > promote its cause through what, in my eyes, would amount to plagiarism, > > viz. letting things pass for Elixir, when they are Erlang/OTP, nor > > through ridiculing anyone or anything, least of all the very things or > > persons that made it even possible. It not only looks childish to me, I > > believe it is also damaging to the many excellent minds in the very > > Elixir community. > > > > Elixir community, please be more responsible; Erlang community, please > > demand it. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dieter@REDACTED Sun Mar 24 12:29:19 2019 From: dieter@REDACTED (dieter@REDACTED) Date: Sun, 24 Mar 2019 12:29:19 +0100 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <440d9cf994e56dc295035922e40066c1@riseup.net> <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> Message-ID: <9C503A8F-6704-47CB-B539-49C44B97C365@schoen.or.at> Hi, this discussion turns out to be very nice and uplifting. A very fine example how problems can be solved! Regarding nerves: this is on my list of things to try, on the way I might also peek a bit into elixir. Regards, Dieter Am 24. M?rz 2019 11:40:34 MEZ schrieb Joe Armstrong : >Well I can't really comment on the talk since I wasn't there - so all >I can comment >on are the comments I've read here. > >I for one welcome all the things the Elixir folks are doing - but I >have noticed the following: > >- Elixir folks are re-using Erlang libraries >- Erlang folks are not (it seems to me) reusing Elixir libraries > >The "how to call Erlang from Elixir" documentation is great - the >opposite "how to call Elixir from Elixir" is not (or have I missed >something) > >Things like nerves, scenic, Phoenix etc. look great to me - but seem to >be used >almost exclusively by Elixir folks. > >Has anybody made, for example, a pure Erlang interface to scenic? > >As for things said in talks that upset people - I have done this myself >on several occasions - you say something that gets misinterpreted >and then everybody gets upset and they don't talk about the subject >of the talk but about the thing that annoyed them. > >Andrea mailed me off-list with an apology - funny really when somebody >mails you apologising for something that you didn't even know had >happened >but nice of him to do so ... > >I'm just curious - has anybody made a pure Erlang interface to scenic? > >And since this is the erlang list - how about joining the elixir forum >so you can get >an idea of what's going on over there - lot's of fun stuff I see > >Cheers > >/Joe > > >On Sat, Mar 23, 2019 at 8:27 PM Bryan Paxton >wrote: >> >> You need a lagom bottles of scotch :) >> >> On 3/23/19 2:21 PM, alex@REDACTED wrote: >> >> WTF! They are messing up with Joe?! No triggering...internalize >what? What's his name and address?!! I'm flying in. Need a bottle of >scotch and a map in that same order. LOL! >> >> On 3/23/19 2:22 PM, Bryan Paxton wrote: >> >> No, no... no triggering happened :) It's better to talk than to >internalize... so I'm glad you brought this up. Communication is the >only way to resolve misunderstanding :) :heart: >> >> -- >> >> Bryan >> >> >> On 3/23/19 1:15 PM, arif wrote: >> >> ok. i?ll take your word for it. it?s quite possible i got it wrong >and i?m sorry to have triggered this then. >> thanks for sharing your thoughts >> Arif >> >> >> >> On 23 Mar 2019, at 18:22, Bryan Paxton wrote: >> >> FWIW the speaker in question has never come across to me as being >hostile towards Erlang, etc. They have always been very laid back, open >to ideas, erlang, etc. In fact, I was talking to them about Erlang >earlier this week and they encouraged me to talk about Erlang in an >Elixir dominated environment :) So, I have to assume that things came >across the wrong way due to language barriers, etc. Jokes in >particular get lost in translation easily and can be seen as something >hostile or malicious... The folly of language. >> >> Then there's always the possibility the talk was a behavioral >experiment :) >> >> But I'm glad we got a line of communication open as that's the >only way that squashes these issues. The BEAM communities need group >therapy sometimes IMO :) >> >> There's been a lot of hostility from the Erlang community towards >Elixir in the past... and I wonder if the echoes of all that are so >ingrained in some of us that we have knee jerk reactions sometimes >(i.e., we hear something from an Elixir speaker and absolutely take it >the wrong way). Having come from Elixir to Erlang I very much have seen >both sides of that coin. I know this much.... >> >> The main thing... Elixir is Erlang, LFE is Elang, Efene is Erlang, >Gleam is Erlang, etc.... While from one side it appears Elixir is >another language... I don't think many, especially in the Elixir >community feel that way... especially core members, syntactical >differences aside Elixir is erlang. BEAM on! >> >> >> -- >> >> Bryan >> >> >> On 3/23/19 11:57 AM, Oliver Korpilla wrote: >> >> I hear you. One can only hope. Those things always happen, though, >almost invariably. I guess it has mostly to do with the desire to carve >one's own niche. >> >> Gesendet: Samstag, 23. M?rz 2019 um 17:46 Uhr >> Von: "Bryan Paxton" >> An: "Oliver Korpilla" >> Cc: arif@REDACTED, erlang-questions@REDACTED >> Betreff: Re: Aw: Re: [erlang-questions] Elixir community, please be >more responsible; Erlang community, please demand it. >> >> I hear ya... I was being lazy :) I see who it is and I have to >wonder if some of what he said was in gest? Maybe just didn't come >across right? I hope so :( >> >> >> >> -- >> >> Bryan >> >> >> >> >> >> On 3/23/19 11:44 AM, Oliver Korpilla wrote: >> >> I'd prefer no calling out of the name, what good will that do? >> >> Gesendet: Samstag, 23. M?rz 2019 um 17:36 Uhr >> Von: "Bryan Paxton" >> An: arif@REDACTED, erlang-questions@REDACTED >> Betreff: Re: [erlang-questions] Elixir community, please be more >responsible; Erlang community, please demand it. >> Who was the speaker? >> >> On 3/23/19 11:13 AM, arif@REDACTED wrote: >> > Yesterday I attended the Code Beam Lite conference in Bologna, >Italy. It >> > ended with a keynote by an Elixir Core Team member, entitled >"Elixir >> > Architecture 101". >> > >> > At the end of an otherwise interesting talk, which started with the >> > presenter saying he hated Erlang (some in the audience found it >funny) >> > and in which he occasionally made fun of Joe and of the perceived >> > shortcomings of Erlang, I couldn?t help wonder where Elixir was in >all >> > that talk, since the ?Elixir? architecture presented, was >practically >> > OTP. >> > >> > I find this very much in bad taste and not helpful towards a >beneficial >> > sharing and spreading of knowledge. I don?t know if the Code of >Conduct >> > of the Code Beam conferences contemplates this, but I would favour >> > forbidding it. >> > >> > If Elixir has something good to offer, and I think it has, let its >> > community showcase that, advance the common good and knowledge, and >not >> > promote its cause through what, in my eyes, would amount to >plagiarism, >> > viz. letting things pass for Elixir, when they are Erlang/OTP, nor >> > through ridiculing anyone or anything, least of all the very things >or >> > persons that made it even possible. It not only looks childish to >me, I >> > believe it is also damaging to the many excellent minds in the very >> > Elixir community. >> > >> > Elixir community, please be more responsible; Erlang community, >please >> > demand it. >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sun Mar 24 13:54:11 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 24 Mar 2019 08:54:11 -0400 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> Message-ID: <20190324125410.GD2243@ferdmbp.local> On 03/24, Joe Armstrong wrote: >I for one welcome all the things the Elixir folks are doing - but I >have noticed the following: > >- Elixir folks are re-using Erlang libraries >- Erlang folks are not (it seems to me) reusing Elixir libraries > >The "how to call Erlang from Elixir" documentation is great - the >opposite "how to call Elixir from Elixir" is not (or have I missed something) > >Things like nerves, scenic, Phoenix etc. look great to me - but seem to be used >almost exclusively by Elixir folks. > >Has anybody made, for example, a pure Erlang interface to scenic? > Well, there are some limitations there. - You can use mix to build your Erlang project and then use Elixir in there - You can use rebar3 with the rebar_mix plugin (along with an Elixir install) to build Elixir dependencies (see https://github.com/tsloughter/rebar_mix) But in all cases, you will not necessarily be able to use Elixir code when it heavily relies on macros at the call-site rather than internally. So for example, a lot of usage of _plugs_ in Phoenix rely on macros running within the controller compilation step to read the declaration and inline them "somewhere??" with no obvious way to do it without the macros. That specific stuff that relies on macros in _your Elixir code_ cannot be ported to work with _your Erlang code_, because, well, we don't have the same macro mechanisms available. Similarly, Erlang parse transforms may not remain fully applicable to Elixir modules in the future. This means that Ecto, which is a huge part of a lot of web framework usage, also won't be usable for Erlang users, since it is very macro-dependent. But if you look at other libraries (or frameworks) such as Raxx (https://github.com/CrowdHailer/raxx), then this is a framework that is fully written in Elixir, yet usable from Erlang (there's a demo at https://github.com/CrowdHailer/greetings-ace-raxx-erlang-example). Similarly, a library such as https://github.com/ericmj/decimal for arbitrary precision arithmetic should be fine to use. This stuff has been available to rebar3 users since around late 2018, so I assume it has seen slow adoption due to its being rather new, but we (rebar3 maintainers) are confident that this bigger interplay is worth it and should be seeing adoption over time. Finally, the stuff we're setting up with the Erlang Ecosystem Foundation is also aimed at making language interplay easier for all languages of the ecosystem. From t@REDACTED Sun Mar 24 15:12:23 2019 From: t@REDACTED (Tristan Sloughter) Date: Sun, 24 Mar 2019 10:12:23 -0400 Subject: [erlang-questions] =?utf-8?q?Elixir_community=2C_please_be_more_r?= =?utf-8?q?esponsible=3B_Erlang_community=2C_please_demand_it=2E?= In-Reply-To: <20190324125410.GD2243@ferdmbp.local> References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> <20190324125410.GD2243@ferdmbp.local> Message-ID: <28a4351e-f08d-48ce-a4cb-d2ce028fb174@www.fastmail.com> > Similarly, a library such as https://github.com/ericmj/decimal for > arbitrary precision arithmetic should be fine to use. Decimal was one of the one I was going to bring up :). That and Timex and postgrex. The issue I see is, while these may work fine with `rebar_mix`you have to have Elixir installed. This can be fine on a project that isn't a publicly shared lib, it can be awkward for those publicly shared libs. While an Elixir user will always already have Erlang, the reverse isn't true. If Elixir could be a rebar3 dependency this issue would go away and I think increase the chances of Erlang projects utilizing Elixir libs. Tristan From t@REDACTED Sun Mar 24 15:18:27 2019 From: t@REDACTED (Tristan Sloughter) Date: Sun, 24 Mar 2019 10:18:27 -0400 Subject: [erlang-questions] =?utf-8?q?Elixir_community=2C_please_be_more_r?= =?utf-8?q?esponsible=3B_Erlang_community=2C_please_demand_it=2E?= In-Reply-To: <28a4351e-f08d-48ce-a4cb-d2ce028fb174@www.fastmail.com> References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> <20190324125410.GD2243@ferdmbp.local> <28a4351e-f08d-48ce-a4cb-d2ce028fb174@www.fastmail.com> Message-ID: Oh and since Joe brought up the forum, there is an Erlang section https://elixirforum.com/c/erlang-forum Maybe if someone of the burden of maintaining (labor and costs) the forum were offered to be undertaken by the Foundation they would be open to renaming the entire forum to make it clearer as a beam ecosystem forum even :) From starbelly@REDACTED Sun Mar 24 16:51:18 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sun, 24 Mar 2019 10:51:18 -0500 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <440d9cf994e56dc295035922e40066c1@riseup.net> <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> Message-ID: It also looks like Andrea is having problems with the mailing list so, I'm going to copy/paste/forward this on his behalf: -- BEGIN -- Author of the talk here. I'm sorry if anything I said came off as bad taste or even against the Code of Conduct. I jokingly said I hate Erlang because I knew a lot of members in the audience and I thought it was obvious it was a joke (my bad). I also said "just kidding" but maybe I wasn't clear enough. I did comment that Erlang's simple_one_for_one is confusing (which I do believe it is). I could probably have expanded on that though, instead of leaving it as a brief remark. But I don't think criticizing Erlang is not allowed, same as I don't think criticizing Elixir is not permitted, and that's why I felt free to make the comment. I did not make fun of Joe. I included two pictures of him in the presentation that I found on Google, since he is an important and known figure in both Erlang and Elixir communities. One of them was a silly meme about how great hot code swapping is but severely underused. I will reach out to Joe and apologize if I stepped out of line. Arif, I agree with you that "Elixir Architecture 101" is a bad title and the presentation was definitely about Erlang/OTP first and foremost. That's why I never said "Elixir application" or "this is how you do this in Elixir", but always said "Elixir and Erlang" or "Erlang and Elixir". I'm aware Elixir doesn't exist without Erlang and I'm not at all ungrateful for Erlang. You will also see the same in Elixir documentation and most of its ecosystem: you are not building an "Elixir application" or a "Phoenix application", but an Erlang/OTP one. In other talks I've often said things that promote the use of Erlang in the Elixir community and that promote the cooperation between the communities, which is something I strongly believe in. Anyhow, sorry for the mess. I'll do better next time. Cheers, Andrea Leopardi an.leopardi@REDACTED -- END -- On 3/24/19 5:40 AM, Joe Armstrong wrote: > Well I can't really comment on the talk since I wasn't there - so all > I can comment > on are the comments I've read here. > > I for one welcome all the things the Elixir folks are doing - but I > have noticed the following: > > - Elixir folks are re-using Erlang libraries > - Erlang folks are not (it seems to me) reusing Elixir libraries > > The "how to call Erlang from Elixir" documentation is great - the > opposite "how to call Elixir from Elixir" is not (or have I missed something) > > Things like nerves, scenic, Phoenix etc. look great to me - but seem to be used > almost exclusively by Elixir folks. > > Has anybody made, for example, a pure Erlang interface to scenic? > > As for things said in talks that upset people - I have done this myself > on several occasions - you say something that gets misinterpreted > and then everybody gets upset and they don't talk about the subject > of the talk but about the thing that annoyed them. > > Andrea mailed me off-list with an apology - funny really when somebody > mails you apologising for something that you didn't even know had happened > but nice of him to do so ... > > I'm just curious - has anybody made a pure Erlang interface to scenic? > > And since this is the erlang list - how about joining the elixir forum > so you can get > an idea of what's going on over there - lot's of fun stuff I see > > Cheers > > /Joe > > > On Sat, Mar 23, 2019 at 8:27 PM Bryan Paxton wrote: >> You need a lagom bottles of scotch :) >> >> On 3/23/19 2:21 PM, alex@REDACTED wrote: >> >> WTF! They are messing up with Joe?! No triggering...internalize what? What's his name and address?!! I'm flying in. Need a bottle of scotch and a map in that same order. LOL! >> >> On 3/23/19 2:22 PM, Bryan Paxton wrote: >> >> No, no... no triggering happened :) It's better to talk than to internalize... so I'm glad you brought this up. Communication is the only way to resolve misunderstanding :) :heart: >> >> -- >> >> Bryan >> >> >> On 3/23/19 1:15 PM, arif wrote: >> >> ok. i?ll take your word for it. it?s quite possible i got it wrong and i?m sorry to have triggered this then. >> thanks for sharing your thoughts >> Arif >> >> >> >> On 23 Mar 2019, at 18:22, Bryan Paxton wrote: >> >> FWIW the speaker in question has never come across to me as being hostile towards Erlang, etc. They have always been very laid back, open to ideas, erlang, etc. In fact, I was talking to them about Erlang earlier this week and they encouraged me to talk about Erlang in an Elixir dominated environment :) So, I have to assume that things came across the wrong way due to language barriers, etc. Jokes in particular get lost in translation easily and can be seen as something hostile or malicious... The folly of language. >> >> Then there's always the possibility the talk was a behavioral experiment :) >> >> But I'm glad we got a line of communication open as that's the only way that squashes these issues. The BEAM communities need group therapy sometimes IMO :) >> >> There's been a lot of hostility from the Erlang community towards Elixir in the past... and I wonder if the echoes of all that are so ingrained in some of us that we have knee jerk reactions sometimes (i.e., we hear something from an Elixir speaker and absolutely take it the wrong way). Having come from Elixir to Erlang I very much have seen both sides of that coin. I know this much.... >> >> The main thing... Elixir is Erlang, LFE is Elang, Efene is Erlang, Gleam is Erlang, etc.... While from one side it appears Elixir is another language... I don't think many, especially in the Elixir community feel that way... especially core members, syntactical differences aside Elixir is erlang. BEAM on! >> >> >> -- >> >> Bryan >> >> >> On 3/23/19 11:57 AM, Oliver Korpilla wrote: >> >> I hear you. One can only hope. Those things always happen, though, almost invariably. I guess it has mostly to do with the desire to carve one's own niche. >> >> Gesendet: Samstag, 23. M?rz 2019 um 17:46 Uhr >> Von: "Bryan Paxton" >> An: "Oliver Korpilla" >> Cc: arif@REDACTED, erlang-questions@REDACTED >> Betreff: Re: Aw: Re: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. >> >> I hear ya... I was being lazy :) I see who it is and I have to wonder if some of what he said was in gest? Maybe just didn't come across right? I hope so :( >> >> >> >> -- >> >> Bryan >> >> >> >> >> >> On 3/23/19 11:44 AM, Oliver Korpilla wrote: >> >> I'd prefer no calling out of the name, what good will that do? >> >> Gesendet: Samstag, 23. M?rz 2019 um 17:36 Uhr >> Von: "Bryan Paxton" >> An: arif@REDACTED, erlang-questions@REDACTED >> Betreff: Re: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. >> Who was the speaker? >> >> On 3/23/19 11:13 AM, arif@REDACTED wrote: >>> Yesterday I attended the Code Beam Lite conference in Bologna, Italy. It >>> ended with a keynote by an Elixir Core Team member, entitled "Elixir >>> Architecture 101". >>> >>> At the end of an otherwise interesting talk, which started with the >>> presenter saying he hated Erlang (some in the audience found it funny) >>> and in which he occasionally made fun of Joe and of the perceived >>> shortcomings of Erlang, I couldn?t help wonder where Elixir was in all >>> that talk, since the ?Elixir? architecture presented, was practically >>> OTP. >>> >>> I find this very much in bad taste and not helpful towards a beneficial >>> sharing and spreading of knowledge. I don?t know if the Code of Conduct >>> of the Code Beam conferences contemplates this, but I would favour >>> forbidding it. >>> >>> If Elixir has something good to offer, and I think it has, let its >>> community showcase that, advance the common good and knowledge, and not >>> promote its cause through what, in my eyes, would amount to plagiarism, >>> viz. letting things pass for Elixir, when they are Erlang/OTP, nor >>> through ridiculing anyone or anything, least of all the very things or >>> persons that made it even possible. It not only looks childish to me, I >>> believe it is also damaging to the many excellent minds in the very >>> Elixir community. >>> >>> Elixir community, please be more responsible; Erlang community, please >>> demand it. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sun Mar 24 17:26:36 2019 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 24 Mar 2019 17:26:36 +0100 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: <20190324125410.GD2243@ferdmbp.local> References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> <20190324125410.GD2243@ferdmbp.local> Message-ID: On Sun, Mar 24, 2019 at 1:54 PM Fred Hebert wrote: > > On 03/24, Joe Armstrong wrote: > >I for one welcome all the things the Elixir folks are doing - but I > >have noticed the following: > > > >- Elixir folks are re-using Erlang libraries > >- Erlang folks are not (it seems to me) reusing Elixir libraries > > > >The "how to call Erlang from Elixir" documentation is great - the > >opposite "how to call Elixir from Elixir" is not (or have I missed something) > > > >Things like nerves, scenic, Phoenix etc. look great to me - but seem to be used > >almost exclusively by Elixir folks. > > > >Has anybody made, for example, a pure Erlang interface to scenic? > > > > Well, there are some limitations there. > > - You can use mix to build your Erlang project and then use Elixir in > there > - You can use rebar3 with the rebar_mix plugin (along with an Elixir > install) to build Elixir dependencies (see > https://github.com/tsloughter/rebar_mix) > > But in all cases, you will not necessarily be able to use Elixir code > when it heavily relies on macros at the call-site rather than > internally. So for example, a lot of usage of _plugs_ in Phoenix rely on > macros running within the controller compilation step to read the > declaration and inline them "somewhere??" with no obvious way to do it > without the macros. > > That specific stuff that relies on macros in _your Elixir code_ cannot > be ported to work with _your Erlang code_, because, well, we don't have > the same macro mechanisms available. Similarly, Erlang parse transforms > may not remain fully applicable to Elixir modules in the future. > > This means that Ecto, which is a huge part of a lot of web framework > usage, also won't be usable for Erlang users, since it is very > macro-dependent. Interesting - I'd imagined that after compilation you'd just end up with beam code files after which you could call them from Erlang ... Could this be rectified by a "better" macro processor for erlang - more in the style of the Elixir macro processor ??? > > But if you look at other libraries (or frameworks) such as Raxx > (https://github.com/CrowdHailer/raxx), then this is a framework that is > fully written in Elixir, yet usable from Erlang (there's a demo at > https://github.com/CrowdHailer/greetings-ace-raxx-erlang-example). > Similarly, a library such as https://github.com/ericmj/decimal for > arbitrary precision arithmetic should be fine to use. > > This stuff has been available to rebar3 users since around late 2018, so > I assume it has seen slow adoption due to its being rather new, but we > (rebar3 maintainers) are confident that this bigger interplay is worth > it and should be seeing adoption over time. > > Finally, the stuff we're setting up with the Erlang Ecosystem Foundation > is also aimed at making language interplay easier for all languages of > the ecosystem. This would be great /Joe From starbelly@REDACTED Sun Mar 24 17:50:08 2019 From: starbelly@REDACTED (Bryan Paxton) Date: Sun, 24 Mar 2019 11:50:08 -0500 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> <20190324125410.GD2243@ferdmbp.local> Message-ID: <80fac090-3af7-ea24-01fb-37233af7628d@pobox.com> On 3/24/19 11:26 AM, Joe Armstrong wrote: > On Sun, Mar 24, 2019 at 1:54 PM Fred Hebert wrote: >> On 03/24, Joe Armstrong wrote: >>> I for one welcome all the things the Elixir folks are doing - but I >>> have noticed the following: >>> >>> - Elixir folks are re-using Erlang libraries >>> - Erlang folks are not (it seems to me) reusing Elixir libraries >>> >>> The "how to call Erlang from Elixir" documentation is great - the >>> opposite "how to call Elixir from Elixir" is not (or have I missed something) >>> >>> Things like nerves, scenic, Phoenix etc. look great to me - but seem to be used >>> almost exclusively by Elixir folks. >>> >>> Has anybody made, for example, a pure Erlang interface to scenic? >>> >> Well, there are some limitations there. >> >> - You can use mix to build your Erlang project and then use Elixir in >> there >> - You can use rebar3 with the rebar_mix plugin (along with an Elixir >> install) to build Elixir dependencies (see >> https://github.com/tsloughter/rebar_mix) >> >> But in all cases, you will not necessarily be able to use Elixir code >> when it heavily relies on macros at the call-site rather than >> internally. So for example, a lot of usage of _plugs_ in Phoenix rely on >> macros running within the controller compilation step to read the >> declaration and inline them "somewhere??" with no obvious way to do it >> without the macros. >> >> That specific stuff that relies on macros in _your Elixir code_ cannot >> be ported to work with _your Erlang code_, because, well, we don't have >> the same macro mechanisms available. Similarly, Erlang parse transforms >> may not remain fully applicable to Elixir modules in the future. >> >> This means that Ecto, which is a huge part of a lot of web framework >> usage, also won't be usable for Erlang users, since it is very >> macro-dependent. > Interesting - I'd imagined that after compilation you'd just end up > with beam code files after which you could call them from Erlang ... > > Could this be rectified by a "better" macro processor for erlang - more > in the style of the Elixir macro processor ??? ?I'd like to add on top of this the smallest part of the problem, but what I see as a problem none the less... 'ManyWouldPrefer':'not_to_have_to_do_this?'(Please) As stated, smallest of all the problems, but whether we like it or not UX matters. This not only applies to using Elixir but LFE, etc.? The only solutions to that problem that I could think of involve perhaps too much trickery, not really sure how the community feels about said trickery though. That is to say, to squash this problem effectively you'd have to translate/generate modules in other BEAM languages to pure erlang (or generate pure erlang interfaces), prefix the module names with 'elixir_' or 'lfe_' and then hack the compiler, shell, etc. to treat this as special so that in the end we would be using many_would_prefer:not_to_have_to_do_this(Please). Or instead of said trickery, elixir_many_would_prefer:not_to_have_to_do_this(Please). ?This brings me to another point and something I didn't understand until recently. Yes, with the rebar_mix plugin and so forth you end up using the artifact (beam file) compiled by the given beam language. As Tristan said, this requires you to have Elixir installed... it's not that big of a deal perhaps... but say you would simply like to bring in emj's Decimal lib as pointed out by Tristan... Do you really want to bring in all of Elixir just to use said lib? It seems a bit much. This is precisely why I "ported" Elixir's Version module to pure Erlang. Now, you don't need to bring in Elixir to use a fully compatible semver lib... but it's wrong... I felt bad in doing it... there is now more code in the world and that's the last thing we need. ?What I want (dreams and wishes): ? Universal BEAM/Erlang libs. It would be the bees knees and a HUGE win for the entire community for all to seamlessly be able use erlang, elixir, lfe, without having to bring in the entire language. If I'm not using the language directly, why do I need that? How this could be achieved, have no idea, erlang core perhaps... perhaps it's more complicated than that...? -- Bryan > >> But if you look at other libraries (or frameworks) such as Raxx >> (https://github.com/CrowdHailer/raxx), then this is a framework that is >> fully written in Elixir, yet usable from Erlang (there's a demo at >> https://github.com/CrowdHailer/greetings-ace-raxx-erlang-example). >> Similarly, a library such as https://github.com/ericmj/decimal for >> arbitrary precision arithmetic should be fine to use. >> >> This stuff has been available to rebar3 users since around late 2018, so >> I assume it has seen slow adoption due to its being rather new, but we >> (rebar3 maintainers) are confident that this bigger interplay is worth >> it and should be seeing adoption over time. >> >> Finally, the stuff we're setting up with the Erlang Ecosystem Foundation >> is also aimed at making language interplay easier for all languages of >> the ecosystem. > This would be great > > /Joe From devon.c.estes@REDACTED Sun Mar 24 19:46:03 2019 From: devon.c.estes@REDACTED (Devon Estes) Date: Sun, 24 Mar 2019 19:46:03 +0100 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: <80fac090-3af7-ea24-01fb-37233af7628d@pobox.com> References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> <20190324125410.GD2243@ferdmbp.local> <80fac090-3af7-ea24-01fb-37233af7628d@pobox.com> Message-ID: What if it was allowed for package maintainers to publish pre-compiled BEAM files to Hex? I would imagine that everyone who is pushing packages to Hex also has the ability to compile those packages on the machine they?re using to publish. There are clearly a whole ton of reasons why that could be a bad idea (and probably wouldn?t even work for a large chunk of macro-heavy Elixir libraries that rely on Mix configuration to be present at compile time), but it would also make for the easiest story for cross-language library sharing. It pushes the compilation step from the user of a package to the maintainer of that package, but if CLI tools knew where to put these pre-compiled BEAM files so users didn?t have to think about it, then it could make usage of some libraries much easier. It could be an optional thing for those maintainers who want to go the extra mile to make cross-language use of their packages easier. I know I?d be happy to take that extra step when publishing new versions of Benchee if it meant Erlang/LFE/etc. users could have an easier time using it. Or it could just make everything worse and more complicated ?? but it seemed like it was worth bringing up. Bryan Paxton schrieb am So. 24. M?rz 2019 um 17:50: > > On 3/24/19 11:26 AM, Joe Armstrong wrote: > > On Sun, Mar 24, 2019 at 1:54 PM Fred Hebert wrote: > >> On 03/24, Joe Armstrong wrote: > >>> I for one welcome all the things the Elixir folks are doing - but I > >>> have noticed the following: > >>> > >>> - Elixir folks are re-using Erlang libraries > >>> - Erlang folks are not (it seems to me) reusing Elixir libraries > >>> > >>> The "how to call Erlang from Elixir" documentation is great - the > >>> opposite "how to call Elixir from Elixir" is not (or have I missed > something) > >>> > >>> Things like nerves, scenic, Phoenix etc. look great to me - but seem > to be used > >>> almost exclusively by Elixir folks. > >>> > >>> Has anybody made, for example, a pure Erlang interface to scenic? > >>> > >> Well, there are some limitations there. > >> > >> - You can use mix to build your Erlang project and then use Elixir in > >> there > >> - You can use rebar3 with the rebar_mix plugin (along with an Elixir > >> install) to build Elixir dependencies (see > >> https://github.com/tsloughter/rebar_mix) > >> > >> But in all cases, you will not necessarily be able to use Elixir code > >> when it heavily relies on macros at the call-site rather than > >> internally. So for example, a lot of usage of _plugs_ in Phoenix rely on > >> macros running within the controller compilation step to read the > >> declaration and inline them "somewhere??" with no obvious way to do it > >> without the macros. > >> > >> That specific stuff that relies on macros in _your Elixir code_ cannot > >> be ported to work with _your Erlang code_, because, well, we don't have > >> the same macro mechanisms available. Similarly, Erlang parse transforms > >> may not remain fully applicable to Elixir modules in the future. > >> > >> This means that Ecto, which is a huge part of a lot of web framework > >> usage, also won't be usable for Erlang users, since it is very > >> macro-dependent. > > Interesting - I'd imagined that after compilation you'd just end up > > with beam code files after which you could call them from Erlang ... > > > > Could this be rectified by a "better" macro processor for erlang - more > > in the style of the Elixir macro processor ??? > > > I'd like to add on top of this the smallest part of the problem, but > what I see as a problem none the less... > > 'ManyWouldPrefer':'not_to_have_to_do_this?'(Please) > > > As stated, smallest of all the problems, but whether we like it or not > UX matters. This not only applies to using Elixir but LFE, etc. The > only solutions to that problem that I could think of involve perhaps too > much trickery, not really sure how the community feels about said > trickery though. That is to say, to squash this problem effectively > you'd have to translate/generate modules in other BEAM languages to pure > erlang (or generate pure erlang interfaces), prefix the module names > with 'elixir_' or 'lfe_' and then hack the compiler, shell, etc. to > treat this as special so that in the end we would be using > many_would_prefer:not_to_have_to_do_this(Please). Or instead of said > trickery, elixir_many_would_prefer:not_to_have_to_do_this(Please). > > This brings me to another point and something I didn't understand until > recently. Yes, with the rebar_mix plugin and so forth you end up using > the artifact (beam file) compiled by the given beam language. As Tristan > said, this requires you to have Elixir installed... it's not that big of > a deal perhaps... but say you would simply like to bring in emj's > Decimal lib as pointed out by Tristan... Do you really want to bring in > all of Elixir just to use said lib? It seems a bit much. This is > precisely why I "ported" Elixir's Version module to pure Erlang. Now, > you don't need to bring in Elixir to use a fully compatible semver > lib... but it's wrong... I felt bad in doing it... there is now more > code in the world and that's the last thing we need. > > What I want (dreams and wishes): > > Universal BEAM/Erlang libs. It would be the bees knees and a HUGE win > for the entire community for all to seamlessly be able use erlang, > elixir, lfe, without having to > bring in the entire language. If I'm not using the language directly, > why do I need that? How this could be achieved, have no idea, erlang > core perhaps... perhaps it's more complicated than that... > > > -- > > Bryan > > > > > >> But if you look at other libraries (or frameworks) such as Raxx > >> (https://github.com/CrowdHailer/raxx), then this is a framework that is > >> fully written in Elixir, yet usable from Erlang (there's a demo at > >> https://github.com/CrowdHailer/greetings-ace-raxx-erlang-example). > >> Similarly, a library such as https://github.com/ericmj/decimal for > >> arbitrary precision arithmetic should be fine to use. > >> > >> This stuff has been available to rebar3 users since around late 2018, so > >> I assume it has seen slow adoption due to its being rather new, but we > >> (rebar3 maintainers) are confident that this bigger interplay is worth > >> it and should be seeing adoption over time. > >> > >> Finally, the stuff we're setting up with the Erlang Ecosystem Foundation > >> is also aimed at making language interplay easier for all languages of > >> the ecosystem. > > This would be great > > > > /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- _________________ Devon Estes 203.559.0323 www.devonestes.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Sun Mar 24 20:09:04 2019 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Sun, 24 Mar 2019 20:09:04 +0100 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> <20190324125410.GD2243@ferdmbp.local> <80fac090-3af7-ea24-01fb-37233af7628d@pobox.com> Message-ID: > What if it was allowed for package maintainers to publish pre-compiled BEAM files to Hex? I would imagine that everyone who is pushing packages to Hex also has the ability to compile those packages on the machine they?re using to publish. Unfortunately that wouldn't solve the issue with macros, because macros are still compiled to regular BEAMs. A precompiled BEAM wouldn't change the module name nor the name of a function. The incompatibility is in the calling convention and in the different ASTs (similar issue to LFE). I feel there are some things that could be done from the Elixir side to make things easier (it could maybe ship with a parse_transform?) but I feel that, for full convenience, (small) changes would need to be done to Erlang too, such as allowing ? and ! at the end of atoms without quoting (note: I am not proposing it, just commenting on it). Unfortunately, on the topic of macros, I can't see them working from Erlang at all. But I don't consider it a bad thing. Well-designed libraries should use macros just a thin layer on top of a proper functional APIs. For example, the macro layer in Plug is very thin and it should be relatively straight-forward to write your own plug web apps in Erlang. But I also feel that even if we somehow port the Plug macro conveniences to Erlang, people won't enjoy using it if you have to write things such as 'Elixir.Plug':send_resp(...). Maybe if we overcome the initial awkwardness which is the different namespace rules, there will be a growing interest in solving those problems. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sun Mar 24 20:10:26 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 24 Mar 2019 15:10:26 -0400 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> <20190324125410.GD2243@ferdmbp.local> Message-ID: <20190324191025.GE2243@ferdmbp.local> On 03/24, Joe Armstrong wrote: > >Interesting - I'd imagined that after compilation you'd just end up >with beam code files after which you could call them from Erlang ... > >Could this be rectified by a "better" macro processor for erlang - more >in the style of the Elixir macro processor ??? > That could be a thing, but currently Erlang's parse transforms do not allow anyone to add any new syntactic element. You can essentially only overload and change the meaning of existing Erlang: you can decide that `case ... of ... end` changes meaning, but you can't add `custom ... end` or anything of that kind. So if you look at an ecto query such as: def with_minimum(age, height_ft) do from u in "users", where: u.age > ^age and u.height > ^(height_ft * 3.28), select: u.name end You could write an Erlang version that does this through list comprehension: with_minimum(Age, HeightFt) -> query([U || U#{age := UAge, height := Height <- "users", UAge > Age, Height > HeightFt*3.23]) (which is essentially what QLC does http://erlang.org/doc/man/qlc.html) Or one using functions: with_minimum(Age, HeightFt) -> from(U, "users", where(Maps:get(age, U) > Age, maps:get(height, U) > HeightFt * 3.28), select(U, name)). and just overloading the hell of whatever functions mean. But you can't introduce any new syntax. From t@REDACTED Sun Mar 24 20:50:55 2019 From: t@REDACTED (Tristan Sloughter) Date: Sun, 24 Mar 2019 15:50:55 -0400 Subject: [erlang-questions] =?utf-8?q?Elixir_community=2C_please_be_more_r?= =?utf-8?q?esponsible=3B_Erlang_community=2C_please_demand_it=2E?= In-Reply-To: References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> <20190324125410.GD2243@ferdmbp.local> <80fac090-3af7-ea24-01fb-37233af7628d@pobox.com> Message-ID: <9422d910-3e35-46cb-ab9b-8731832bb863@www.fastmail.com> On Sun, Mar 24, 2019, at 13:09, Jos? Valim wrote: > > What if it was allowed for package maintainers to publish pre-compiled BEAM files to Hex? I would imagine that everyone who is pushing packages to Hex also has the ability to compile those packages on the machine they?re using to publish. > > Unfortunately that wouldn't solve the issue with macros, because macros are still compiled to regular BEAMs. A precompiled BEAM wouldn't change the module name nor the name of a function. The incompatibility is in the calling convention and in the different ASTs (similar issue to LFE). It would solve the issue of if I created an Erlang lib and depend on an Elixir lib I'm forcing any user of my lib to perform a step outside of the build tool after depending on it (installing Elixir). Benchee itself this isn't an issue for in my opinion. Since it is used for benchmarking and wouldn't be a regular dependency, but only required for those working directly on the application and running benchmarks, requiring an external dependency isn't unusual. I've been planning to try Benchee out for some Erlang projects and just haven't gotten around to it yet. Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.r.nohl@REDACTED Sun Mar 24 22:00:21 2019 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Sun, 24 Mar 2019 22:00:21 +0100 Subject: [erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it. In-Reply-To: References: <90af3ede-a4fa-9ccd-224f-a9fc6bc09c78@pobox.com> <1E2B4E3F-AAC9-4360-A6FB-3E50F0A26BF2@riseup.net> <70bb8ca0-71e5-8ea5-de07-2b0e43afdf48@pobox.com> <2bee3bf5-1d2e-5baf-c628-6895424764b2@pobox.com> <20190324125410.GD2243@ferdmbp.local> <80fac090-3af7-ea24-01fb-37233af7628d@pobox.com> Message-ID: Hello! Calling Elixir from Erlang is similar problem to calling C++ from C. Possible? In certain cases: yes, I've done that, the (mangled) function name looks ugly - but there's no way to instantiate C++ templates from C as the C compiler has no idea about them. Similarly the Erlang compiler has no idea about Elixir macros. However, I have an even crazier idea: rebar, mix, hex, etc. know only about (some of the) BEAM-using languages. But we live in multilingual times, so a project might use other languages (especially JavaScript) too. Wouldn't it be cool if a single tool could manage those dependencies, maybe even generate Erlang/Elixir server code and JavaScript client code from the interface description... I feel like reinventing CORBA and its IDL :-) Devon Estes ezt ?rta (id?pont: 2019. m?rc. 24., V, 19:46): > What if it was allowed for package maintainers to publish pre-compiled > BEAM files to Hex? I would imagine that everyone who is pushing packages to > Hex also has the ability to compile those packages on the machine they?re > using to publish. > > There are clearly a whole ton of reasons why that could be a bad idea (and > probably wouldn?t even work for a large chunk of macro-heavy Elixir > libraries that rely on Mix configuration to be present at compile time), > but it would also make for the easiest story for cross-language library > sharing. > > It pushes the compilation step from the user of a package to the > maintainer of that package, but if CLI tools knew where to put these > pre-compiled BEAM files so users didn?t have to think about it, then it > could make usage of some libraries much easier. > > It could be an optional thing for those maintainers who want to go the > extra mile to make cross-language use of their packages easier. I know I?d > be happy to take that extra step when publishing new versions of Benchee if > it meant Erlang/LFE/etc. users could have an easier time using it. > > Or it could just make everything worse and more complicated ?? but it > seemed like it was worth bringing up. > > Bryan Paxton schrieb am So. 24. M?rz 2019 um 17:50: > >> >> On 3/24/19 11:26 AM, Joe Armstrong wrote: >> > On Sun, Mar 24, 2019 at 1:54 PM Fred Hebert wrote: >> >> On 03/24, Joe Armstrong wrote: >> >>> I for one welcome all the things the Elixir folks are doing - but I >> >>> have noticed the following: >> >>> >> >>> - Elixir folks are re-using Erlang libraries >> >>> - Erlang folks are not (it seems to me) reusing Elixir libraries >> >>> >> >>> The "how to call Erlang from Elixir" documentation is great - the >> >>> opposite "how to call Elixir from Elixir" is not (or have I missed >> something) >> >>> >> >>> Things like nerves, scenic, Phoenix etc. look great to me - but seem >> to be used >> >>> almost exclusively by Elixir folks. >> >>> >> >>> Has anybody made, for example, a pure Erlang interface to scenic? >> >>> >> >> Well, there are some limitations there. >> >> >> >> - You can use mix to build your Erlang project and then use Elixir in >> >> there >> >> - You can use rebar3 with the rebar_mix plugin (along with an Elixir >> >> install) to build Elixir dependencies (see >> >> https://github.com/tsloughter/rebar_mix) >> >> >> >> But in all cases, you will not necessarily be able to use Elixir code >> >> when it heavily relies on macros at the call-site rather than >> >> internally. So for example, a lot of usage of _plugs_ in Phoenix rely >> on >> >> macros running within the controller compilation step to read the >> >> declaration and inline them "somewhere??" with no obvious way to do it >> >> without the macros. >> >> >> >> That specific stuff that relies on macros in _your Elixir code_ cannot >> >> be ported to work with _your Erlang code_, because, well, we don't have >> >> the same macro mechanisms available. Similarly, Erlang parse transforms >> >> may not remain fully applicable to Elixir modules in the future. >> >> >> >> This means that Ecto, which is a huge part of a lot of web framework >> >> usage, also won't be usable for Erlang users, since it is very >> >> macro-dependent. >> > Interesting - I'd imagined that after compilation you'd just end up >> > with beam code files after which you could call them from Erlang ... >> > >> > Could this be rectified by a "better" macro processor for erlang - more >> > in the style of the Elixir macro processor ??? >> >> >> I'd like to add on top of this the smallest part of the problem, but >> what I see as a problem none the less... >> >> 'ManyWouldPrefer':'not_to_have_to_do_this?'(Please) >> >> >> As stated, smallest of all the problems, but whether we like it or not >> UX matters. This not only applies to using Elixir but LFE, etc. The >> only solutions to that problem that I could think of involve perhaps too >> much trickery, not really sure how the community feels about said >> trickery though. That is to say, to squash this problem effectively >> you'd have to translate/generate modules in other BEAM languages to pure >> erlang (or generate pure erlang interfaces), prefix the module names >> with 'elixir_' or 'lfe_' and then hack the compiler, shell, etc. to >> treat this as special so that in the end we would be using >> many_would_prefer:not_to_have_to_do_this(Please). Or instead of said >> trickery, elixir_many_would_prefer:not_to_have_to_do_this(Please). >> >> This brings me to another point and something I didn't understand until >> recently. Yes, with the rebar_mix plugin and so forth you end up using >> the artifact (beam file) compiled by the given beam language. As Tristan >> said, this requires you to have Elixir installed... it's not that big of >> a deal perhaps... but say you would simply like to bring in emj's >> Decimal lib as pointed out by Tristan... Do you really want to bring in >> all of Elixir just to use said lib? It seems a bit much. This is >> precisely why I "ported" Elixir's Version module to pure Erlang. Now, >> you don't need to bring in Elixir to use a fully compatible semver >> lib... but it's wrong... I felt bad in doing it... there is now more >> code in the world and that's the last thing we need. >> >> What I want (dreams and wishes): >> >> Universal BEAM/Erlang libs. It would be the bees knees and a HUGE win >> for the entire community for all to seamlessly be able use erlang, >> elixir, lfe, without having to >> bring in the entire language. If I'm not using the language directly, >> why do I need that? How this could be achieved, have no idea, erlang >> core perhaps... perhaps it's more complicated than that... >> >> >> -- >> >> Bryan >> >> >> > >> >> But if you look at other libraries (or frameworks) such as Raxx >> >> (https://github.com/CrowdHailer/raxx), then this is a framework that >> is >> >> fully written in Elixir, yet usable from Erlang (there's a demo at >> >> https://github.com/CrowdHailer/greetings-ace-raxx-erlang-example). >> >> Similarly, a library such as https://github.com/ericmj/decimal for >> >> arbitrary precision arithmetic should be fine to use. >> >> >> >> This stuff has been available to rebar3 users since around late 2018, >> so >> >> I assume it has seen slow adoption due to its being rather new, but we >> >> (rebar3 maintainers) are confident that this bigger interplay is worth >> >> it and should be seeing adoption over time. >> >> >> >> Finally, the stuff we're setting up with the Erlang Ecosystem >> Foundation >> >> is also aimed at making language interplay easier for all languages of >> >> the ecosystem. >> > This would be great >> > >> > /Joe >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- > > _________________ > Devon Estes > 203.559.0323 > www.devonestes.com > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Mon Mar 25 04:58:40 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Mon, 25 Mar 2019 16:58:40 +1300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: Take this as a code smell. There is probably an abstraction missing in your data struc On Sat, 23 Mar 2019 at 20:40, Florent Gallaire wrote: > Hello everybody, > > I'm not very experimented in Erlang but I read carefully books and > official documention. > > It seems to me that the guards syntax is not as good as it should be, > i.e. too much verbose for multiple values. > > do(val1) -> val1; > do(val2) -> val2; > do(val3) -> val3; > do(val4) -> val4; > do(val5) -> val5. > > do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > Val =:= val5 -> Val. > > It's boring and error prone to write. > > Has a "in tuple" syntax already be considered ? Something like : > > do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > > Cheers > > Florent > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Mon Mar 25 05:32:20 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Mon, 25 Mar 2019 17:32:20 +1300 Subject: [erlang-questions] netmap, UDP, and Erlang Message-ID: I need to do some load testing between two machines; the protocol is an astronomy protocol layered over UDP and the data rate is higher than anything I've had my hands on before. The system is going to be Ubuntu 18 LTS and while *eventually* there is going to be a custom FPGA between the line and the CPU it would be nice to use something other than Python or C++ for prototyping. 1. Does netmap live up to its promise? 2. Are there there any issues installing it on Ubuntu 18? 3. Has anyone used this with Erlang/got any necessary glue code? If this is a bad idea, I'd find it helpful to be told why. "A little learning is a dangerous thing" and I am wary of the Dunning-Kruger effect. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgallaire@REDACTED Mon Mar 25 01:34:04 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Mon, 25 Mar 2019 01:34:04 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: Frank thanks for your answer. > You?re probably new to Erlang. Yes, but... > You can achieve the same with parse_transform: > https://github.com/mad-cocktail/gin/blob/master/README.rst ...I can say parse_transform is not the solution Erlang needs. > There?s no point to add new syntax to the language. Yes we need it, an easy to use built-in "in (tuple or list I'm not sure of the right semantic)" syntactic sugar for guards. Hope some other advices. Florent > /Frank > >> Hello everybody, >> >> I'm not very experimented in Erlang but I read carefully books and >> official documention. >> >> It seems to me that the guards syntax is not as good as it should be, >> i.e. too much verbose for multiple values. >> >> do(val1) -> val1; >> do(val2) -> val2; >> do(val3) -> val3; >> do(val4) -> val4; >> do(val5) -> val5. >> >> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; >> Val =:= val5 -> Val. >> >> It's boring and error prone to write. >> >> Has a "in tuple" syntax already be considered ? Something like : >> >> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. >> >> Cheers >> >> Florent >> >> -- >> FLOSS Engineer & Lawyer >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- FLOSS Engineer & Lawyer From raoknz@REDACTED Mon Mar 25 07:32:56 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Mon, 25 Mar 2019 19:32:56 +1300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: lists:member(X, [X1,X2,X3,X4]) answers true or false. There is no fundamental reason that the compiler could not expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) when the shape of the list is known. So we *definitely* need no new syntax. However, I must repeat that if this happens often enough in your code to be "boring" you need to give serious thought to changing your data structure. Things that share a processing path should be given a common structure. We really need an actual concrete example of real code to discuss. On Mon, 25 Mar 2019 at 18:12, Florent Gallaire wrote: > Frank thanks for your answer. > > > You?re probably new to Erlang. > > Yes, but... > > > You can achieve the same with parse_transform: > > https://github.com/mad-cocktail/gin/blob/master/README.rst > > ...I can say parse_transform is not the solution Erlang needs. > > > There?s no point to add new syntax to the language. > > Yes we need it, an easy to use built-in "in (tuple or list I'm not > sure of the right semantic)" syntactic sugar for guards. > > Hope some other advices. > > Florent > > > /Frank > > > >> Hello everybody, > >> > >> I'm not very experimented in Erlang but I read carefully books and > >> official documention. > >> > >> It seems to me that the guards syntax is not as good as it should be, > >> i.e. too much verbose for multiple values. > >> > >> do(val1) -> val1; > >> do(val2) -> val2; > >> do(val3) -> val3; > >> do(val4) -> val4; > >> do(val5) -> val5. > >> > >> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > >> Val =:= val5 -> Val. > >> > >> It's boring and error prone to write. > >> > >> Has a "in tuple" syntax already be considered ? Something like : > >> > >> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > >> > >> Cheers > >> > >> Florent > >> > >> -- > >> FLOSS Engineer & Lawyer > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan.hunt@REDACTED Mon Mar 25 12:50:11 2019 From: bryan.hunt@REDACTED (Bryan Hunt) Date: Mon, 25 Mar 2019 11:50:11 +0000 Subject: [erlang-questions] Guards syntax for multiple values Message-ID: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Pretty easy to do with Elixir - also runs on beam and is a bit more expressive e.g. iex(1)> "foo" in ["foo","bar"] true iex(4)> defmodule T do ...(4)> def f(x) when x in ["foo","bar"] do ...(4)> true ...(4)> end ...(4)> def f(x), do: false ...(4)> end warning: variable "x" is unused (if the variable is not meant to be used, prefix it with an underscore) iex:8 {:module, T, <<70, 79, 82, 49, 0, 0, 4, 100, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 128, 0, 0, 0, 15, 8, 69, 108, 105, 120, 105, 114, 46, 84, 8, 95, 95, 105, 110, 102, 111, 95, 95, 7, 99, 111, 109, 112, ...>>, {:f, 1}} iex(5)> T.f f/1 iex(5)> T.f("bar") true iex(6)> T.f("baz") false -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgallaire@REDACTED Mon Mar 25 13:38:11 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Mon, 25 Mar 2019 13:38:11 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: Hello Richard, Thanks for your answer. > lists:member(X, [X1,X2,X3,X4]) answers true or false. > There is no fundamental reason that the compiler could not > expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) > when the shape of the list is known. So we *definitely* need > no new syntax. So if there's no reason the compiler could not do it, we *really* should have a new syntax. > We really need an actual concrete example of real code to discuss. The developed version of the is_fraction/1 function: is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction($?) -> true; is_fraction(_) -> false. The awful actual "with a guard" version: is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; is_fraction(_) -> false. The pretty, easy and obviously needed "with in list syntactic sugar" version : is_fraction(X) when X in "??????????????????" -> true; is_fraction(_) -> false. It clearly speaks for itself. Cheers. > On Mon, 25 Mar 2019 at 18:12, Florent Gallaire wrote: >> >> Frank thanks for your answer. >> >> > You?re probably new to Erlang. >> >> Yes, but... >> >> > You can achieve the same with parse_transform: >> > https://github.com/mad-cocktail/gin/blob/master/README.rst >> >> ...I can say parse_transform is not the solution Erlang needs. >> >> > There?s no point to add new syntax to the language. >> >> Yes we need it, an easy to use built-in "in (tuple or list I'm not >> sure of the right semantic)" syntactic sugar for guards. >> >> Hope some other advices. >> >> Florent >> >> > /Frank >> > >> >> Hello everybody, >> >> >> >> I'm not very experimented in Erlang but I read carefully books and >> >> official documention. >> >> >> >> It seems to me that the guards syntax is not as good as it should be, >> >> i.e. too much verbose for multiple values. >> >> >> >> do(val1) -> val1; >> >> do(val2) -> val2; >> >> do(val3) -> val3; >> >> do(val4) -> val4; >> >> do(val5) -> val5. >> >> >> >> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; >> >> Val =:= val5 -> Val. >> >> >> >> It's boring and error prone to write. >> >> >> >> Has a "in tuple" syntax already be considered ? Something like : >> >> >> >> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. >> >> >> >> Cheers >> >> >> >> Florent >> >> >> >> -- >> >> FLOSS Engineer & Lawyer >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> -- >> FLOSS Engineer & Lawyer >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- FLOSS Engineer & Lawyer From elbrujohalcon@REDACTED Mon Mar 25 13:49:31 2019 From: elbrujohalcon@REDACTED (Brujo Benavides) Date: Mon, 25 Mar 2019 09:49:31 -0300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: Hey Florent, Why not just? is_fraction(X) -> lists:member(X, "???????????????????). Or, if you really really want to use function clause heads, pattern-matching and guards: is_fraction(X) when $? =< X =< $? -> true; is_fraction(X) when $? =< X <= $? -> true; is_fraction(_) -> false. For these kinds of character manipulation things, using the fact that they?re just integers under-the-hood is not a bad idea. Cheers! Brujo Benavides > On 25 Mar 2019, at 09:38, Florent Gallaire wrote: > > Hello Richard, > > Thanks for your answer. > >> lists:member(X, [X1,X2,X3,X4]) answers true or false. >> There is no fundamental reason that the compiler could not >> expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) >> when the shape of the list is known. So we *definitely* need >> no new syntax. > > So if there's no reason the compiler could not do it, we *really* > should have a new syntax. > >> We really need an actual concrete example of real code to discuss. > > The developed version of the is_fraction/1 function: > > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction(_) -> false. > > The awful actual "with a guard" version: > > is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; > is_fraction(_) -> false. > > The pretty, easy and obviously needed "with in list syntactic sugar" version : > > is_fraction(X) when X in "??????????????????" -> true; > is_fraction(_) -> false. > > It clearly speaks for itself. > > Cheers. > >> On Mon, 25 Mar 2019 at 18:12, Florent Gallaire wrote: >>> >>> Frank thanks for your answer. >>> >>>> You?re probably new to Erlang. >>> >>> Yes, but... >>> >>>> You can achieve the same with parse_transform: >>>> https://github.com/mad-cocktail/gin/blob/master/README.rst >>> >>> ...I can say parse_transform is not the solution Erlang needs. >>> >>>> There?s no point to add new syntax to the language. >>> >>> Yes we need it, an easy to use built-in "in (tuple or list I'm not >>> sure of the right semantic)" syntactic sugar for guards. >>> >>> Hope some other advices. >>> >>> Florent >>> >>>> /Frank >>>> >>>>> Hello everybody, >>>>> >>>>> I'm not very experimented in Erlang but I read carefully books and >>>>> official documention. >>>>> >>>>> It seems to me that the guards syntax is not as good as it should be, >>>>> i.e. too much verbose for multiple values. >>>>> >>>>> do(val1) -> val1; >>>>> do(val2) -> val2; >>>>> do(val3) -> val3; >>>>> do(val4) -> val4; >>>>> do(val5) -> val5. >>>>> >>>>> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; >>>>> Val =:= val5 -> Val. >>>>> >>>>> It's boring and error prone to write. >>>>> >>>>> Has a "in tuple" syntax already be considered ? Something like : >>>>> >>>>> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. >>>>> >>>>> Cheers >>>>> >>>>> Florent >>>>> >>>>> -- >>>>> FLOSS Engineer & Lawyer >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >>> -- >>> FLOSS Engineer & Lawyer >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgallaire@REDACTED Mon Mar 25 14:12:58 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Mon, 25 Mar 2019 14:12:58 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: Hello Brujo, Thanks for your answer. > Why not just? > > is_fraction(X) -> lists:member(X, "???????????????????). Because it's not possible: "illegal guard expression". > Or, if you really really want to use function clause heads, pattern-matching and guards: > > is_fraction(X) when $? =< X =< $? -> true; > is_fraction(X) when $? =< X <= $? -> true; > is_fraction(_) -> false. > > For these kinds of character manipulation things, using the fact that they?re just integers under-the-hood is not a bad idea. Yes you're right in this case, but it remains a trick so most of the time it's not applicable. Cheers > Cheers! > > ________________________________ > Brujo Benavides > > > > On 25 Mar 2019, at 09:38, Florent Gallaire wrote: > > Hello Richard, > > Thanks for your answer. > > lists:member(X, [X1,X2,X3,X4]) answers true or false. > There is no fundamental reason that the compiler could not > expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) > when the shape of the list is known. So we *definitely* need > no new syntax. > > > So if there's no reason the compiler could not do it, we *really* > should have a new syntax. > > We really need an actual concrete example of real code to discuss. > > > The developed version of the is_fraction/1 function: > > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction(_) -> false. > > The awful actual "with a guard" version: > > is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; > is_fraction(_) -> false. > > The pretty, easy and obviously needed "with in list syntactic sugar" version : > > is_fraction(X) when X in "??????????????????" -> true; > is_fraction(_) -> false. > > It clearly speaks for itself. > > Cheers. > > On Mon, 25 Mar 2019 at 18:12, Florent Gallaire wrote: > > > Frank thanks for your answer. > > You?re probably new to Erlang. > > > Yes, but... > > You can achieve the same with parse_transform: > https://github.com/mad-cocktail/gin/blob/master/README.rst > > > ...I can say parse_transform is not the solution Erlang needs. > > There?s no point to add new syntax to the language. > > > Yes we need it, an easy to use built-in "in (tuple or list I'm not > sure of the right semantic)" syntactic sugar for guards. > > Hope some other advices. > > Florent > > /Frank > > Hello everybody, > > I'm not very experimented in Erlang but I read carefully books and > official documention. > > It seems to me that the guards syntax is not as good as it should be, > i.e. too much verbose for multiple values. > > do(val1) -> val1; > do(val2) -> val2; > do(val3) -> val3; > do(val4) -> val4; > do(val5) -> val5. > > do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > Val =:= val5 -> Val. > > It's boring and error prone to write. > > Has a "in tuple" syntax already be considered ? Something like : > > do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > > Cheers > > Florent > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- FLOSS Engineer & Lawyer From elbrujohalcon@REDACTED Mon Mar 25 14:18:22 2019 From: elbrujohalcon@REDACTED (Brujo Benavides) Date: Mon, 25 Mar 2019 10:18:22 -0300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: <1F9285B6-8A54-4B6C-A796-F6CC1C0F305D@gmail.com> Well on the first example, there are no guards. I pretty much doubt that there is an illegal guard expression there :P But the code was poorly written, I grant you that. I fixed it (and i actually checked that it compiled this time): is_fraction(X) -> lists:member(X, "??????????????????"). is_fraction_with_guards(X) when $? =< X, X =< $? -> true; is_fraction_with_guards(X) when $? =< X, X =< $? -> true; is_fraction_with_guards(_) -> false. Brujo Benavides > On 25 Mar 2019, at 10:12, Florent Gallaire wrote: > > Hello Brujo, > > Thanks for your answer. > >> Why not just? >> >> is_fraction(X) -> lists:member(X, "???????????????????). > > Because it's not possible: "illegal guard expression". > >> Or, if you really really want to use function clause heads, pattern-matching and guards: >> >> is_fraction(X) when $? =< X =< $? -> true; >> is_fraction(X) when $? =< X <= $? -> true; >> is_fraction(_) -> false. >> >> For these kinds of character manipulation things, using the fact that they?re just integers under-the-hood is not a bad idea. > > Yes you're right in this case, but it remains a trick so most of the > time it's not applicable. > > Cheers > >> Cheers! >> >> ________________________________ >> Brujo Benavides >> >> >> >> On 25 Mar 2019, at 09:38, Florent Gallaire wrote: >> >> Hello Richard, >> >> Thanks for your answer. >> >> lists:member(X, [X1,X2,X3,X4]) answers true or false. >> There is no fundamental reason that the compiler could not >> expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) >> when the shape of the list is known. So we *definitely* need >> no new syntax. >> >> >> So if there's no reason the compiler could not do it, we *really* >> should have a new syntax. >> >> We really need an actual concrete example of real code to discuss. >> >> >> The developed version of the is_fraction/1 function: >> >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction(_) -> false. >> >> The awful actual "with a guard" version: >> >> is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; >> X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; >> X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; >> is_fraction(_) -> false. >> >> The pretty, easy and obviously needed "with in list syntactic sugar" version : >> >> is_fraction(X) when X in "??????????????????" -> true; >> is_fraction(_) -> false. >> >> It clearly speaks for itself. >> >> Cheers. >> >> On Mon, 25 Mar 2019 at 18:12, Florent Gallaire wrote: >> >> >> Frank thanks for your answer. >> >> You?re probably new to Erlang. >> >> >> Yes, but... >> >> You can achieve the same with parse_transform: >> https://github.com/mad-cocktail/gin/blob/master/README.rst >> >> >> ...I can say parse_transform is not the solution Erlang needs. >> >> There?s no point to add new syntax to the language. >> >> >> Yes we need it, an easy to use built-in "in (tuple or list I'm not >> sure of the right semantic)" syntactic sugar for guards. >> >> Hope some other advices. >> >> Florent >> >> /Frank >> >> Hello everybody, >> >> I'm not very experimented in Erlang but I read carefully books and >> official documention. >> >> It seems to me that the guards syntax is not as good as it should be, >> i.e. too much verbose for multiple values. >> >> do(val1) -> val1; >> do(val2) -> val2; >> do(val3) -> val3; >> do(val4) -> val4; >> do(val5) -> val5. >> >> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; >> Val =:= val5 -> Val. >> >> It's boring and error prone to write. >> >> Has a "in tuple" syntax already be considered ? Something like : >> >> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. >> >> Cheers >> >> Florent >> >> -- >> FLOSS Engineer & Lawyer >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> FLOSS Engineer & Lawyer >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> FLOSS Engineer & Lawyer >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > FLOSS Engineer & Lawyer -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgallaire@REDACTED Mon Mar 25 15:00:54 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Mon, 25 Mar 2019 15:00:54 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <1F9285B6-8A54-4B6C-A796-F6CC1C0F305D@gmail.com> References: <1F9285B6-8A54-4B6C-A796-F6CC1C0F305D@gmail.com> Message-ID: > Well on the first example, there are no guards. I pretty much doubt that there is an illegal guard expression there :P Yes excuse me for my wrong sentence. I was talking about lists:member/2 in a guard: is_fraction(X) when lists:member(X, "??????????????????") -> true. which is not possible. is_fraction(X) -> lists:member(X, "??????????????????"). is not good for me because you can't combine with other tests and only can return true. So I really think Erlang need the "in list" syntax for guards. Florent > But the code was poorly written, I grant you that. I fixed it (and i actually checked that it compiled this time): > > is_fraction(X) -> lists:member(X, "??????????????????"). > > is_fraction_with_guards(X) when $? =< X, X =< $? -> true; > is_fraction_with_guards(X) when $? =< X, X =< $? -> true; > is_fraction_with_guards(_) -> false. > > ________________________________ > Brujo Benavides > > > > On 25 Mar 2019, at 10:12, Florent Gallaire wrote: > > Hello Brujo, > > Thanks for your answer. > > Why not just? > > is_fraction(X) -> lists:member(X, "???????????????????). > > > Because it's not possible: "illegal guard expression". > > Or, if you really really want to use function clause heads, pattern-matching and guards: > > is_fraction(X) when $? =< X =< $? -> true; > is_fraction(X) when $? =< X <= $? -> true; > is_fraction(_) -> false. > > For these kinds of character manipulation things, using the fact that they?re just integers under-the-hood is not a bad idea. > > > Yes you're right in this case, but it remains a trick so most of the > time it's not applicable. > > Cheers > > Cheers! > > ________________________________ > Brujo Benavides > > > > On 25 Mar 2019, at 09:38, Florent Gallaire wrote: > > Hello Richard, > > Thanks for your answer. > > lists:member(X, [X1,X2,X3,X4]) answers true or false. > There is no fundamental reason that the compiler could not > expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) > when the shape of the list is known. So we *definitely* need > no new syntax. > > > So if there's no reason the compiler could not do it, we *really* > should have a new syntax. > > We really need an actual concrete example of real code to discuss. > > > The developed version of the is_fraction/1 function: > > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction(_) -> false. > > The awful actual "with a guard" version: > > is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; > is_fraction(_) -> false. > > The pretty, easy and obviously needed "with in list syntactic sugar" version : > > is_fraction(X) when X in "??????????????????" -> true; > is_fraction(_) -> false. > > It clearly speaks for itself. > > Cheers. > > On Mon, 25 Mar 2019 at 18:12, Florent Gallaire wrote: > > > Frank thanks for your answer. > > You?re probably new to Erlang. > > > Yes, but... > > You can achieve the same with parse_transform: > https://github.com/mad-cocktail/gin/blob/master/README.rst > > > ...I can say parse_transform is not the solution Erlang needs. > > There?s no point to add new syntax to the language. > > > Yes we need it, an easy to use built-in "in (tuple or list I'm not > sure of the right semantic)" syntactic sugar for guards. > > Hope some other advices. > > Florent > > /Frank > > Hello everybody, > > I'm not very experimented in Erlang but I read carefully books and > official documention. > > It seems to me that the guards syntax is not as good as it should be, > i.e. too much verbose for multiple values. > > do(val1) -> val1; > do(val2) -> val2; > do(val3) -> val3; > do(val4) -> val4; > do(val5) -> val5. > > do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > Val =:= val5 -> Val. > > It's boring and error prone to write. > > Has a "in tuple" syntax already be considered ? Something like : > > do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > > Cheers > > Florent > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > FLOSS Engineer & Lawyer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > FLOSS Engineer & Lawyer > > -- FLOSS Engineer & Lawyer From elbrujohalcon@REDACTED Mon Mar 25 15:07:27 2019 From: elbrujohalcon@REDACTED (Brujo Benavides) Date: Mon, 25 Mar 2019 11:07:27 -0300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <1F9285B6-8A54-4B6C-A796-F6CC1C0F305D@gmail.com> Message-ID: Sorry Florent, but I don?t understand what you can?t combine with other tests and only can return true means in this context. In any case, if your situation involves more context than just is_fraction/1, it would be nice if you could provide it so others can really understand the problem you?re facing (i.e. as Richard put it: We really need an actual concrete example of real code to discuss). Cheers! Brujo Benavides > On 25 Mar 2019, at 11:00, Florent Gallaire wrote: > >> Well on the first example, there are no guards. I pretty much doubt that there is an illegal guard expression there :P > > Yes excuse me for my wrong sentence. I was talking about > lists:member/2 in a guard: > is_fraction(X) when lists:member(X, "??????????????????") -> true. > which is not possible. > > is_fraction(X) -> lists:member(X, "??????????????????"). > is not good for me because you can't combine with other tests and only > can return true. > > So I really think Erlang need the "in list" syntax for guards. > > Florent > >> But the code was poorly written, I grant you that. I fixed it (and i actually checked that it compiled this time): >> >> is_fraction(X) -> lists:member(X, "??????????????????"). >> >> is_fraction_with_guards(X) when $? =< X, X =< $? -> true; >> is_fraction_with_guards(X) when $? =< X, X =< $? -> true; >> is_fraction_with_guards(_) -> false. >> >> ________________________________ >> Brujo Benavides >> >> >> >> On 25 Mar 2019, at 10:12, Florent Gallaire wrote: >> >> Hello Brujo, >> >> Thanks for your answer. >> >> Why not just? >> >> is_fraction(X) -> lists:member(X, "???????????????????). >> >> >> Because it's not possible: "illegal guard expression". >> >> Or, if you really really want to use function clause heads, pattern-matching and guards: >> >> is_fraction(X) when $? =< X =< $? -> true; >> is_fraction(X) when $? =< X <= $? -> true; >> is_fraction(_) -> false. >> >> For these kinds of character manipulation things, using the fact that they?re just integers under-the-hood is not a bad idea. >> >> >> Yes you're right in this case, but it remains a trick so most of the >> time it's not applicable. >> >> Cheers >> >> Cheers! >> >> ________________________________ >> Brujo Benavides >> >> >> >> On 25 Mar 2019, at 09:38, Florent Gallaire wrote: >> >> Hello Richard, >> >> Thanks for your answer. >> >> lists:member(X, [X1,X2,X3,X4]) answers true or false. >> There is no fundamental reason that the compiler could not >> expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) >> when the shape of the list is known. So we *definitely* need >> no new syntax. >> >> >> So if there's no reason the compiler could not do it, we *really* >> should have a new syntax. >> >> We really need an actual concrete example of real code to discuss. >> >> >> The developed version of the is_fraction/1 function: >> >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction(_) -> false. >> >> The awful actual "with a guard" version: >> >> is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; >> X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; >> X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; >> is_fraction(_) -> false. >> >> The pretty, easy and obviously needed "with in list syntactic sugar" version : >> >> is_fraction(X) when X in "??????????????????" -> true; >> is_fraction(_) -> false. >> >> It clearly speaks for itself. >> >> Cheers. >> >> On Mon, 25 Mar 2019 at 18:12, Florent Gallaire wrote: >> >> >> Frank thanks for your answer. >> >> You?re probably new to Erlang. >> >> >> Yes, but... >> >> You can achieve the same with parse_transform: >> https://github.com/mad-cocktail/gin/blob/master/README.rst >> >> >> ...I can say parse_transform is not the solution Erlang needs. >> >> There?s no point to add new syntax to the language. >> >> >> Yes we need it, an easy to use built-in "in (tuple or list I'm not >> sure of the right semantic)" syntactic sugar for guards. >> >> Hope some other advices. >> >> Florent >> >> /Frank >> >> Hello everybody, >> >> I'm not very experimented in Erlang but I read carefully books and >> official documention. >> >> It seems to me that the guards syntax is not as good as it should be, >> i.e. too much verbose for multiple values. >> >> do(val1) -> val1; >> do(val2) -> val2; >> do(val3) -> val3; >> do(val4) -> val4; >> do(val5) -> val5. >> >> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; >> Val =:= val5 -> Val. >> >> It's boring and error prone to write. >> >> Has a "in tuple" syntax already be considered ? Something like : >> >> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. >> >> Cheers >> >> Florent >> >> -- >> FLOSS Engineer & Lawyer >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> FLOSS Engineer & Lawyer >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> FLOSS Engineer & Lawyer >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> FLOSS Engineer & Lawyer >> >> > > > -- > FLOSS Engineer & Lawyer -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Mar 25 15:27:19 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Mon, 25 Mar 2019 15:27:19 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: <5bb22839-4460-1860-8dd0-e8097b2e84d5@ninenines.eu> I would second this. It would be great to be able to say "when Val in [a, b, c]" and that be translated to "when Val =:= a; Val =:= b; Val =:= c" automatically. It's just nicer to read and write. And since strings are lists this would also work: 'when Val in "=!~._-"'. I have a lot of HTTP parsing code that would benefit from such a construct. I suppose "when Val in [a, b, c], Flag =:= true" would have to be translated as "Val =:= a, Flag =:= true; Val =:= b, Flag =:= true; Val =:= c, Flag =:= true" as well, due to how ;/, work in guards. Cheers, On 23/03/2019 04:24, Florent Gallaire wrote: > Hello everybody, > > I'm not very experimented in Erlang but I read carefully books and > official documention. > > It seems to me that the guards syntax is not as good as it should be, > i.e. too much verbose for multiple values. > > do(val1) -> val1; > do(val2) -> val2; > do(val3) -> val3; > do(val4) -> val4; > do(val5) -> val5. > > do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > Val =:= val5 -> Val. > > It's boring and error prone to write. > > Has a "in tuple" syntax already be considered ? Something like : > > do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > > Cheers > > Florent > -- Lo?c Hoguin https://ninenines.eu From jesper.louis.andersen@REDACTED Mon Mar 25 16:30:52 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 25 Mar 2019 16:30:52 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <5bb22839-4460-1860-8dd0-e8097b2e84d5@ninenines.eu> References: <5bb22839-4460-1860-8dd0-e8097b2e84d5@ninenines.eu> Message-ID: An alternative notation is that of or-patterns. Here from OCaml: type foo = A | B | C | D let is_frac x = match x with A | B | C -> true | _ -> false Abusing erlang notation, you would write something like is_frac(a); is_frac(b); is_frac(c) -> true; is_frac(_) -> false. for this variant. As for a hint why you would prefer an or-pattern over list membership in a typed language, consider the compilation of let is_frac x = match x with A | B | C | D -> true | _ -> false This returns a warning: "Warning 11: this match case is unused." because the latter wildcard match on _ can never be reached. On Mon, Mar 25, 2019 at 3:27 PM Lo?c Hoguin wrote: > I would second this. It would be great to be able to say "when Val in > [a, b, c]" and that be translated to "when Val =:= a; Val =:= b; Val =:= > c" automatically. It's just nicer to read and write. > > And since strings are lists this would also work: 'when Val in > "=!~._-"'. I have a lot of HTTP parsing code that would benefit from > such a construct. > > I suppose "when Val in [a, b, c], Flag =:= true" would have to be > translated as "Val =:= a, Flag =:= true; Val =:= b, Flag =:= true; Val > =:= c, Flag =:= true" as well, due to how ;/, work in guards. > > Cheers, > > On 23/03/2019 04:24, Florent Gallaire wrote: > > Hello everybody, > > > > I'm not very experimented in Erlang but I read carefully books and > > official documention. > > > > It seems to me that the guards syntax is not as good as it should be, > > i.e. too much verbose for multiple values. > > > > do(val1) -> val1; > > do(val2) -> val2; > > do(val3) -> val3; > > do(val4) -> val4; > > do(val5) -> val5. > > > > do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > > Val =:= val5 -> Val. > > > > It's boring and error prone to write. > > > > Has a "in tuple" syntax already be considered ? Something like : > > > > do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > > > > Cheers > > > > Florent > > > > -- > Lo?c Hoguin > https://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2QdxY4RzWzUUiLuE@REDACTED Mon Mar 25 16:50:46 2019 From: 2QdxY4RzWzUUiLuE@REDACTED (Dan Sommers) Date: Mon, 25 Mar 2019 10:50:46 -0500 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <1F9285B6-8A54-4B6C-A796-F6CC1C0F305D@gmail.com> Message-ID: <5b359d99-fb02-8df0-b729-364c713bb8f9@potatochowder.com> On 3/25/19 9:00 AM, Florent Gallaire wrote: > Yes excuse me for my wrong sentence. I was talking about > lists:member/2 in a guard: > is_fraction(X) when lists:member(X, "??????????????????") -> true. > which is not possible. http://erlang.org/doc/reference_manual/expressions.html#guard-sequences explains The set of valid guard expressions (sometimes called guard tests) is a subset of the set of valid Erlang expressions. The reason for restricting the set of valid expressions is that evaluation of a guard expression must be guaranteed to be free of side effects. Valid guard expressions are the following: and later on, there's a list of "blessed" functions that are allowed in guard expressions. My experience with Erlang is entirely as a hobbyist, but what are the pros, cons, and possibilities of expanding the list of such "blessed" functions? Many of the functions in the list module have no side effects, and could make some Erlang code more concise. That said, I've also discovered (or more likely rediscovered) that breaking down such functions and guard clauses one more layer also leads to more concise code. I don't know Florent's use case, but I could imagine breaking it down one more level into something like this: process(X) -> Classification = classify(X), process(X, Classification). process(X, fraction) -> %% process fractions here ok; process(X, url_character) -> %% process URL characters here ok; process(X, whitespace) -> %% process whitespace here ok; process(X, UnknownClassification) -> %% handle an unknown X here ok. Or maybe all that does is push the problem into the implementation of classify/1. From powers_brady@REDACTED Mon Mar 25 17:48:51 2019 From: powers_brady@REDACTED (Brady Powers) Date: Mon, 25 Mar 2019 16:48:51 +0000 (UTC) Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <5b359d99-fb02-8df0-b729-364c713bb8f9@potatochowder.com> References: <1F9285B6-8A54-4B6C-A796-F6CC1C0F305D@gmail.com> <5b359d99-fb02-8df0-b729-364c713bb8f9@potatochowder.com> Message-ID: <1285082746.10695040.1553532531131@mail.yahoo.com> I personally have always wanted to see it possible to specify certain functions as "pure" so that they can be used in a guard.? I understand why using any random function in a guard is a bad idea. But some ability to override should be possible, even if it emitted a warning of some sort.? Typically, I've seen patterns like so when needing to use a custom function in a guard: ``` function(X) -> ? ? case custom_guard(X) of ? ? ? ? true -> function_guarded(X) ? ? end. ``` While a terrible example, the point is there are ways to work around it, and sometimes people have to work around it. So the restriction is bypassed anyway, surely there is a way to dissuade people from using any function in a guard, but allowing people to carefully write a function that would be guard safe. Parse transforms can be way more dangerous, and yet we still allow them, and their use is certainly dissuaded.? Personally, I think just marking a function as "pure" should be enough to allow it in a guard, possibly with a warning. No need to auto-detect what functions are pure or not, though possibly we could double check the "pure" functions to verify they only call out to the current "blessed" functions and others marked as "pure".? On Monday, March 25, 2019, 11:51:04 AM EDT, Dan Sommers <2QdxY4RzWzUUiLuE@REDACTED> wrote: On 3/25/19 9:00 AM, Florent Gallaire wrote: > Yes excuse me for my wrong sentence. I was talking about > lists:member/2 in a guard: > is_fraction(X) when lists:member(X, "??????????????????") -> true. > which is not possible. http://erlang.org/doc/reference_manual/expressions.html#guard-sequences explains ? ? The set of valid guard expressions (sometimes called guard tests) is ? ? a subset of the set of valid Erlang expressions. The reason for ? ? restricting the set of valid expressions is that evaluation of a ? ? guard expression must be guaranteed to be free of side ? ? effects. Valid guard expressions are the following: and later on, there's a list of "blessed" functions that are allowed in guard expressions. My experience with Erlang is entirely as a hobbyist, but what are the pros, cons, and possibilities of expanding the list of such "blessed" functions?? Many of the functions in the list module have no side effects, and could make some Erlang code more concise. That said, I've also discovered (or more likely rediscovered) that breaking down such functions and guard clauses one more layer also leads to more concise code.? I don't know Florent's use case, but I could imagine breaking it down one more level into something like this: process(X) -> ? ? Classification = classify(X), ? ? process(X, Classification). process(X, fraction) -> ? ? %% process fractions here ? ? ok; process(X, url_character) -> ? ? %% process URL characters here ? ? ok; process(X, whitespace) -> ? ? %% process whitespace here ? ? ok; process(X, UnknownClassification) -> ? ? %% handle an unknown X here ? ? ok. Or maybe all that does is push the problem into the implementation of classify/1. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgallaire@REDACTED Mon Mar 25 18:03:22 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Mon, 25 Mar 2019 18:03:22 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: Hello Bryan, thanks for your answer. Indeed it's very intersting to note that the only thing added to Erlang guards when designing Elixir has been this "in list" (and "not in") operator. For people who don't know about Elixir, it's a BEAM based programming language with a tremondous succes. All (alive) programming languages are evolving influenced by others, Erlang evolve too, even for syntactic sugar, and it's GOOD. For reasons of taste, I prefer Erlang over Elixir, and my "in list" operator need comes obviously from my important Python experience. As Lo?c said "It's just nicer to read and write", it's just better for beginnings, and so better for any programmers, and so better for Erlang. Cheers Le lun. 25 mars 2019 ? 12:50, Bryan Hunt a ?crit : > > Pretty easy to do with Elixir - also runs on beam and is a bit more expressive e.g. > > iex(1)> "foo" in ["foo","bar"] > true > iex(4)> defmodule T do > ...(4)> def f(x) when x in ["foo","bar"] do > ...(4)> true > ...(4)> end > ...(4)> def f(x), do: false > ...(4)> end > warning: variable "x" is unused (if the variable is not meant to be used, prefix it with an underscore) > iex:8 > > {:module, T, > <<70, 79, 82, 49, 0, 0, 4, 100, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 128, > 0, 0, 0, 15, 8, 69, 108, 105, 120, 105, 114, 46, 84, 8, 95, 95, 105, 110, > 102, 111, 95, 95, 7, 99, 111, 109, 112, ...>>, {:f, 1}} > iex(5)> T.f > f/1 > iex(5)> T.f("bar") > true > iex(6)> T.f("baz") > false > > -- FLOSS Engineer & Lawyer From mononcqc@REDACTED Mon Mar 25 18:19:55 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 25 Mar 2019 13:19:55 -0400 Subject: [erlang-questions] Travis issues while searching for lager In-Reply-To: References: <20190323141612.GC2243@ferdmbp.local> Message-ID: <20190325171952.GF2243@ferdmbp.local> On 03/25, Caragea Silviu wrote: >Hello Fred, > >Any idea what's be best way to do this in travis config ? > >Maybe to add a copy of rebar3 into my repo and run this when compile ? > There are two options. To run the newest rebar3 possible, rather than checking rebar3 into your repository permanently, you can just use the S3 link for it and do something like curl https://s3.amazonaws.com/rebar3/rebar3 && chmod +x rebar3 And then call ./rebar3 in your commands for S3. If you cache the ~/.cache directory, you may want to also call ./rebar3 update. If the objective is to lock the plugin, you can force-specify a version for the plugin on your own terms ({project_plugins, [{Plugin, Version}]} -- here I use project_plugins because it will _not_ be fetched by parent projects when you put yours as a dependency) Those are all options that are nicer than checking in (and downloading) rebar3 for each project that exists. From mononcqc@REDACTED Mon Mar 25 18:28:12 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 25 Mar 2019 13:28:12 -0400 Subject: [erlang-questions] netmap, UDP, and Erlang In-Reply-To: References: Message-ID: <20190325172811.GG2243@ferdmbp.local> On 03/25, Richard O'Keefe wrote: >I need to do some load testing between two machines; >the protocol is an astronomy protocol layered over UDP >and the data rate is higher than anything I've had my >hands on before. The system is going to be Ubuntu 18 LTS >and while *eventually* there is going to be a custom FPGA >between the line and the CPU it would be nice to use >something other than Python or C++ for prototyping. I've been on a team that has experimented with netmap on both FreeBSD and Linux (Ubuntu) for UDP traffic handling, although that code base was mostly maintained in C++ itself rather than Erlang (the latter was used to manage the C++ code, among other things). > >1. Does netmap live up to its promise? Yes. It's pretty damn fast compared to all other alternatives we'd had looked into at the time, although there are some different alternatives on Linux that we have not tried. >2. Are there there any issues installing it on > Ubuntu 18? Mostly FreeBSD was really nice with it since it shipped with the kernel module required for netmap. Linux, by comparison, required the compilation of custom kernel modules, which became rather painful. Every time we wanted to upgrade the linux kernel, we also had to recompile all modules, which made for very complex upgrade sequences for devices in the field. >3. Has anyone used this with Erlang/got any necessary > glue code? > Unfortunately not; all of it was private, and only talked to Erlang through more isolated mechanisms than NIFs or anything of the kind. >If this is a bad idea, >I'd find it helpful to be told why. >"A little learning is a dangerous thing" >and I am wary of the Dunning-Kruger effect. The big problem is really the poor support for netmap to be built as a kernel module on Ubuntu. Otherwise it works. Other things to look into might be those named at https://lwn.net/Articles/719850/ -- namely af_packet which I heard should be easier to deal with, but have no experience with. Maybe things changed since then, but those were the last echoes I had heard about it all. From mark.geib.44@REDACTED Mon Mar 25 18:47:04 2019 From: mark.geib.44@REDACTED (Mark Geib) Date: Mon, 25 Mar 2019 11:47:04 -0600 Subject: [erlang-questions] no logger output using ?LOG macros in release Message-ID: <4D844006-52F5-4A37-8CD8-15108720E84D@gmail.com> I have a problem where I see no logger output in a release built with rebar3 using the new ?LOG macros. If I use the logger: functions everything is working fine. Decided to change to use the macros in order to get able to include MFA, line number, etc. in templates. Also, doing a dev release build and then running interactively everything works fine with the ?LOG macros. It?s like the prod builds are missing something compared to dev build. Thanks in advance for any help. Mark. From jesper.louis.andersen@REDACTED Mon Mar 25 19:02:58 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 25 Mar 2019 19:02:58 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: On Mon, Mar 25, 2019 at 6:03 PM Florent Gallaire wrote: > For reasons of taste, I prefer Erlang over Elixir, and my "in list" > operator need comes obviously from my important Python experience. > > Thinking out loud, I think it might be beneficial to look at two additions: lists:member - because length(..) is in the set of Valid GuardSeqs and is O(n) maps:is_key maps:get The latter map variants are arguably even stronger since they have good lookup time, even for very large maps. Writing maps:is_key(X, #{ a => true, b => true }) should be fast and since it is a literal, it can be optimized in a number of ways by the compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From silviu.cpp@REDACTED Mon Mar 25 19:27:01 2019 From: silviu.cpp@REDACTED (Caragea Silviu) Date: Mon, 25 Mar 2019 20:27:01 +0200 Subject: [erlang-questions] Travis issues while searching for lager In-Reply-To: <20190325171952.GF2243@ferdmbp.local> References: <20190323141612.GC2243@ferdmbp.local> <20190325171952.GF2243@ferdmbp.local> Message-ID: Awesome, thanks! Have a nice day, Silviu On Mon, Mar 25, 2019 at 7:19 PM Fred Hebert wrote: > On 03/25, Caragea Silviu wrote: > >Hello Fred, > > > >Any idea what's be best way to do this in travis config ? > > > >Maybe to add a copy of rebar3 into my repo and run this when compile ? > > > > There are two options. To run the newest rebar3 possible, rather than > checking rebar3 into your repository permanently, you can just use the > S3 link for it and do something like > > curl https://s3.amazonaws.com/rebar3/rebar3 && chmod +x rebar3 > > And then call ./rebar3 in your commands for S3. If you cache the > ~/.cache directory, you may want to also call ./rebar3 update. > > If the objective is to lock the plugin, you can force-specify a version > for the plugin on your own terms ({project_plugins, [{Plugin, Version}]} > -- here I use project_plugins because it will _not_ be fetched by parent > projects when you put yours as a dependency) > > > Those are all options that are nicer than checking in (and downloading) > rebar3 for each project that exists. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob01@REDACTED Mon Mar 25 20:02:51 2019 From: jacob01@REDACTED (Jacob) Date: Mon, 25 Mar 2019 20:02:51 +0100 Subject: [erlang-questions] netmap, UDP, and Erlang In-Reply-To: <20190325172811.GG2243@ferdmbp.local> References: <20190325172811.GG2243@ferdmbp.local> Message-ID: <8e5cae73-9828-6a32-259b-c291a64cbc67@gmx.net> Hi, On 3/25/19 6:28 PM, Fred Hebert wrote: > > The big problem is really the poor support for netmap to be built as a > kernel module on Ubuntu. Otherwise it works. > Other things to look into might be those named at > https://lwn.net/Articles/719850/ -- namely af_packet which I heard > should be easier to deal with, but have no experience with. In a former (Linux/C++ based)? product we have used the pcap library to analyse high volume video data (TCP) on the fly which in turn used AF_PACKET with the memory mapped ring buffer feature enabled. This has worked without issues (as long as you don't reference the data in the buffer too long) and relatively low system load and successfully prevented us from using netmap. Unfortunately this didn't involve Erlang and I cannot provide more details, since this was about 6 years ago and I no longer have access to the code. HTH Jacob From mononcqc@REDACTED Mon Mar 25 20:32:46 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 25 Mar 2019 15:32:46 -0400 Subject: [erlang-questions] no logger output using ?LOG macros in release In-Reply-To: <4D844006-52F5-4A37-8CD8-15108720E84D@gmail.com> References: <4D844006-52F5-4A37-8CD8-15108720E84D@gmail.com> Message-ID: See if you are using any log formatters or handlers -- those may not be direct dependencies of your application, and therefore do not get included in the final release. You will need to add these dependencies to the release independently so that they are present to run and handle output. The rebar3 shell and other interactive modes can dynamically load libraries from disk and won't show that little gotcha at all. On Mon, Mar 25, 2019 at 1:47 PM Mark Geib wrote: > I have a problem where I see no logger output in a release built with > rebar3 using the new ?LOG macros. If I use the logger: functions > everything is working fine. Decided to change to use the macros in order > to get able to include MFA, line number, etc. in templates. > > Also, doing a dev release build and then running interactively everything > works fine with the ?LOG macros. It?s like the > prod builds are missing something compared to dev build. > > Thanks in advance for any help. > > Mark. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Mon Mar 25 20:35:39 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 25 Mar 2019 15:35:39 -0400 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: On Mon, Mar 25, 2019 at 2:03 PM Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > Thinking out loud, I think it might be beneficial to look at two additions: > > lists:member - because length(..) is in the set of Valid GuardSeqs and is > O(n) > maps:is_key > maps:get > > The latter map variants are arguably even stronger since they have good > lookup time, even for very large maps. Writing maps:is_key(X, #{ a => true, > b => true }) should be fast and since it is a literal, it can be optimized > in a number of ways by the compiler. > > OTP-21 includes the new BIFs erlang:map_get(Key, Map) and erlang:map_size(Map) for these reasons. Only lists:member is missing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.geib.44@REDACTED Mon Mar 25 20:41:20 2019 From: mark.geib.44@REDACTED (Mark Geib) Date: Mon, 25 Mar 2019 13:41:20 -0600 Subject: [erlang-questions] no logger output using ?LOG macros in release In-Reply-To: References: <4D844006-52F5-4A37-8CD8-15108720E84D@gmail.com> Message-ID: <4A390CA2-C06C-4D99-81D4-2C02576E6BD9@gmail.com> I am using the default handler and formatter, i.e.: [{handler, default, logger_disk_log_h, % handler, HandlerId, Module, #{config => #{file => "/var/log/asp2aj/erlang.log", type => wrap, max_no_files => 10, max_no_bytes => 1000000000}, formatter => {logger_formatter, #{single_line => true, template => [time," ",mfa,":",line," ",pid," [",level,"] ",msg,"\n"]}}} }] And my logging works fine previously when I was doing logger:info()... Thanks, Mark. > On Mar 25, 2019, at 1:32 PM, Fred Hebert wrote: > > See if you are using any log formatters or handlers -- those may not be direct dependencies of your application, and therefore do not get included in the final release. You will need to add these dependencies to the release independently so that they are present to run and handle output. > > The rebar3 shell and other interactive modes can dynamically load libraries from disk and won't show that little gotcha at all. > > On Mon, Mar 25, 2019 at 1:47 PM Mark Geib > wrote: > I have a problem where I see no logger output in a release built with rebar3 using the new ?LOG macros. If I use the logger: functions > everything is working fine. Decided to change to use the macros in order to get able to include MFA, line number, etc. in templates. > > Also, doing a dev release build and then running interactively everything works fine with the ?LOG macros. It?s like the > prod builds are missing something compared to dev build. > > Thanks in advance for any help. > > Mark. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Mar 25 20:42:41 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 25 Mar 2019 20:42:41 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: On Mon, Mar 25, 2019 at 8:36 PM Fred Hebert wrote: > > OTP-21 includes the new BIFs erlang:map_get(Key, Map) and > erlang:map_size(Map) for these reasons. Only lists:member is missing. > Indeed! Though the documentation doesn't have them as "Allowed in guard tests". We can live without is_key, if we just test against true for now. I tried looking it up and the documentation didn't have them as allowed. But perhaps the code actually allows them if I just tried doing it? -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve@REDACTED Mon Mar 25 20:44:11 2019 From: steve@REDACTED (Steve Strong) Date: Mon, 25 Mar 2019 19:44:11 +0000 Subject: [erlang-questions] no logger output using ?LOG macros in release In-Reply-To: <4A390CA2-C06C-4D99-81D4-2C02576E6BD9@gmail.com> References: <4D844006-52F5-4A37-8CD8-15108720E84D@gmail.com> <4A390CA2-C06C-4D99-81D4-2C02576E6BD9@gmail.com> Message-ID: <0DDBE35D-7988-4C80-B0B8-5EC574C53218@srstrong.com> Do you have the logger_level value set in your sys.config (or are you setting it in code)? The ?LOG macros check that before logging? -define(DO_LOG(Level,Args), case logger:allow(Level,?MODULE) of true -> apply(logger,macro_log,[?LOCATION,Level|Args]); false -> ok end). -endif. Cheers, Steve > On 25 Mar 2019, at 19:41, Mark Geib wrote: > > I am using the default handler and formatter, i.e.: > > [{handler, default, logger_disk_log_h, % handler, HandlerId, Module, > #{config => #{file => "/var/log/asp2aj/erlang.log", type => wrap, max_no_files => 10, max_no_bytes => 1000000000}, > formatter => {logger_formatter, #{single_line => true, template => [time," ",mfa,":",line," ",pid," [",level,"] ",msg,"\n"]}}} > }] > > > And my logging works fine previously when I was doing logger:info()... > > Thanks, > Mark. > > >> On Mar 25, 2019, at 1:32 PM, Fred Hebert > wrote: >> >> See if you are using any log formatters or handlers -- those may not be direct dependencies of your application, and therefore do not get included in the final release. You will need to add these dependencies to the release independently so that they are present to run and handle output. >> >> The rebar3 shell and other interactive modes can dynamically load libraries from disk and won't show that little gotcha at all. >> >> On Mon, Mar 25, 2019 at 1:47 PM Mark Geib > wrote: >> I have a problem where I see no logger output in a release built with rebar3 using the new ?LOG macros. If I use the logger: functions >> everything is working fine. Decided to change to use the macros in order to get able to include MFA, line number, etc. in templates. >> >> Also, doing a dev release build and then running interactively everything works fine with the ?LOG macros. It?s like the >> prod builds are missing something compared to dev build. >> >> Thanks in advance for any help. >> >> Mark. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.geib.44@REDACTED Mon Mar 25 20:49:03 2019 From: mark.geib.44@REDACTED (Mark Geib) Date: Mon, 25 Mar 2019 13:49:03 -0600 Subject: [erlang-questions] no logger output using ?LOG macros in release In-Reply-To: <0DDBE35D-7988-4C80-B0B8-5EC574C53218@srstrong.com> References: <4D844006-52F5-4A37-8CD8-15108720E84D@gmail.com> <4A390CA2-C06C-4D99-81D4-2C02576E6BD9@gmail.com> <0DDBE35D-7988-4C80-B0B8-5EC574C53218@srstrong.com> Message-ID: <300A54A3-A6FB-4DD7-AE28-BB9898AB2D79@gmail.com> Yes, here is the bottom of my sys.config. {kernel, [{logger_level, info}, {logger, [{handler, default, logger_disk_log_h, #{config => #{file => "/var/log/asp2aj/erlang.log", type => wrap, max_no_files => 10, max_no_bytes => 1000000000}, formatter => {logger_formatter, #{single_line => true, template => [time," ",mfa,":",line," ",pid," [",level,"] ",msg,"\n"]}}} }] }] }]. Mark. > On Mar 25, 2019, at 1:44 PM, Steve Strong wrote: > > Do you have the logger_level value set in your sys.config (or are you setting it in code)? The ?LOG macros check that before logging? > > -define(DO_LOG(Level,Args), > case logger:allow(Level,?MODULE) of > true -> > apply(logger,macro_log,[?LOCATION,Level|Args]); > false -> > ok > end). > -endif. > > Cheers, > > Steve > >> On 25 Mar 2019, at 19:41, Mark Geib > wrote: >> >> I am using the default handler and formatter, i.e.: >> >> [{handler, default, logger_disk_log_h, % handler, HandlerId, Module, >> #{config => #{file => "/var/log/asp2aj/erlang.log", type => wrap, max_no_files => 10, max_no_bytes => 1000000000}, >> formatter => {logger_formatter, #{single_line => true, template => [time," ",mfa,":",line," ",pid," [",level,"] ",msg,"\n"]}}} >> }] >> >> >> And my logging works fine previously when I was doing logger:info()... >> >> Thanks, >> Mark. >> >> >>> On Mar 25, 2019, at 1:32 PM, Fred Hebert > wrote: >>> >>> See if you are using any log formatters or handlers -- those may not be direct dependencies of your application, and therefore do not get included in the final release. You will need to add these dependencies to the release independently so that they are present to run and handle output. >>> >>> The rebar3 shell and other interactive modes can dynamically load libraries from disk and won't show that little gotcha at all. >>> >>> On Mon, Mar 25, 2019 at 1:47 PM Mark Geib > wrote: >>> I have a problem where I see no logger output in a release built with rebar3 using the new ?LOG macros. If I use the logger: functions >>> everything is working fine. Decided to change to use the macros in order to get able to include MFA, line number, etc. in templates. >>> >>> Also, doing a dev release build and then running interactively everything works fine with the ?LOG macros. It?s like the >>> prod builds are missing something compared to dev build. >>> >>> Thanks in advance for any help. >>> >>> Mark. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe@REDACTED Mon Mar 25 17:28:30 2019 From: joe@REDACTED (joe mcguckin) Date: Mon, 25 Mar 2019 09:28:30 -0700 Subject: [erlang-questions] Erlang questions Message-ID: <058C994C-4568-4774-82CF-93EE88F98DFB@via.net> What?s the main difference between Erlang & Elixir? What web framework is popular with Erlang? Just as a toy app for learning a bit of both languages I want to implement a URL shortner. Something a little bit more complicated than ?Hello World!?. Does a CPU with more cores tend to handle more of a load? If so, it seems to me that a multi-socket RYZEN platform ought to be a good choice. Also, I saw a talk given by someone from WhatApp and he mentioned that they had a lot of internal BEAM fixes for performance speedups. Does anyone know if those fixes have been merged back into the public sources? Thanks, Joe Joe McGuckin ViaNet Communications joe@REDACTED 650-207-0372 cell 650-213-1302 office 650-969-2124 fax From raoknz@REDACTED Tue Mar 26 07:42:31 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Tue, 26 Mar 2019 19:42:31 +1300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: I must repeat, we do not need any new syntax. We just need the special case of lists:member/2 with a fixed-length list argument to be accepted in a guard. This is a relatively minor change to the compiler. If any syntactic extension were involved, SML/NJ allows (P1 | ... | Pn) anywhere that a pattern is allowed. However, this particular example strikes me as a perfect example of something that should NOT repeat NOT be done by pattern matching. Why? Because "does this codepoint represent a vulgar fraction in Unicode" is not a question with a fixed answer. Unicode keeps on growing. The *right* question is "does codepoint X represent a vulgar fraction in Unicode version Y", and you not only do not want to express that kind of thing in code, you don't want to, because Unicode keeps on growing, new versions keep on coming out. You want to be able to load a new Unicode Data release *without* rewriting your Erlang code. Alternativey, this appears to be an excellent example of code that should be *generated*, not *written*, and who cares how hard the compiler has to work? On Tue, 26 Mar 2019 at 08:43, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > > On Mon, Mar 25, 2019 at 8:36 PM Fred Hebert wrote: > >> >> OTP-21 includes the new BIFs erlang:map_get(Key, Map) and >> erlang:map_size(Map) for these reasons. Only lists:member is missing. >> > > Indeed! Though the documentation doesn't have them as "Allowed in guard > tests". We can live without is_key, if we just test against true for now. I > tried looking it up and the documentation didn't have them as allowed. But > perhaps the code actually allows them if I just tried doing it? > > > > -- > J. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Tue Mar 26 07:52:41 2019 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Tue, 26 Mar 2019 07:52:41 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: The concern I have with adding lists:member/2 and similar to guards is that adds an exception to the language, since all guards today exist in the "erlang" module. If lists:member/2 is allowed in guards, why not the other functions in lists? There are also other implementation differences, such as the fact guards are not traceable and all BIFs are. That's not to say a new syntax is needed. For example, a new function could be added to erlang such as lists_member or is_member. I believe those reasons are what caused erlang:map_get/2 to be added instead of allowing maps:get/2 in guards. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Tue Mar 26 08:53:05 2019 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 26 Mar 2019 08:53:05 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: On Mon, Mar 25, 2019 at 7:03 PM Jesper Louis Andersen wrote: > Thinking out loud, I think it might be beneficial to look at two additions: > > lists:member - because length(..) is in the set of Valid GuardSeqs and is O(n) lists:member/2 has always been problematic because it's O(n). The way guard and guard BIFs are implemented (for efficiency), guard BIFs can't yield during execution. In OTP 22 we finally fixed that issue by implementing special instructions for executing length/1: https://github.com/erlang/otp/pull/2053 Because of the effort required to make length/1 yielding, it is unlikely that we will ever introduce another guard BIF with O(n) or worse complexity. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From essen@REDACTED Tue Mar 26 09:08:31 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 26 Mar 2019 09:08:31 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: On 26/03/2019 08:53, Bj?rn Gustavsson wrote: > On Mon, Mar 25, 2019 at 7:03 PM Jesper Louis Andersen > wrote: >> Thinking out loud, I think it might be beneficial to look at two additions: >> >> lists:member - because length(..) is in the set of Valid GuardSeqs and is O(n) > > lists:member/2 has always been problematic because it's O(n). The way > guard and guard BIFs are implemented (for efficiency), guard BIFs > can't yield during execution. > > In OTP 22 we finally fixed that issue by implementing special > instructions for executing length/1: > > https://github.com/erlang/otp/pull/2053 > > Because of the effort required to make length/1 yielding, it is > unlikely that we will ever introduce another guard BIF with O(n) or > worse complexity. What about compiler trickery, as mentioned earlier in the thread? Either allowing 'lists:member(Var, )' or 'Var in ' and rewriting this at compile time as a more verbose series of =:= tests and/or separate clauses? This would fit a lot of use cases. -- Lo?c Hoguin https://ninenines.eu From frank.muller.erl@REDACTED Tue Mar 26 09:15:00 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Tue, 26 Mar 2019 09:15:00 +0100 Subject: [erlang-questions] msacc 21.3.2 Message-ID: Hi guys msacc:print/1 is showing me that all my dirty_io_shed are busy 100% (sleep column at 0.0%). The vm is using more and more RAM. How can I identify the issue? /Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Tue Mar 26 09:41:10 2019 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 26 Mar 2019 09:41:10 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: On Tue, Mar 26, 2019 at 9:08 AM Lo?c Hoguin wrote: > What about compiler trickery, as mentioned earlier in the thread? Either > allowing 'lists:member(Var, )' or 'Var in ' > and rewriting this at compile time as a more verbose series of =:= tests > and/or separate clauses? This would fit a lot of use cases. Yes, that would work. As long as the list is a literal, the compiler can rewrite it in a smarter way to reduce the complexity to O(log(N)), which would be acceptable. As Jos? pointed out, all guard BIFs are currently in the Erlang module. So most likely there would be a new guard BIF in the erlang module called is_member/2 or lists_member/2. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From z@REDACTED Tue Mar 26 09:46:28 2019 From: z@REDACTED (Danil Zagoskin) Date: Tue, 26 Mar 2019 11:46:28 +0300 Subject: [erlang-questions] msacc 21.3.2 In-Reply-To: References: Message-ID: Hi Frank! First, which OTP version are you using? Second, try that on a fresh minor release ? some scheduler issues were fixed recently. Third, try rebuilding OTP with ./configure --with-microstate-accounting=extra and check what are these schedulers doing (which columns have the most %) This could give some more valuable info. Also you may check which processes are using lots of scheduler time. Try using etop. After you find troubled processes, you may use fprof to determine which functions are slow. In simple case you can just see that in process_info(Pid, current_stacktrace). Good luck! On Tue, Mar 26, 2019 at 11:15 AM Frank Muller wrote: > Hi guys > > msacc:print/1 is showing me that all my dirty_io_shed are busy 100% (sleep > column at 0.0%). > > The vm is using more and more RAM. > > How can I identify the issue? > > /Frank > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Tue Mar 26 10:43:29 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Tue, 26 Mar 2019 10:43:29 +0100 Subject: [erlang-questions] msacc 21.3.2 In-Reply-To: References: Message-ID: I?m using 21.3.2 (as in the title). My VM is already configured with microstate-accounting=extra The Sleep column for Poll is 99.72% And the Sleep column is the one with more %. The rest of the columns are almost at 0% I?m able to identify which process is using most the scheduler. It?s busy looping on gen_tcp:send calls proxying binary data to other nodes on the system. /Frank Hi Frank! > > First, which OTP version are you using? > Second, try that on a fresh minor release ? some scheduler issues were > fixed recently. > Third, try rebuilding OTP with ./configure > --with-microstate-accounting=extra and > check what are these schedulers doing (which columns have the most %) > > This could give some more valuable info. > > Also you may check which processes are using lots of scheduler time. Try > using etop. > After you find troubled processes, you may use fprof to determine which > functions are slow. In simple case you can just see that in > process_info(Pid, current_stacktrace). > > Good luck! > > On Tue, Mar 26, 2019 at 11:15 AM Frank Muller > wrote: > >> Hi guys >> >> msacc:print/1 is showing me that all my dirty_io_shed are busy 100% >> (sleep column at 0.0%). >> >> The vm is using more and more RAM. >> >> How can I identify the issue? >> >> /Frank >> > _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > >> > > -- > Danil Zagoskin | z@REDACTED > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Tue Mar 26 11:51:03 2019 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 26 Mar 2019 11:51:03 +0100 Subject: [erlang-questions] no logger output using ?LOG macros in release In-Reply-To: <300A54A3-A6FB-4DD7-AE28-BB9898AB2D79@gmail.com> References: <4D844006-52F5-4A37-8CD8-15108720E84D@gmail.com> <4A390CA2-C06C-4D99-81D4-2C02576E6BD9@gmail.com> <0DDBE35D-7988-4C80-B0B8-5EC574C53218@srstrong.com> <300A54A3-A6FB-4DD7-AE28-BB9898AB2D79@gmail.com> Message-ID: Hi Mark, I'm not sure what the difference could be between dev an prod here, but if you can access your node, did you check that the logger configuration is as expected? logger:i() in OTP-21.3, or else logger:get_config(). Just to make sure nothing failed silently during startup. Another thing though - are you using run_erl with your prod release? If so, given the file name specified for the default handler, you must make sure that run_erl does not have the same log directory as you handler, or else they will attempt writing to the same file. logger_disk_log_h has no mechanism to ensure that it's file descriptor is fresh (the inode has not been changed), so if run_erl writes something to the same file, then the next log event from logger_disk_log_h will just disappear :( (logger_std_h has better protection against this, and from OTP-21.3 it also has log rotation.) But this is of course not related to the macros at all, so if everything works ok with logger:info(..) but not with the macro, then there must be something else going on anyway. Regards /siri Den man. 25. mar. 2019 kl. 20:49 skrev Mark Geib : > Yes, here is the bottom of my sys.config. > > {kernel, > [{logger_level, info}, {logger, > [{handler, default, logger_disk_log_h, > #{config => #{file => "/var/log/asp2aj/erlang.log", type => wrap, > max_no_files => 10, max_no_bytes => 1000000000}, > formatter => {logger_formatter, #{single_line => true, template => [time," > ",mfa,":",line," ",pid," [",level,"] ",msg,"\n"]}}} > }] > }] > }]. > > Mark. > > > On Mar 25, 2019, at 1:44 PM, Steve Strong wrote: > > Do you have the logger_level value set in your sys.config (or are you > setting it in code)? The ?LOG macros check that before logging? > > -define(DO_LOG(Level,Args), > case logger:allow(Level,?MODULE) of > true -> > apply(logger,macro_log,[?LOCATION,Level|Args]); > false -> > ok > end). > -endif. > > Cheers, > > Steve > > On 25 Mar 2019, at 19:41, Mark Geib wrote: > > I am using the default handler and formatter, i.e.: > > [{handler, default, logger_disk_log_h, % handler, HandlerId, Module, > #{config => #{file => "/var/log/asp2aj/erlang.log", type => wrap, > max_no_files => 10, max_no_bytes => 1000000000}, > formatter => {logger_formatter, #{single_line => true, template => [time," > ",mfa,":",line," ",pid," [",level,"] ",msg,"\n"]}}} > }] > > > And my logging works fine previously when I was doing logger:info()... > > Thanks, > Mark. > > > On Mar 25, 2019, at 1:32 PM, Fred Hebert wrote: > > See if you are using any log formatters or handlers -- those may not be > direct dependencies of your application, and therefore do not get included > in the final release. You will need to add these dependencies to the > release independently so that they are present to run and handle output. > > The rebar3 shell and other interactive modes can dynamically load > libraries from disk and won't show that little gotcha at all. > > On Mon, Mar 25, 2019 at 1:47 PM Mark Geib wrote: > >> I have a problem where I see no logger output in a release built with >> rebar3 using the new ?LOG macros. If I use the logger: functions >> everything is working fine. Decided to change to use the macros in order >> to get able to include MFA, line number, etc. in templates. >> >> Also, doing a dev release build and then running interactively everything >> works fine with the ?LOG macros. It?s like the >> prod builds are missing something compared to dev build. >> >> Thanks in advance for any help. >> >> Mark. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From z@REDACTED Tue Mar 26 11:53:13 2019 From: z@REDACTED (Danil Zagoskin) Date: Tue, 26 Mar 2019 13:53:13 +0300 Subject: [erlang-questions] msacc 21.3.2 In-Reply-To: References: Message-ID: (inline) On Tue, Mar 26, 2019 at 12:43 PM Frank Muller wrote: > I?m using 21.3.2 (as in the title). My VM is already configured with > microstate-accounting=extra > Sorry, I ignored the title for some reason. > > The Sleep column for Poll is 99.72% > > And the Sleep column is the one with more %. The rest of the columns are > almost at 0% > So, is Sleep 99.72% or 0.0% as in your initial email? > > I?m able to identify which process is using most the scheduler. It?s busy > looping on gen_tcp:send calls proxying binary data to other nodes on the > system. > Does it mean the problem with msacc is solved? > > /Frank > > -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Mar 26 14:44:13 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 26 Mar 2019 14:44:13 +0100 Subject: [erlang-questions] Erlang questions In-Reply-To: <058C994C-4568-4774-82CF-93EE88F98DFB@via.net> References: <058C994C-4568-4774-82CF-93EE88F98DFB@via.net> Message-ID: On Tue, Mar 26, 2019 at 5:42 AM joe mcguckin wrote: > What?s the main difference between Erlang & Elixir? What web framework is > popular with Erlang? > Just as a toy app for learning a bit of both languages I want to > implement a URL shortner. > > Both Erlang and Elixir run on the same Bytecode engine, called BEAM. From a language perspective they are much more alike than they are different. The two main differences, as I see them, are that Elixir has some neat support for protocols; a somewhat bastardized version of what one would call an interface, and is also embracing macros to a much greater extent than typical Erlang code. As for web frameworks, the dominant one on Elixir is Phoenix. On the Erlang side, there is Zotonic, and also n2o. At a lower level, one that could be suitable for a simple URL shortener, you could just use a web server such as cowboy directly. I want to stress these are just what I remember: there are more frameworks out there for Erlang, so do a search. Does a CPU with more cores tend to handle more of a load? If so, it seems > to me that a multi-socket > RYZEN platform ought to be a good choice. > > More cores will not make a single process any faster. But if you have multiple processes, which can all do work at the same time, the VM will start using additional cores. If you have a RYZEN platform with multiple sockets, 128 threads of execution is not that far fetched. You can utilize this, provided you have 128 url shortening requests at the very same time in your system. > Also, I saw a talk given by someone from WhatApp and he mentioned that > they had a lot of internal BEAM fixes > for performance speedups. Does anyone know if those fixes have been merged > back into the public sources? > > Modern BEAM (OTP-21 and later versions) implemented a set of optimizations which has made some of the older WhatsApp changes obsolete. WA still have a set of unique optimizations though. Most notably a way to quickly empty a queue and a way to push a message to the front of the queue. The latter breaks the semantics of Erlang and the message order guarantees, but WA uses it to check for progress in certain core processes, which makes sense. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgallaire@REDACTED Tue Mar 26 15:51:08 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Tue, 26 Mar 2019 15:51:08 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: Hello Bj?rn, thanks a lot for your attention to this thread. > Yes, that would work. As long as the list is a literal, the compiler > can rewrite it in a smarter way to reduce the complexity to O(log(N)), > which would be acceptable. Very happy to hear that it's technicaly feasible and that the complexity is acceptable. > As Jos? pointed out, all guard BIFs are currently in the Erlang > module. So most likely there would be a new guard BIF in the erlang > module called is_member/2 or lists_member/2. Why do you clearly prefer is_member/2 or lists_member/2 to 'Var in ' ? It's also a good opportunity to make Erlang more modern with a sexy syntactic sugar... Cheers > /Bj?rn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- FLOSS Engineer & Lawyer From mononcqc@REDACTED Tue Mar 26 16:15:28 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 26 Mar 2019 11:15:28 -0400 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: On Tue, Mar 26, 2019 at 10:51 AM Florent Gallaire wrote: > It's also a good opportunity to make Erlang more modern with a sexy > syntactic sugar... > > this should be done very carefully. For example, adding the 'in' keyword for 'X in [A,B,C]' syntax will break all existing code out there that uses the word 'in' for a function, including the `queue:in/2` function call in the standard library. That could ripple into inconsiderate breakage in the whole ecosystem. I don't really care if Erlang is sexier if I have to spend 6-12 months updating all the libraries everywhere that depend on the queue module (among other things) just to keep compiling. I'd rather you write slightly less convenient code on your end instead. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth@REDACTED Tue Mar 26 16:47:01 2019 From: kenneth@REDACTED (Kenneth Lundin) Date: Tue, 26 Mar 2019 16:47:01 +0100 Subject: [erlang-questions] Erlang OTP 22.0-rc2 is available for testing! Message-ID: OTP 22 Release Candidate 2 This is the second of three planned release candidates before the OTP 22 release. The intention with this release is to get feedback from our users. All feedback is welcome, even if it is only to say that it works for you, as it lets us know that the release candidate got some testing. Erlang/OTP 22 is a new major release with new features and improvements as well as incompatibilities. Potential Incompatibilities - gen_* behaviours: If logging of the last N messages through sys:log/2,3 is active for the server, this log is included in the terminate report. - reltool: A new element, Opts, can now be included in a rel tuple in the reltool release specific configuration format: {rel, Name, Vsn, RelApps, Opts}. - All external pids/ports/refs created by erlang:list_to_pid and similar functions now compare equal to any other pid/port/ref with same number from that node. - The old legacy erl_interface library is deprecated as of OTP 22, and will be removed in OTP 23. This does not apply to the ei library. - VxWorks is deprecated as of OTP 22 and will be removed in OTP 23. Additional highlights in release candidate 2 - A simple socket API is provided through the socket module. This is a low level API that does *not* replace gen_[tcp|udp|sctp]. It is intended to *eventually* replace the inet driver. It also provides a basic API that facilitates the implementation of other protocols than TCP, UDP and SCTP. Known issues are; No support for the Windows OS (currently), a small term leakage. This feature will be classed as experimental in OTP 22. - ssl: Basic support for TLS 1.3 Server for experimental use. - In OTP 22, HiPE (the native code compiler) is not fully functional. The reasons for this are new BEAM instructions for binary matching that the HiPE native code compiler does not support. If erlc is invoked with the +native option, and if any of the new binary matching instructions are used, the compiler will issue a warning and produce a BEAM file without native code. - erts: Added the NIF function enif_term_type, which helps avoid long sequences of enif_is_xyz by returning the type of the given term. This is especially helpful for NIFs that serialize terms, such as JSON encoders, where it can improve both performance and readability. - crypto: The new hash_info/1 and cipher_info/1 functions returns maps with information about the hash or cipher in the argument. Highlights in release candidate 1 Erts: - Support for Erlang Distribution protocol to split the payload of large signals into several fragments. - ETS option write_concurrency now also effects and improves scalability of ordered_set tables. - The length/1 BIF used to calculate the length of the list in one go without yielding, even if the list was very long. Now it yields when called with long lists. - A new (still experimental) module socket is introduced. It is implemented as a NIF and the idea is that it shall be as "close as possible" to the OS level socket interface. Compiler: - The compiler has been rewritten to internally use an intermediate representation based on Static Single Assignment (SSA). The new intermediate representation makes more optimizations possible. - The binary matching optimizations are now applicable in many more circumstances than before. - Type optimizations are now applied across local function calls, and will remove a lot more redundant type tests than before. - All compiler options that can be given in the source file can now be given in the option list on the command line for erlc. Standard libraries: - Cover now uses the counters module instead of ets for updating counters. The new function cover:local_only/0 allows running Cover in a restricted but faster local-only mode. The increase in speed will vary depending on the type of code being cover-compiled, as an example the compiler test suite runs more than twice as fast with the new Cover. - SSL now uses the new logger API, including log levels and verbose debug logging. For more details see http://erlang.org/download/otp_src_22.0-rc2.readme Pre built versions for Windows can be fetched here: http://erlang.org/download/otp_win32_22.0-rc2.exe http://erlang.org/download/otp_win64_22.0-rc2.exe Online documentation can be browsed here: http://erlang.org/documentation/doc-11.0-rc2/doc The Erlang/OTP source can also be found at GitHub on the official Erlang repository: https://github.com/erlang/otp OTP-22.0-rc2 Thank you for all your contributions! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob01@REDACTED Tue Mar 26 16:50:42 2019 From: jacob01@REDACTED (Jacob) Date: Tue, 26 Mar 2019 16:50:42 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: <07477075-4a8c-3101-885f-0efd54a53d88@gmx.net> On 26.03.19 09:08, Lo?c Hoguin wrote: > > What about compiler trickery, as mentioned earlier in the thread? Either > allowing 'lists:member(Var, )' or 'Var in ' What do you think about using <- instead of introducing a new 'in' operator which might cause clashes with existing code? Okay, in list comprehensions this is not exactly a boolean expression, and a bound var would be shadowed there, but at least that's an existing operator that semantically comes closest somehow (it even looks a little bit like the algebraic 'is element of' operator). The advantage of using a operator is IMO that it is less surprising, if there are restrictions like "only apply this to literal lists", as '++' in pattern has also certain restrictions on the LHS. Is the "" restriction a little bit too strong? Wouldn't "" be sufficient? Jacob > and rewriting this at compile time as a more verbose series of =:= tests > and/or separate clauses? This would fit a lot of use cases. > From eckard.brauer@REDACTED Tue Mar 26 19:24:42 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Tue, 26 Mar 2019 19:24:42 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: <20190326192442.4fd748bb@gmx.de> Am Tue, 26 Mar 2019 11:15:28 -0400 schrieb Fred Hebert : > On Tue, Mar 26, 2019 at 10:51 AM Florent Gallaire > wrote: > > > It's also a good opportunity to make Erlang more modern with a sexy > > syntactic sugar... > > > > > > this should be done very carefully. For example, adding the 'in' > keyword for 'X in [A,B,C]' syntax will break all existing code out > there that uses the word 'in' for a function, including the > `queue:in/2` function call in the standard library. That could ripple > into inconsiderate breakage in the whole ecosystem. I don't really prefer lists_member/2 or is_member/2 over 'X in [A,B,C]' or the other way, but could you please enlight me (rather erlang beginner) about where/why this would break existing code? If we talk about a list as the second/right side arg of 'in', I could think of either having an opening bracket '[' or a variable bound to that list ("when X in List") after the keyword when to be used as a guard, or of '(' when to be used as the abovementioned function call. So for me, that looks rather simple, but as already written, I'd like to further improve knowledge. Thanks in advance Eckard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Digitale Signatur von OpenPGP URL: From dszoboszlay@REDACTED Tue Mar 26 20:37:43 2019 From: dszoboszlay@REDACTED (=?UTF-8?Q?D=C3=A1niel_Szoboszlay?=) Date: Tue, 26 Mar 2019 20:37:43 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <20190326192442.4fd748bb@gmx.de> References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <20190326192442.4fd748bb@gmx.de> Message-ID: You are right that a parser could easily distinguish "X in Y" from "M:in(...)" or even "fun M:in/N" based on the context. The problem, as I see it, is that "X in Y" introduced a new infix operator to the language, while "is_member(X, Y)" does not, it is syntactically just an ordinary function call. The first problem with introducing a new operator is that there are some conventions for operators in Erlang. Like every alphabetic operator is currently a reserved word. So we either break this convention with "in", or we make "in" a reserved word that would break all the existing "M:in(...)" use cases. I like neither of these options. The second problem I see with a new operator is that it would require an update of every tool that parses Erlang code. An Erlang parser is very likely to have a hard-coded list of operators (together with e.g. the precedence order of them), and wouldn't just try to parse any atom as a potential infix operator. On the other hand, a parser may have a hard-coded list of BIF-s that are allowed in a guard, but that's not likely. Most probably it would just accept any function call in a guard position, so going with "is_member/2" or "lists_member/2" would not break a typical parser. Cheers, Daniel On Tue, 26 Mar 2019 at 19:25 Eckard Brauer wrote: > Am Tue, 26 Mar 2019 11:15:28 -0400 > schrieb Fred Hebert : > > > On Tue, Mar 26, 2019 at 10:51 AM Florent Gallaire > > wrote: > > > > > It's also a good opportunity to make Erlang more modern with a sexy > > > syntactic sugar... > > > > > > > > > > this should be done very carefully. For example, adding the 'in' > > keyword for 'X in [A,B,C]' syntax will break all existing code out > > there that uses the word 'in' for a function, including the > > `queue:in/2` function call in the standard library. That could ripple > > into inconsiderate breakage in the whole ecosystem. > > I don't really prefer lists_member/2 or is_member/2 over 'X in [A,B,C]' > or the other way, but could you please enlight me (rather erlang > beginner) about where/why this would break existing code? If we talk > about a list as the second/right side arg of 'in', I could think of > either having an opening bracket '[' or a variable bound to that list > ("when X in List") after the keyword when to be used as a guard, or of > '(' when to be used as the abovementioned function call. So for me, > that looks rather simple, but as already written, I'd like to further > improve knowledge. > > Thanks in advance > Eckard > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eckard.brauer@REDACTED Tue Mar 26 21:41:36 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Tue, 26 Mar 2019 21:41:36 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <20190326192442.4fd748bb@gmx.de> Message-ID: <20190326214136.0ab81bd0@gmx.de> Hello D?niel, thanks for the clarification. See the problems. Best regards / ?dv?z?l?k Eckard Am Tue, 26 Mar 2019 20:37:43 +0100 schrieb D?niel Szoboszlay : > You are right that a parser could easily distinguish "X in Y" from > "M:in(...)" or even "fun M:in/N" based on the context. The problem, > as I see it, is that "X in Y" introduced a new infix operator to the > language, while "is_member(X, Y)" does not, it is syntactically just > an ordinary function call. > > The first problem with introducing a new operator is that there are > some conventions for operators in Erlang. Like every alphabetic > operator is currently a reserved word. So we either break this > convention with "in", or we make "in" a reserved word that would > break all the existing "M:in(...)" use cases. I like neither of these > options. > > The second problem I see with a new operator is that it would require > an update of every tool that parses Erlang code. An Erlang parser is > very likely to have a hard-coded list of operators (together with > e.g. the precedence order of them), and wouldn't just try to parse > any atom as a potential infix operator. On the other hand, a parser > may have a hard-coded list of BIF-s that are allowed in a guard, but > that's not likely. Most probably it would just accept any function > call in a guard position, so going with "is_member/2" or > "lists_member/2" would not break a typical parser. > > Cheers, > Daniel -- :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Digitale Signatur von OpenPGP URL: From be.dmitry@REDACTED Tue Mar 26 23:12:53 2019 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Wed, 27 Mar 2019 09:12:53 +1100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <20190326192442.4fd748bb@gmx.de> Message-ID: <172A51CB-AB25-43B1-9C16-34248BC2CC76@gmail.com> No current code will be broken if an infix 'in' operator is parsed based on context as it's not currently used. If an auto-impotred function 'erlang:is_member' is introduced, the code previously using locally defined function 'is_member' will be broken. If the bif is not auto-imported its usage in guards will be very confusing. All these proposed changes - a new operator, or a new function - to me look as too small changes, not really solving the main problem - absence of convenient and accepted way to metaprogramming. Just have a look how many proposals to Elixir are rejected as almost all of them are implementable using macros. It reminds me all those libraries implementing different improvements to the language like erlando, gin and many others that don't become used much only because parse transforms are not accepted solution to the Erlang language problems. Maybe we should shift our attention from a list of newly added bifs and those suggested to be added to a more generic way to solve these and other similar problems once and for all? On 27 March 2019 06:37:43 GMT+11:00, "D?niel Szoboszlay" wrote: >You are right that a parser could easily distinguish "X in Y" from >"M:in(...)" or even "fun M:in/N" based on the context. The problem, as >I >see it, is that "X in Y" introduced a new infix operator to the >language, >while "is_member(X, Y)" does not, it is syntactically just an ordinary >function call. > >The first problem with introducing a new operator is that there are >some >conventions for operators in Erlang. Like every alphabetic operator is >currently a reserved word. So we either break this convention with >"in", or >we make "in" a reserved word that would break all the existing >"M:in(...)" >use cases. I like neither of these options. > >The second problem I see with a new operator is that it would require >an >update of every tool that parses Erlang code. An Erlang parser is very >likely to have a hard-coded list of operators (together with e.g. the >precedence order of them), and wouldn't just try to parse any atom as a >potential infix operator. On the other hand, a parser may have a >hard-coded >list of BIF-s that are allowed in a guard, but that's not likely. Most >probably it would just accept any function call in a guard position, so >going with "is_member/2" or "lists_member/2" would not break a typical >parser. > >Cheers, >Daniel > >On Tue, 26 Mar 2019 at 19:25 Eckard Brauer >wrote: > >> Am Tue, 26 Mar 2019 11:15:28 -0400 >> schrieb Fred Hebert : >> >> > On Tue, Mar 26, 2019 at 10:51 AM Florent Gallaire >> > wrote: >> > >> > > It's also a good opportunity to make Erlang more modern with a >sexy >> > > syntactic sugar... >> > > >> > > >> > >> > this should be done very carefully. For example, adding the 'in' >> > keyword for 'X in [A,B,C]' syntax will break all existing code out >> > there that uses the word 'in' for a function, including the >> > `queue:in/2` function call in the standard library. That could >ripple >> > into inconsiderate breakage in the whole ecosystem. >> >> I don't really prefer lists_member/2 or is_member/2 over 'X in >[A,B,C]' >> or the other way, but could you please enlight me (rather erlang >> beginner) about where/why this would break existing code? If we talk >> about a list as the second/right side arg of 'in', I could think of >> either having an opening bracket '[' or a variable bound to that list >> ("when X in List") after the keyword when to be used as a guard, or >of >> '(' when to be used as the abovementioned function call. So for me, >> that looks rather simple, but as already written, I'd like to further >> improve knowledge. >> >> Thanks in advance >> Eckard >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> -- Kind regards, Dmitry Belyaev -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Wed Mar 27 01:07:27 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Wed, 27 Mar 2019 13:07:27 +1300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: Everybody seems to be chasing after how to express "X in [...]" as a guard without responding to the suggestion of copying SML/NJ's "or patterns" as Erlang has already copied andalso and orelse from SML. "or patterns" do not introduce a newreserved word, do not make a special case of a function in a module other than erlang". and are strictly more general than "_ in _". I am also puzzled that nobody seems to be concerned that the one and only example we have of a use case is code that should never be written in the first place because it requires frequent maintenance effort (where it needs to be changed or not does not matter, it still needs to be CHECKED with each new release of Unicode, and Unicode changes quite often). As an exercise, I wrote a little script to parse UnicodeData.txt and write lines like -- I am on another machine so this is not an actual example -- fraction(9999) -> 3/11; % VULGAR FRACTION THREE ELEVENTHS ... fraction(C) when is_integer(C), C >= 0 -> undef. Plug it into your build tool of choice, and the code automatically gets correctly updated whenever a new version of Unicode is installed. With a little more work, you could configure it to support multiple versions of Unicode. This is code that should NOT be written by hand. If anything, we need to retain the current setup so that the pain of trying to do the wrong thing triggers the realisation that the the fault is not in Erlang. On Tue, 26 Mar 2019 at 19:42, Richard O'Keefe wrote: > I must repeat, we do not need any new syntax. > We just need the special case of lists:member/2 > with a fixed-length list argument to be accepted > in a guard. This is a relatively minor change > to the compiler. > > If any syntactic extension were involved, > SML/NJ allows (P1 | ... | Pn) anywhere that > a pattern is allowed. > > However, this particular example strikes me as > a perfect example of something that should NOT > repeat NOT be done by pattern matching. Why? > Because "does this codepoint represent a vulgar > fraction in Unicode" is not a question with a > fixed answer. Unicode keeps on growing. The > *right* question is "does codepoint X represent > a vulgar fraction in Unicode version Y", and > you not only do not want to express that kind > of thing in code, you don't want to, because > Unicode keeps on growing, new versions keep on > coming out. You want to be able to load a new > Unicode Data release *without* rewriting your > Erlang code. > > Alternativey, this appears to be an excellent > example of code that should be *generated*, not > *written*, and who cares how hard the compiler > has to work? > > On Tue, 26 Mar 2019 at 08:43, Jesper Louis Andersen < > jesper.louis.andersen@REDACTED> wrote: > >> >> >> On Mon, Mar 25, 2019 at 8:36 PM Fred Hebert wrote: >> >>> >>> OTP-21 includes the new BIFs erlang:map_get(Key, Map) and >>> erlang:map_size(Map) for these reasons. Only lists:member is missing. >>> >> >> Indeed! Though the documentation doesn't have them as "Allowed in guard >> tests". We can live without is_key, if we just test against true for now. I >> tried looking it up and the documentation didn't have them as allowed. But >> perhaps the code actually allows them if I just tried doing it? >> >> >> >> -- >> J. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2QdxY4RzWzUUiLuE@REDACTED Wed Mar 27 02:04:43 2019 From: 2QdxY4RzWzUUiLuE@REDACTED (Dan Sommers) Date: Tue, 26 Mar 2019 20:04:43 -0500 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: <8bd7dcc9-921e-df0f-9f46-02988b9f6ec0@potatochowder.com> On 3/26/19 7:07 PM, Richard O'Keefe wrote: > Everybody seems to be chasing after how to express "X in [...]" as a guard > without responding to the suggestion of copying SML/NJ's "or patterns" as > Erlang has already copied andalso and orelse from SML. "or patterns" do > not introduce a newreserved word, do not make a special case of a function > in a module other than erlang". and are strictly more general than "_ in _". Speaking as a long time polyglot and a relative newcomer to Erlang, here's my response: the "or pattern" is already used elsewhere to solve this problem, and fits Erlang's functional style very well. The "in" operator creates an impedance mismatch. Now that I understand some of the arguments against lists: member/2, I would also favor a new erlang:list_member (or similarly named function) over an "in" operator. I've written plenty of Python code, and "in" fits in over there, but it's a bad fit for Erlang, and definitely not sexy given the alternatives. > I am also puzzled that nobody seems to be concerned that the one and only > example we have of a use case is code that should never be written in the > first place ... I couldn't agree more. Dan From jose.valim@REDACTED Wed Mar 27 02:17:01 2019 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 27 Mar 2019 02:17:01 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: > Everybody seems to be chasing after how to express "X in [...]" as a guard without responding to the suggestion of copying SML/NJ's "or patterns" What are the restrictions for OR patterns? Can OR patterns be allowed anywhere in a pattern (i.e. arbitrarily nested) or are they allowed only at the root? Can we bind variables inside OR patterns? I assume both are possible as long as after all combinations are expanded, they all bind the same variable names? > I am also puzzled that nobody seems to be concerned that the one and only example we have of a use case is code that should never be written in the first place Since we do have this feature in Elixir, I can provide examples of where we use it in the language, translated to Erlang. I will use the is_member/2 syntax but anyone is welcome to translate it to "X in Y" or the equivalent "OR patterns". *Example 1: validate supervision restart* validate_restart(_Name, Strategy) when is_member([permanent, temporary, transient], Strategy) -> ok; validate_restart(Name, Strategy) -> error({bad_strategy, Name, Strategy}). Without is_member, you either need multiple clauses (which is ok in this case, since the positive clauses only return ok) or write long guards (too repetitive IMO). *Example 2: rewriting Erlang binary operators into Elixir AST* rewrite_guard_call(Op) when is_member(['band', 'bor', 'bnot', 'bsl', 'bsr', 'bxor'], Op) -> {'.', meta(), [bitwise, Op]}; rewrite_guard_call(Op) -> ...N other clauses... I find this a very good example of is_member/2. Of course, the functionality could be written differently, but I can't think of any alternative existing *today* that would be as concise or as elegant as is_member/2. *Example 3: Checking if a character is unreserved according to URI (RFC 3986)* Similar to the Unicode example except we are pinned against a RFC, so it can't change: char_unreserved(Char) when Char >= ?0, Char =< ?9; Char >= ?A, Char =< ?Z; Char >= ?a, Char =< ?z; is_member("~_-.", Char) -> true; char_unreserved(Char) when Char >= 0, Char <= 16x10FFFF -> false. And similar for reserved characters: char_reserved(Char) when is_member(":/?#[]@!$&\'()*+,;=", Char) -> true; char_reserved(Char) when Char >= 0, Char <= 16x10FFFF -> false. There are likely other examples but this should be enough to push the discussion forward. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgallaire@REDACTED Wed Mar 27 02:55:54 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Wed, 27 Mar 2019 02:55:54 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: Tanks a lot Jos? for your great examples, even if obvious for me some people seem to really need them. > char_unreserved(Char) > when Char >= ?0, Char =< ?9; > Char >= ?A, Char =< ?Z; > Char >= ?a, Char =< ?z; > is_member("~_-.", Char) -> > true; > char_unreserved(Char) when is_member("0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ~_-.") -> true; Cheers Florent > char_unreserved(Char) when Char >= 0, Char <= 16x10FFFF -> > > false. > > > And similar for reserved characters: > > char_reserved(Char) > when is_member(":/?#[]@!$&\'()*+,;=", Char) -> > > true; > > char_reserved(Char) when Char >= 0, Char <= 16x10FFFF -> > > false. > > > There are likely other examples but this should be enough to push the discussion forward. > > Jos? Valim > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- FLOSS Engineer & Lawyer From fgallaire@REDACTED Wed Mar 27 03:39:10 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Wed, 27 Mar 2019 03:39:10 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: -define(DIGITS, "0123456789"). -define(LOWERCASE, "abcdefghijklmnopqrstuvwxyz"). -define(UPPERCASE, "ABCDEFGHIJKLMNOPQRSTUVWXYZ"). -define(FRACTIONS, "??????????????????") A standard .hlr include file could be a nice plus. is_fraction(X) when is_member(?FRACTIONS, X) -> true. char_unreserved(Char) when is_member(?DIGITS, Char); is_member(?UPPERCASE, Char); is_member(?LOWERCASE, Char); is_member("~_-.", Char) -> true; Kill the need of integer tricks (yes it's fun, but error-prone and not beginners friendly) will be a nice side-effect. Cheers Florent Le mer. 27 mars 2019 ? 02:55, Florent Gallaire a ?crit : > > Tanks a lot Jos? for your great examples, even if obvious for me some > people seem to really need them. > > > char_unreserved(Char) > > when Char >= ?0, Char =< ?9; > > Char >= ?A, Char =< ?Z; > > Char >= ?a, Char =< ?z; > > is_member("~_-.", Char) -> > > true; > > > > char_unreserved(Char) > when is_member("0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ~_-.") > -> > true; > > Cheers > > Florent > > > char_unreserved(Char) when Char >= 0, Char <= 16x10FFFF -> > > > > false. > > > > > > And similar for reserved characters: > > > > char_reserved(Char) > > when is_member(":/?#[]@!$&\'()*+,;=", Char) -> > > > > true; > > > > char_reserved(Char) when Char >= 0, Char <= 16x10FFFF -> > > > > false. > > > > > > There are likely other examples but this should be enough to push the discussion forward. > > > > Jos? Valim > > www.plataformatec.com.br > > Skype: jv.ptec > > Founder and Director of R&D > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > FLOSS Engineer & Lawyer -- FLOSS Engineer & Lawyer From 2QdxY4RzWzUUiLuE@REDACTED Wed Mar 27 03:40:39 2019 From: 2QdxY4RzWzUUiLuE@REDACTED (Dan Sommers) Date: Tue, 26 Mar 2019 21:40:39 -0500 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: <127fdd31-a716-87ac-669b-9a5e7c7c6db2@potatochowder.com> On 3/26/19 8:55 PM, Florent Gallaire wrote: > Tanks a lot Jos? for your great examples, even if obvious for me some > people seem to really need them. > >> char_unreserved(Char) >> when Char >= ?0, Char =< ?9; >> Char >= ?A, Char =< ?Z; >> Char >= ?a, Char =< ?z; >> is_member("~_-.", Char) -> >> true; >> > > char_unreserved(Char) > when is_member("0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ~_-.") > -> > true; Given the following from section 2.3 of the RFC: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" I find Jos?'s example clearer. From mononcqc@REDACTED Wed Mar 27 03:42:45 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 26 Mar 2019 22:42:45 -0400 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: <20190327024243.GB45961@ferdmbp.local> I do not really want to get in an argument here, but I decided to rewrite these as I would with today's Erlang, for a comparative purpose. On 03/27, Jos? Valim wrote: > >validate_restart(_Name, Strategy) > when is_member([permanent, temporary, transient], Strategy) -> > > ok; > >validate_restart(Name, Strategy) -> > > error({bad_strategy, Name, Strategy}). > > validate_restart(Name, Strategy) -> case lists:member(Strategy, [permanent, temporary, transient]) of true -> ok; false -> error({bad_strategy, Name, Strategy}) end. > >*Example 2: rewriting Erlang binary operators into Elixir AST* > >rewrite_guard_call(Op) > when is_member(['band', 'bor', 'bnot', 'bsl', 'bsr', 'bxor'], Op) -> > > {'.', meta(), [bitwise, Op]}; > >rewrite_guard_call(Op) -> > > ...N other clauses... > This one is just harder to plainly rewrite. As you said, it's a good example. One way I could think of is to write up the types in a map; the pattern underlying this is of categorizing operators. {OpList, Type} --> #{Op1 => Type, Op2 => Type, ...} which can be done once at system initialization, and possibly use persistent terms now. Then the function can be something like rewrite_guard(Op) -> TypeMap = fetch_cached(...), rewrite_guard(Op, maps:get(Op, TypeMap)). rewrite_guard(Op, bitwise) -> {'.', meta(), [bitwise, Op]}; ... N other clauses ... WHile this is far more obtuse than declaring the mapping inline and testing it on each run, the lookups are likely to be much faster at run-time since they won't have to do a linear search. That would of course depend on the map size and the cost of copying it (if you're not using persistent terms). I guess with macros you could essentially build that map by enumerating clauses and baking them into a module for a similar effect, turning things into another autogenerated piece of code. > >*Example 3: Checking if a character is unreserved according to URI (RFC >3986)* > >Similar to the Unicode example except we are pinned against a RFC, so it >can't change: > >char_unreserved(Char) > when Char >= ?0, Char =< ?9; > Char >= ?A, Char =< ?Z; > Char >= ?a, Char =< ?z; > > is_member("~_-.", Char) -> > true; > >char_unreserved(Char) when Char >= 0, Char <= 16x10FFFF -> > > false. > This one is a bit annoying because you can just inline the boolean expression: char_unreserved(Char) -> (Char >= ?0 andalso Char =< ?9 andalso Char >= ?A andalso Char =< ?Z andalso Char >= ?a andalso Char =< ?z andalso lists:member(Char, "~_-.")) orelse (Char >= 0 andalso Char =< 16#10FFFF). > >And similar for reserved characters: > >char_reserved(Char) > when is_member(":/?#[]@!$&\'()*+,;=", Char) -> > > true; > >char_reserved(Char) when Char >= 0, Char <= 16x10FFFF -> > > false. > Which similarly inlines to: char_reserved(Char) -> lists:member(Char, ":/?#[]@!$&\'()*+,;=") orelse (Char >= 0 andalso Char <= 16#10FFFF). It is not my intent to push the discussion backwards or in any other way, One could argue that having to move the boolean expressions and pattern matches out of the function heads and guard patterns is a limitation on its own that should be addressed, and that the rewrite_guard is way too painful as it is: clarity is better than the potential performance gain (which also requires far more knowledge of VM internals than the is_member/2 approach). I'm not casting judgement here. Regards, Fred. From mononcqc@REDACTED Wed Mar 27 03:45:06 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 26 Mar 2019 22:45:06 -0400 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <20190327024243.GB45961@ferdmbp.local> References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <20190327024243.GB45961@ferdmbp.local> Message-ID: <20190327024505.GC45961@ferdmbp.local> On 03/26, Fred Hebert wrote: > >char_unreserved(Char) -> > (Char >= ?0 andalso Char =< ?9 andalso > Char >= ?A andalso Char =< ?Z andalso > Char >= ?a andalso Char =< ?z andalso > lists:member(Char, "~_-.")) > orelse > (Char >= 0 andalso Char =< 16#10FFFF). > The last one should read 'not (Char >= 0 andalso Char =< 16#10FFFF)' > >char_reserved(Char) -> > lists:member(Char, ":/?#[]@!$&\'()*+,;=") > orelse > (Char >= 0 andalso Char <= 16#10FFFF). > And similarly here, 'not (Char >= 0 andalso Char <= 16#10FFFF)' My bad. From andreas.schultz@REDACTED Wed Mar 27 08:20:15 2019 From: andreas.schultz@REDACTED (Andreas Schultz) Date: Wed, 27 Mar 2019 08:20:15 +0100 Subject: [erlang-questions] OTP 22 socket module Message-ID: Hi, Is a {active, N} like delivery of data planed for the new socket or will polling the recv methods be the only way the receive data? What about non-blocking connect and accept? My preference would be to get an active notification when data is available for receive and another one when when a non-blocking write is possible. Sending and reception should then be left to the caller. Same goes for non-block accept and connect. Call accept/connect with a async option and get some message when the procedures finishes. I do realize that all this could be build with a gen_server/gen_statem around socket, so I guess the real question is does it make sense to start build such a wrapper or are the plans to make async functions part of the socket module? Thanks Andreas -- -- Dipl.-Inform. Andreas Schultz ----------------------- enabling your networks ---------------------- Travelping GmbH Phone: +49-391-81 90 99 0 Roentgenstr. 13 Fax: +49-391-81 90 99 299 39108 Magdeburg Email: info@REDACTED GERMANY Web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 --------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Wed Mar 27 08:52:05 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Wed, 27 Mar 2019 16:52:05 +0900 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: <36153248.xv1vtEgLtn@takoyaki> On 2019?3?26???? 15?51?08? JST Florent Gallaire wrote: > > As Jos? pointed out, all guard BIFs are currently in the Erlang > > module. So most likely there would be a new guard BIF in the erlang > > module called is_member/2 or lists_member/2. > > Why do you clearly prefer is_member/2 or lists_member/2 to 'Var in > ' ? > > It's also a good opportunity to make Erlang more modern with a sexy > syntactic sugar... No. That's what other disaster zones are for. Functions are nearly always better than new syntax. Almost. This particular case doesn't even rate discussion. How much once-cool-but-now-unused syntax is there in C++, Haskell, Ruby, etc? ... ugh. There are languages I've used for more than a decade in which I occasionally stumble upon a line I can't begin to comprehend because the syntax exhibits a never-used-but-legal construct and I have no idea what to call the thing I'm seeing so I am left powerless to even do a search to figure it out. "Oh! That's a 'left-fish'! Well, had I only known how to search for it... since it couldn't be simply named as a function..." Erlang doesn't need new syntax for this, you need more familiarity with Erlang and to research our long and glorious history of discussing the merits of new syntax, pure function declarations, allowing more permissible functions in guards, set operators (instead of set functions/operations), etc. Quite a lot of that history is right here in the mailing list archives. Any complex operation in a function head makes the burden of comprehending function heads more complex and has the potential to make the match itself expensive. You shouldn't want either to be true (consider the well-known case of paralyzed performance through the use of length/1 in a set of function head guards). If you want to do complex comparison operations (such as checking membership) do it in the body of a function itself. The closest you'll get to this in matching is with map keys, and there are constraints on that case for good reasons already. Why would we go to the trouble to special-case some syntax for membership check which can only accept a literal at compile time (and how do you fit *that* in there if the list of things to check is very large?) when the obvious solution is what everyone already does (checking inside the function itself)? This case isn't even very common over literal values outside of parsers and encoders/decoders. I've written a LOT of encoders and decoders, and while extended guards leave a bit to be desired in terms of initial typing and there could be some utilty to making it easy to define a set of most-used guards (oh wait, you can write them once and wrap that up in a function, nevermind...) WRITING the code is never as important as being able to READ it later -- and a drop-down set of guards is pretty darn easy to comprehend, even in a gigantic set of function clauses like often encountered in encoders specifically because they are boring, explicit, and not hidden by any magical syntax. Case in point: https://gitlab.com/zxq9/zj/blob/6364e17ebf3e8215e2631e8d9f082fc09b741528/src/zj.erl#L411 Code like this happen a lot in decoders and parsers and pretty much nowhere else, and once written tend not to change much except for DEBUGGING if there turns out to be a problem with it. Infrequently updated forms of code is the WORST candidate for new syntax inclusion. Note, I am NOT addressing there general case of membership checks, I am specifically addressing the case where the membership comparison set is statically defined and known at compile time becuase that's the only case that is even remotely reasonable to consider here. The case where the comparison is against dynamic values on either side is already handled by existing list, set, map, etc. functions. Note, there are SEVERAL ways to compare for membership because there are SEVERAL types of collections. Why are we special casing lists? Should we also have a magic syntax just in case something exists in a set? What about the now-unloved dicts? gb-trees? etc. -Craig From essen@REDACTED Wed Mar 27 09:56:18 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Wed, 27 Mar 2019 09:56:18 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <172A51CB-AB25-43B1-9C16-34248BC2CC76@gmail.com> References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <20190326192442.4fd748bb@gmx.de> <172A51CB-AB25-43B1-9C16-34248BC2CC76@gmail.com> Message-ID: On 26/03/2019 23:12, Dmitry Belyaev wrote: > No current code will be broken if an infix 'in' operator is parsed based > on context as it's not currently used. > If an auto-impotred function 'erlang:is_member' is introduced, the code > previously using locally defined function 'is_member' will be broken. If > the bif is not auto-imported its usage in guards will be very confusing. > > All these proposed changes - a new operator, or a new function - to me > look as too small changes, not really solving the main problem - absence > of convenient and accepted way to metaprogramming. We do have an accepted way. "Don't do it." Not sure why the discussion moved into metaprogramming territory, there's no need to add new syntax for this. Just a new guard function. -- Lo?c Hoguin https://ninenines.eu From mikpelinux@REDACTED Wed Mar 27 09:57:38 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 27 Mar 2019 09:57:38 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <36153248.xv1vtEgLtn@takoyaki> References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <36153248.xv1vtEgLtn@takoyaki> Message-ID: Instead of focusing on syntax, people should focus on semantics. The basic problem is the very presence of so-called "guard expressions", as a highly restricted subset of the general set of expressions. The guard expression restriction is only needed in receives, to ensure that the mailbox doesn't change as a side-effect of evaluating the pattern match + guard combination. In other contexts, guards could be fully general boolean expressions -- only historical reasons prevent them from being so. Personally I tend to write code to dispatch on the result of classification functions instead of relying on complex guards. From oliver.bollmann@REDACTED Wed Mar 27 10:09:35 2019 From: oliver.bollmann@REDACTED (Oliver Bollmann) Date: Wed, 27 Mar 2019 10:09:35 +0100 Subject: [erlang-questions] Hipe and Binary - Bitstring Message-ID: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> I use, with binaries like <<1:1000000>>, one(F,<>) -> one(F,Bitmap,0,[]). one(F, <<0:1,R/bitstring>>,N,Acc) -> one(F,R,N +1,Acc); one(F, <<1:1,R/bitstring>>,N,Acc) -> one(F,R,N +1, [F(N) |Acc]); one(_, <<>>,_,Acc) ->Acc. union(<>, <>) -> <>. and call this functions 1,000,000 times, this takes for 1,000 calls about 20 minutes, if i compile with native -compile([native,{hipe, o2}])it takes 3 seconds for 1,000 calls, so it is about 400x faster !! OS: OSX What is the secret? -- Gr??e Oliver Bollmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Wed Mar 27 12:01:23 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 27 Mar 2019 07:01:23 -0400 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <36153248.xv1vtEgLtn@takoyaki> Message-ID: <20190327110121.GD45961@ferdmbp.local> On 03/27, Mikael Pettersson wrote: >Instead of focusing on syntax, people should focus on semantics. > >The basic problem is the very presence of so-called "guard >expressions", as a highly restricted subset of the general set of >expressions. The guard expression restriction is only needed in >receives, to ensure that the mailbox doesn't change as a side-effect >of evaluating the pattern match + guard combination. In other >contexts, guards could be fully general boolean expressions -- only >historical reasons prevent them from being so. > Hot-code loading could also lead to weird effects where you could not only have recursive guards, but guards whose meaning changes during clause evaluation and could give really funky results when you consider that the compiler reserves rights to modify clause order. From raoknz@REDACTED Wed Mar 27 12:25:52 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Thu, 28 Mar 2019 00:25:52 +1300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: I knew it! I knew it! "??????????????????? That list is NOT an exhaustive list of all the "VULGAR FRACTION n dTHS" characters! It was not even complete back in Unicode 6.3. Nor is the version with two integer ranges complete. If this list is not *intended* to include all such characters, there had better be a very clear and explicit comment saying that it is so and why it is so. Let me put it this way: if the number of cases you want to cover this way is sufficiently large that writing it is enough of a pain to comment on, considering all the other things you have to do, you almost surely have the list wrong. So I was *expecting* the list to miss something, and it was. In fact the list is incomplete in two different ways. First, it does not contain all the "VULGAR FRACTION *" characters. Second, it does not contain *any* of the "ORIYA FRACTION *", "TELUGU FRACTION *", "MALAYALAM FRACTION *", "NORTH INDIC FRACTION *", "RUMI FRACTION *", or "COPTIC FRACTION *" characters (and there were 27 of those in Unicode 6.3), and there is no explanation of why not. Seriously, by the time the function is adequately documented as to which characters are included, which excluded, and why, the actual code is relatively small. On Tue, 26 Mar 2019 at 02:13, Florent Gallaire wrote: > Hello Brujo, > > Thanks for your answer. > > > Why not just? > > > > is_fraction(X) -> lists:member(X, "???????????????????). > > Because it's not possible: "illegal guard expression". > > > Or, if you really really want to use function clause heads, > pattern-matching and guards: > > > > is_fraction(X) when $? =< X =< $? -> true; > > is_fraction(X) when $? =< X <= $? -> true; > > is_fraction(_) -> false. > > > > For these kinds of character manipulation things, using the fact that > they?re just integers under-the-hood is not a bad idea. > > Yes you're right in this case, but it remains a trick so most of the > time it's not applicable. > > Cheers > > > Cheers! > > > > ________________________________ > > Brujo Benavides > > > > > > > > On 25 Mar 2019, at 09:38, Florent Gallaire wrote: > > > > Hello Richard, > > > > Thanks for your answer. > > > > lists:member(X, [X1,X2,X3,X4]) answers true or false. > > There is no fundamental reason that the compiler could not > > expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) > > when the shape of the list is known. So we *definitely* need > > no new syntax. > > > > > > So if there's no reason the compiler could not do it, we *really* > > should have a new syntax. > > > > We really need an actual concrete example of real code to discuss. > > > > > > The developed version of the is_fraction/1 function: > > > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction($?) -> true; > > is_fraction(_) -> false. > > > > The awful actual "with a guard" version: > > > > is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; > > is_fraction(_) -> false. > > > > The pretty, easy and obviously needed "with in list syntactic sugar" > version : > > > > is_fraction(X) when X in "??????????????????" -> true; > > is_fraction(_) -> false. > > > > It clearly speaks for itself. > > > > Cheers. > > > > On Mon, 25 Mar 2019 at 18:12, Florent Gallaire > wrote: > > > > > > Frank thanks for your answer. > > > > You?re probably new to Erlang. > > > > > > Yes, but... > > > > You can achieve the same with parse_transform: > > https://github.com/mad-cocktail/gin/blob/master/README.rst > > > > > > ...I can say parse_transform is not the solution Erlang needs. > > > > There?s no point to add new syntax to the language. > > > > > > Yes we need it, an easy to use built-in "in (tuple or list I'm not > > sure of the right semantic)" syntactic sugar for guards. > > > > Hope some other advices. > > > > Florent > > > > /Frank > > > > Hello everybody, > > > > I'm not very experimented in Erlang but I read carefully books and > > official documention. > > > > It seems to me that the guards syntax is not as good as it should be, > > i.e. too much verbose for multiple values. > > > > do(val1) -> val1; > > do(val2) -> val2; > > do(val3) -> val3; > > do(val4) -> val4; > > do(val5) -> val5. > > > > do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > > Val =:= val5 -> Val. > > > > It's boring and error prone to write. > > > > Has a "in tuple" syntax already be considered ? Something like : > > > > do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > > > > Cheers > > > > Florent > > > > -- > > FLOSS Engineer & Lawyer > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > -- > > FLOSS Engineer & Lawyer > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > -- > > FLOSS Engineer & Lawyer > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > -- > FLOSS Engineer & Lawyer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Wed Mar 27 12:41:19 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Thu, 28 Mar 2019 00:41:19 +1300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: "If there is no reason the compiler could not do it [using existing syntax] we *really* need new syntax." That does not make sense. And I shall keep on repeating * this is the code of code which should never be written by hand * when it is generated by a simple script, who cares what the generated code looks like? With frequent mutterings of * with this number of cases, no matter HOW you write it, the safe money says "it's wrong". And it arguably is, so * what code like this needs above all is documentation. When you are dealing with Unicode characters, the chances are excellent that you need to represent some characters your available fonts cannot display, and if yours can, mine that I am reading your code with probably cannot. is_fraction(($? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? )) -> true; is_fraction(_) -> false. doesn't look too bad, does it? No new operator. No new reserved word. It _is_ new syntax, but it is strictly more general than the rather ugly 'in' special case. On Tue, 26 Mar 2019 at 01:38, Florent Gallaire wrote: > Hello Richard, > > Thanks for your answer. > > > lists:member(X, [X1,X2,X3,X4]) answers true or false. > > There is no fundamental reason that the compiler could not > > expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) > > when the shape of the list is known. So we *definitely* need > > no new syntax. > > So if there's no reason the compiler could not do it, we *really* > should have a new syntax. > > > We really need an actual concrete example of real code to discuss. > > The developed version of the is_fraction/1 function: > > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction($?) -> true; > is_fraction(_) -> false. > > The awful actual "with a guard" version: > > is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; > is_fraction(_) -> false. > > The pretty, easy and obviously needed "with in list syntactic sugar" > version : > > is_fraction(X) when X in "??????????????????" -> true; > is_fraction(_) -> false. > > It clearly speaks for itself. > > Cheers. > > > On Mon, 25 Mar 2019 at 18:12, Florent Gallaire > wrote: > >> > >> Frank thanks for your answer. > >> > >> > You?re probably new to Erlang. > >> > >> Yes, but... > >> > >> > You can achieve the same with parse_transform: > >> > https://github.com/mad-cocktail/gin/blob/master/README.rst > >> > >> ...I can say parse_transform is not the solution Erlang needs. > >> > >> > There?s no point to add new syntax to the language. > >> > >> Yes we need it, an easy to use built-in "in (tuple or list I'm not > >> sure of the right semantic)" syntactic sugar for guards. > >> > >> Hope some other advices. > >> > >> Florent > >> > >> > /Frank > >> > > >> >> Hello everybody, > >> >> > >> >> I'm not very experimented in Erlang but I read carefully books and > >> >> official documention. > >> >> > >> >> It seems to me that the guards syntax is not as good as it should be, > >> >> i.e. too much verbose for multiple values. > >> >> > >> >> do(val1) -> val1; > >> >> do(val2) -> val2; > >> >> do(val3) -> val3; > >> >> do(val4) -> val4; > >> >> do(val5) -> val5. > >> >> > >> >> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > >> >> Val =:= val5 -> Val. > >> >> > >> >> It's boring and error prone to write. > >> >> > >> >> Has a "in tuple" syntax already be considered ? Something like : > >> >> > >> >> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > >> >> > >> >> Cheers > >> >> > >> >> Florent > >> >> > >> >> -- > >> >> FLOSS Engineer & Lawyer > >> >> _______________________________________________ > >> >> erlang-questions mailing list > >> >> erlang-questions@REDACTED > >> >> http://erlang.org/mailman/listinfo/erlang-questions > >> > >> > >> > >> -- > >> FLOSS Engineer & Lawyer > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > FLOSS Engineer & Lawyer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Wed Mar 27 13:04:56 2019 From: john@REDACTED (John =?ISO-8859-1?Q?H=F6gberg?=) Date: Wed, 27 Mar 2019 13:04:56 +0100 Subject: [erlang-questions] Hipe and Binary - Bitstring In-Reply-To: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> References: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> Message-ID: <279725e33f4b420fd95841dbe69378d5919fba50.camel@erlang.org> Hi Oliver, I've tried to reproduce this discrepancy on my machine, but I can only see a modest difference on latest OTP 21 (the results are in microseconds): Erlang/OTP 21 [erts-10.3.1] [source] [64-bit] [smp:24:24] [ds:24:24:10] [async-threads:1] [hipe] Eshell V10.3.1 (abort with ^G)1> c(t, []). {ok,t}2> t:bench(one). 159573043> t:bench(union).5594704> c(t, [native]). {ok,t}5> t:bench(one). 36113716> t:bench(union).501871 I've attached the source code I used for this test, am I missing something? Regards,John H?gberg On Wed, 2019-03-27 at 10:09 +0100, Oliver Bollmann wrote: > I use, with binaries like <<1:1000000>>, > > one(F,<>) > -> one(F,Bitmap,0,[]).one(F, <<0:1, R/bitstring>>, N, Acc) > -> one(F, R, N + 1, Acc);one(F, <<1:1, R/bitstring>>, N, Acc) > -> one(F, R, N + 1, [F(N) | Acc]);one(_, <<>>, _, Acc) -> > Acc.union(< P/bitstring>>, <>) > -> <>. > > and call this functions 1,000,000 times, this takes for 1,000 > calls about 20 minutes, > > > > if i compile with native -compile([native,{hipe, o2}]) it takes 3 > seconds for 1,000 calls, so it is about 400x faster !! > > OS: OSX > > > > What is the secret? > > -- Gr??eOliver Bollmann > > > _______________________________________________erlang-questions > mailing listerlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.erl Type: text/x-erlang Size: 1090 bytes Desc: not available URL: From jesper.louis.andersen@REDACTED Wed Mar 27 13:28:55 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 27 Mar 2019 13:28:55 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: On Wed, Mar 27, 2019 at 2:17 AM Jos? Valim wrote: > > Everybody seems to be chasing after how to express "X in [...]" as a > guard > without responding to the suggestion of copying SML/NJ's "or patterns" > > What are the restrictions for OR patterns? > Can OR patterns be allowed anywhere in a pattern (i.e. arbitrarily nested) > or are they allowed only at the root? > Can we bind variables inside OR patterns? > > I'll use Ocaml as the language for this, since it has the same pattern as SML/NJ, and I happen to have Ocaml installed, but not SML/NJ. In erlang we write: case Exp of P1 -> E1; P2 -> E2; P3 -> E3 end In Ocaml, we would write match Exp With | P1 -> E1 | P2 -> E2 | P3 -> E3 Note that we prefix each pattern by '|' rather than separate them with ';' as in Erlang. The semantics are otherwise the same at least up to a very high level of equivalence. Now suppose, we have a case where we want to write match Exp with | P1 -> E | P2 -> E | P3 -> E3 That is, both patterns P1 and P2 runs the same function body E. In this case, Ocaml allows us to avoid the repetition, the so-called OR-pattern: match Exp with | P1 | P2 -> E | P3 -> E3 What are the rules? Any use of a variable 'x' in E must be bound in the scope and must have the same type. That is, if P1 binds 'x : t' i.e., with type t, then P2 must also bind 'x : t'. In principle, we could allow it if the scope/context has 'x : t' and it isn't bound in P2, but this is currently rejected by the language, probably on the grounds of being prone to error. The compiler has a relatively easy rewrite to make: let body_E x = E in match Exp with | P1 x -> body_E x | P2 x -> body_E x ... more or less (caveat: capture! body_E must be be passed parameters appropriately if it uses them from the context. Further optimizations might then lift them). Extract the common body into a local function and apply that function. Further optimizations are often able to remove 'body_E' from the generated code. Since we are in ML-land with Standard ML and Ocaml, the Mlton compiler has a contification optimization which will fuse the body_E continutation appropriately. This can then uncover further optimizations down the road. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Mar 27 13:48:10 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 27 Mar 2019 13:48:10 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <36153248.xv1vtEgLtn@takoyaki> References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <36153248.xv1vtEgLtn@takoyaki> Message-ID: On Wed, Mar 27, 2019 at 8:52 AM wrote: > How much once-cool-but-now-unused syntax is there in C++, Haskell, Ruby, > etc? > > Haskell is the exception to the rule. In Haskell, you can define your own operators and give them precedence. But they are just functions in the core language. There are very few restricted keywords in Haskell (98): 28 identifiers such as 'case', 'where', 'deriving', 'class', ... and 27 symbols such as '*', '!', ... The rest are libraries defining their own operators. Almost nothing in Haskell has special handling requiring language extension. Proof Assistants take this idea even further by allowing mixfix operators to be defined. Agda allows us to define if-then-else: if_then_else_ : ? {a} {A : Set a} ? Bool ? A ? A ? A if true then t else f = t if false then t else f = f Where the underscores say where the holes are in the expression. That is, the construct is not built into the language. It is *defined* as part of the standard library[*]. This also allows far more complicated rules such as (brace for unicode!) x ?? M ? y, which allows us to have an operation (the dot) under a given magma[0] for elements x and y of that type. Personal opinion: It is often better to add generic functionality to a language then special case handling. The compiler is free to optimize the generic situation if it can see some specific structure, and this has long-term support. Whereas the other way is far more restrictive (though it is often alluring). However, syntactic sugar might be necessary in certain cases, as it makes code easier to read, and often more convenient to work with. Add sugar, but add it sparingly. [*] Note this requires evaluation order to be lazy. You can only evaluate the two branches once you know the result of the conditional. Otherwise, you don't have the usual semantics of this construct, which is why it is often implement as a built-in into the language. If you have macro-expansion, you can build it on top of case, however. [0] https://en.wikipedia.org/wiki/Magma_(algebra) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Catenacci@REDACTED Wed Mar 27 13:54:20 2019 From: Catenacci@REDACTED (Onorio Catenacci) Date: Wed, 27 Mar 2019 08:54:20 -0400 Subject: [erlang-questions] Syntactic Sugar In-Reply-To: References: Message-ID: Craig said: "> It's also a good opportunity to make Erlang more modern with a sexy > syntactic sugar... "No. That's what other disaster zones are for. "Functions are nearly always better than new syntax. Almost. "This particular case doesn't even rate discussion. "How much once-cool-but-now-unused syntax is there in C++, Haskell, Ruby, etc?" +1000 Craig! When it comes to adding syntactic sugar to a language the opposite of Postel's Law should apply. Be conservative in what you accept! Every "great idea" will live on in the language from that point forward. Be very wary of adding stuff to the language which can be solved in other less-permanent ways. -- Onorio Catenacci http://onor.io https://twitter.com/OldDutchCap -------------- next part -------------- An HTML attachment was scrubbed... URL: From be.dmitry@REDACTED Wed Mar 27 14:28:40 2019 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Thu, 28 Mar 2019 00:28:40 +1100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <36153248.xv1vtEgLtn@takoyaki> Message-ID: <3D77FB15-A7A3-40D7-993E-B6DFBA7D0B33@gmail.com> If I remember correctly Idris has eager evaluation and also defines 'if then else' in the standard library. So I believe lazy evaluation is not really required for that. On 27 March 2019 23:48:10 GMT+11:00, Jesper Louis Andersen wrote: >On Wed, Mar 27, 2019 at 8:52 AM wrote: > >> How much once-cool-but-now-unused syntax is there in C++, Haskell, >Ruby, >> etc? >> >> >Haskell is the exception to the rule. In Haskell, you can define your >own >operators and give them precedence. But they are just functions in the >core >language. There are very few restricted keywords in Haskell (98): 28 >identifiers such as 'case', 'where', 'deriving', 'class', ... and 27 >symbols such as '*', '!', ... The rest are libraries defining their own >operators. Almost nothing in Haskell has special handling requiring >language extension. > >Proof Assistants take this idea even further by allowing mixfix >operators >to be defined. Agda allows us to define if-then-else: > >if_then_else_ : ? {a} {A : Set a} ? Bool ? A ? A ? A >if true then t else f = t >if false then t else f = f > >Where the underscores say where the holes are in the expression. That >is, >the construct is not built into the language. It is *defined* as part >of >the standard library[*]. This also allows far more complicated rules >such >as (brace for unicode!) x ?? M ? y, which allows us to have an >operation >(the dot) under a given magma[0] for elements x and y of that type. > >Personal opinion: It is often better to add generic functionality to a >language then special case handling. The compiler is free to optimize >the >generic situation if it can see some specific structure, and this has >long-term support. Whereas the other way is far more restrictive >(though it >is often alluring). However, syntactic sugar might be necessary in >certain >cases, as it makes code easier to read, and often more convenient to >work >with. Add sugar, but add it sparingly. > >[*] Note this requires evaluation order to be lazy. You can only >evaluate >the two branches once you know the result of the conditional. >Otherwise, >you don't have the usual semantics of this construct, which is why it >is >often implement as a built-in into the language. If you have >macro-expansion, you can build it on top of case, however. >[0] https://en.wikipedia.org/wiki/Magma_(algebra) -- Kind regards, Dmitry Belyaev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Mar 27 15:14:25 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 27 Mar 2019 15:14:25 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: <3D77FB15-A7A3-40D7-993E-B6DFBA7D0B33@gmail.com> References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <36153248.xv1vtEgLtn@takoyaki> <3D77FB15-A7A3-40D7-993E-B6DFBA7D0B33@gmail.com> Message-ID: On Wed, Mar 27, 2019 at 2:28 PM Dmitry Belyaev wrote: > If I remember correctly Idris has eager evaluation and also defines 'if > then else' in the standard library. So I believe lazy evaluation is not > really required for that. > > Two points: * In a total language, evaluation order only matters insofar efficiency is concerned. The result would be the same, regardless of evaluation order. * Idris implementation types the branches as Lazy, so it explicitly marks those as lazily evaluated. Evaluation order is but a mode of execution, so converting between them is possible. A lazy by default language often requires strictness annotations for efficiency reasons. And likewise, a strict language enjoy having explicit laziness for efficiency reasons, where efficiency encompasses execution time as well as space usage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.geib.44@REDACTED Wed Mar 27 17:49:12 2019 From: mark.geib.44@REDACTED (Mark Geib) Date: Wed, 27 Mar 2019 10:49:12 -0600 Subject: [erlang-questions] SOLVED - no logger output using ?LOG macros in release In-Reply-To: References: <4D844006-52F5-4A37-8CD8-15108720E84D@gmail.com> <4A390CA2-C06C-4D99-81D4-2C02576E6BD9@gmail.com> <0DDBE35D-7988-4C80-B0B8-5EC574C53218@srstrong.com> <300A54A3-A6FB-4DD7-AE28-BB9898AB2D79@gmail.com> Message-ID: Just to follow up. Spent yesterday tracking this all down and there is no issue with the logging macros, etc. I was not explicitly specifying versions in my rebar.conf and late last week, while I was migrating my logging to use the macros a new RC release of a dependency was pushed to the HEX repo. This is apparently when my logging stopped working. Because I do my prod builds with an erlang docker image it was always grabbing the latest release of all the dependencies, thus getting this new RC release. In dev of course rebar3 locks the versions used in builds. I also failed to include the rebar.lock file in my repo. Lesson learned, always use explicit versions of dependencies, and in addition add the rebar.lock to the repo. Sorry for all the confusion and misleading information. Mark. > On Mar 26, 2019, at 4:51 AM, Siri Hansen wrote: > > Hi Mark, > > I'm not sure what the difference could be between dev an prod here, but if you can access your node, did you check that the logger configuration is as expected? logger:i() in OTP-21.3, or else logger:get_config(). Just to make sure nothing failed silently during startup. > > Another thing though - are you using run_erl with your prod release? If so, given the file name specified for the default handler, you must make sure that run_erl does not have the same log directory as you handler, or else they will attempt writing to the same file. logger_disk_log_h has no mechanism to ensure that it's file descriptor is fresh (the inode has not been changed), so if run_erl writes something to the same file, then the next log event from logger_disk_log_h will just disappear :( (logger_std_h has better protection against this, and from OTP-21.3 it also has log rotation.) But this is of course not related to the macros at all, so if everything works ok with logger:info(..) but not with the macro, then there must be something else going on anyway. > > Regards > /siri > > Den man. 25. mar. 2019 kl. 20:49 skrev Mark Geib >: > Yes, here is the bottom of my sys.config. > > {kernel, > [{logger_level, info}, {logger, > [{handler, default, logger_disk_log_h, > #{config => #{file => "/var/log/asp2aj/erlang.log", type => wrap, max_no_files => 10, max_no_bytes => 1000000000}, > formatter => {logger_formatter, #{single_line => true, template => [time," ",mfa,":",line," ",pid," [",level,"] ",msg,"\n"]}}} > }] > }] > }]. > > Mark. > > >> On Mar 25, 2019, at 1:44 PM, Steve Strong > wrote: >> >> Do you have the logger_level value set in your sys.config (or are you setting it in code)? The ?LOG macros check that before logging? >> >> -define(DO_LOG(Level,Args), >> case logger:allow(Level,?MODULE) of >> true -> >> apply(logger,macro_log,[?LOCATION,Level|Args]); >> false -> >> ok >> end). >> -endif. >> >> Cheers, >> >> Steve >> >>> On 25 Mar 2019, at 19:41, Mark Geib > wrote: >>> >>> I am using the default handler and formatter, i.e.: >>> >>> [{handler, default, logger_disk_log_h, % handler, HandlerId, Module, >>> #{config => #{file => "/var/log/asp2aj/erlang.log", type => wrap, max_no_files => 10, max_no_bytes => 1000000000}, >>> formatter => {logger_formatter, #{single_line => true, template => [time," ",mfa,":",line," ",pid," [",level,"] ",msg,"\n"]}}} >>> }] >>> >>> >>> And my logging works fine previously when I was doing logger:info()... >>> >>> Thanks, >>> Mark. >>> >>> >>>> On Mar 25, 2019, at 1:32 PM, Fred Hebert > wrote: >>>> >>>> See if you are using any log formatters or handlers -- those may not be direct dependencies of your application, and therefore do not get included in the final release. You will need to add these dependencies to the release independently so that they are present to run and handle output. >>>> >>>> The rebar3 shell and other interactive modes can dynamically load libraries from disk and won't show that little gotcha at all. >>>> >>>> On Mon, Mar 25, 2019 at 1:47 PM Mark Geib > wrote: >>>> I have a problem where I see no logger output in a release built with rebar3 using the new ?LOG macros. If I use the logger: functions >>>> everything is working fine. Decided to change to use the macros in order to get able to include MFA, line number, etc. in templates. >>>> >>>> Also, doing a dev release build and then running interactively everything works fine with the ?LOG macros. It?s like the >>>> prod builds are missing something compared to dev build. >>>> >>>> Thanks in advance for any help. >>>> >>>> Mark. >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgallaire@REDACTED Wed Mar 27 18:20:18 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Wed, 27 Mar 2019 18:20:18 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: > is_fraction(($? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | > $? | $? | $? | $? | $? | $? )) -> true; > is_fraction(_) -> false. > > doesn't look too bad, does it? No new operator. No new reserved > word. It _is_ new syntax, but it is strictly more general than the > rather ugly 'in' special case. Yes it doesn't look bad, as I prefer function header patten matching to anything else. But your "|" syntax is already used in pattern matching; div8([Char | Tail]) when is_member("????", Char) -> {divisor8, Tail}; div8([Char | Tail]) when Char in "????" -> {divisor8, Tail}; is_member/2 and "in list" operator are really working examples. div8([$? | $? | $? | $? | Tail]) -> {divisor8, Tail}; "|" as OR pattern operator doesn't work, you need a new operator/reserved keyword. The "in list" operator and is_member/2 guard BIF are quite equivalent. I prefer the "in list" syntax, probably because of my Python roots, but the is_member/2 guard is good enough to make me happy ! Cheers Florent > On Tue, 26 Mar 2019 at 01:38, Florent Gallaire wrote: >> >> Hello Richard, >> >> Thanks for your answer. >> >> > lists:member(X, [X1,X2,X3,X4]) answers true or false. >> > There is no fundamental reason that the compiler could not >> > expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) >> > when the shape of the list is known. So we *definitely* need >> > no new syntax. >> >> So if there's no reason the compiler could not do it, we *really* >> should have a new syntax. >> >> > We really need an actual concrete example of real code to discuss. >> >> The developed version of the is_fraction/1 function: >> >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction($?) -> true; >> is_fraction(_) -> false. >> >> The awful actual "with a guard" version: >> >> is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; >> X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; >> X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; >> is_fraction(_) -> false. >> >> The pretty, easy and obviously needed "with in list syntactic sugar" version : >> >> is_fraction(X) when X in "??????????????????" -> true; >> is_fraction(_) -> false. >> >> It clearly speaks for itself. >> >> Cheers. >> >> > On Mon, 25 Mar 2019 at 18:12, Florent Gallaire wrote: >> >> >> >> Frank thanks for your answer. >> >> >> >> > You?re probably new to Erlang. >> >> >> >> Yes, but... >> >> >> >> > You can achieve the same with parse_transform: >> >> > https://github.com/mad-cocktail/gin/blob/master/README.rst >> >> >> >> ...I can say parse_transform is not the solution Erlang needs. >> >> >> >> > There?s no point to add new syntax to the language. >> >> >> >> Yes we need it, an easy to use built-in "in (tuple or list I'm not >> >> sure of the right semantic)" syntactic sugar for guards. >> >> >> >> Hope some other advices. >> >> >> >> Florent >> >> >> >> > /Frank >> >> > >> >> >> Hello everybody, >> >> >> >> >> >> I'm not very experimented in Erlang but I read carefully books and >> >> >> official documention. >> >> >> >> >> >> It seems to me that the guards syntax is not as good as it should be, >> >> >> i.e. too much verbose for multiple values. >> >> >> >> >> >> do(val1) -> val1; >> >> >> do(val2) -> val2; >> >> >> do(val3) -> val3; >> >> >> do(val4) -> val4; >> >> >> do(val5) -> val5. >> >> >> >> >> >> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; >> >> >> Val =:= val5 -> Val. >> >> >> >> >> >> It's boring and error prone to write. >> >> >> >> >> >> Has a "in tuple" syntax already be considered ? Something like : >> >> >> >> >> >> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. >> >> >> >> >> >> Cheers >> >> >> >> >> >> Florent >> >> >> >> >> >> -- >> >> >> FLOSS Engineer & Lawyer >> >> >> _______________________________________________ >> >> >> erlang-questions mailing list >> >> >> erlang-questions@REDACTED >> >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> >> >> >> -- >> >> FLOSS Engineer & Lawyer >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> -- >> FLOSS Engineer & Lawyer -- FLOSS Engineer & Lawyer From kostis@REDACTED Wed Mar 27 21:30:09 2019 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 27 Mar 2019 21:30:09 +0100 Subject: [erlang-questions] Hipe and Binary - Bitstring In-Reply-To: <279725e33f4b420fd95841dbe69378d5919fba50.camel@erlang.org> References: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> <279725e33f4b420fd95841dbe69378d5919fba50.camel@erlang.org> Message-ID: On 3/27/19 1:04 PM, John H?gberg wrote: > Hi Oliver, > > I've tried to reproduce this discrepancy on my machine, but I can only > see a modest difference on latest OTP 21 (the results are in microseconds): > > Erlang/OTP 21 [erts-10.3.1] [source] [64-bit] [smp:24:24] [ds:24:24:10] [async-threads:1] [hipe] > > > Eshell V10.3.1??(abort with ^G) > > 1> c(t, []). > > {ok,t} > > 2> t:bench(one). > > 15957304 > > 3> t:bench(union). > > 559470 > > 4> c(t, [native]). > > {ok,t} > > 5> t:bench(one). > > 3611371 > > 6> t:bench(union). > > 501871 > > > I've attached the source code I used for this test, am I missing something? We are obviously missing the benchmark program that Oliver used to get numbers. But the "400x faster" figure cannot possibly be right. Personally, I cannot see how one could turn function union/2, which is a one-liner with two bitstring matches and one construction, into a benchmark. So, it's not surprising that the performance difference there is very small. On the other hand, I would not call the performance difference between BEAM and HiPE that you observed "modest". Four times faster execution is IMO something that deserves a better adjective. Kostis > On Wed, 2019-03-27 at 10:09 +0100, Oliver Bollmann wrote: >> >> I use, with binaries like <<1:1000000>>, >> >> one(F,<>) -> >> one(F,Bitmap,0,[]). >> one(F, <<0:1,R/bitstring>>,N,Acc) -> >> one(F,R,N +1,Acc); >> one(F, <<1:1,R/bitstring>>,N,Acc) -> >> one(F,R,N +1, [F(N) |Acc]); >> one(_, <<>>,_,Acc) ->Acc. >> union(<>, >> <>) -> >> <>. >> >> and call this functions 1,000,000 times, this takes for 1,000 calls >> about 20 minutes, >> >> if i compile with native -compile([native,{hipe, o2}])it takes 3 >> seconds for 1,000 calls, so it is about 400x faster !! >> >> OS: OSX >> >> What is the secret? >> >> -- >> Gr??e >> Oliver Bollmann >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From soverdor@REDACTED Wed Mar 27 22:35:32 2019 From: soverdor@REDACTED (Sam Overdorf) Date: Wed, 27 Mar 2019 14:35:32 -0700 Subject: [erlang-questions] Syntactic Sugar In-Reply-To: References: Message-ID: If it ain't broke don't fix it... Sam On Wed, Mar 27, 2019 at 5:55 AM Onorio Catenacci wrote: > > Craig said: > > "> It's also a good opportunity to make Erlang more modern with a sexy > > syntactic sugar... > > "No. > That's what other disaster zones are for. > > "Functions are nearly always better than new syntax. > Almost. > > "This particular case doesn't even rate discussion. > > "How much once-cool-but-now-unused syntax is there in C++, Haskell, Ruby, etc?" > > +1000 Craig! When it comes to adding syntactic sugar to a language the opposite of Postel's Law should apply. Be conservative in what you accept! Every "great idea" will live on in the language from that point forward. Be very wary of adding stuff to the language which can be solved in other less-permanent ways. > > -- > Onorio Catenacci > http://onor.io > https://twitter.com/OldDutchCap > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From t6sn7gt@REDACTED Wed Mar 27 23:21:36 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Wed, 27 Mar 2019 18:21:36 -0400 Subject: [erlang-questions] true Message-ID: <24277fb4-695d-b361-2c73-284a7825695d@aim.com> As someone very new to Erlang, I find it interesting to follow the discussion on guards. FWIW, the *only* thing about Erlang that drives me to distraction is the use of the atom 'true' as a reliable "or, if the above ain't so" default value for the expression.? If only (how I wish it were so) the atom wasn't so often completely at odds -- and at times the inverse -- of the normal English 'read' of the if expression.? Please consider grandfathering 'true' (not to break old code) and coming up with a logically less committed atom-of-the-future such as 'default' or 'otherwise'. Don From fgallaire@REDACTED Thu Mar 28 00:57:12 2019 From: fgallaire@REDACTED (Florent Gallaire) Date: Thu, 28 Mar 2019 00:57:12 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: Message-ID: With the Jacob "<-" operator suggestion we have: div8([Char | Tail]) when Char <- "????" -> {divisor8, Tail}; Equivalent to the "in lsit" syntax but quite confusing with the list inside "<-" and "->". Mixing with the Richard function header pattern matching we could have: div8([Char <- "????" | Tail]) -> {divisor8, Tail}; No now operator needed, just using existing generator in a new place, and looks really erlangish. Cheers Florent Le mer. 27 mars 2019 ? 18:20, Florent Gallaire a ?crit : > > > is_fraction(($? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | $? | > > $? | $? | $? | $? | $? | $? )) -> true; > > is_fraction(_) -> false. > > > > doesn't look too bad, does it? No new operator. No new reserved > > word. It _is_ new syntax, but it is strictly more general than the > > rather ugly 'in' special case. > > Yes it doesn't look bad, as I prefer function header patten matching > to anything else. > But your "|" syntax is already used in pattern matching; > > div8([Char | Tail]) when is_member("????", Char) -> {divisor8, Tail}; > > div8([Char | Tail]) when Char in "????" -> {divisor8, Tail}; > > is_member/2 and "in list" operator are really working examples. > > div8([$? | $? | $? | $? | Tail]) -> {divisor8, Tail}; > > "|" as OR pattern operator doesn't work, you need a new > operator/reserved keyword. > > The "in list" operator and is_member/2 guard BIF are quite equivalent. > I prefer the "in list" syntax, probably because of my Python roots, > but the is_member/2 guard > is good enough to make me happy ! > > Cheers > > Florent > > > On Tue, 26 Mar 2019 at 01:38, Florent Gallaire wrote: > >> > >> Hello Richard, > >> > >> Thanks for your answer. > >> > >> > lists:member(X, [X1,X2,X3,X4]) answers true or false. > >> > There is no fundamental reason that the compiler could not > >> > expand that in-line to (X =:= X1 orselse ... orelse X =:= X4) > >> > when the shape of the list is known. So we *definitely* need > >> > no new syntax. > >> > >> So if there's no reason the compiler could not do it, we *really* > >> should have a new syntax. > >> > >> > We really need an actual concrete example of real code to discuss. > >> > >> The developed version of the is_fraction/1 function: > >> > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction($?) -> true; > >> is_fraction(_) -> false. > >> > >> The awful actual "with a guard" version: > >> > >> is_fraction(X) when X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > >> X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; > >> X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $?; X =:= $? -> true; > >> is_fraction(_) -> false. > >> > >> The pretty, easy and obviously needed "with in list syntactic sugar" version : > >> > >> is_fraction(X) when X in "??????????????????" -> true; > >> is_fraction(_) -> false. > >> > >> It clearly speaks for itself. > >> > >> Cheers. > >> > >> > On Mon, 25 Mar 2019 at 18:12, Florent Gallaire wrote: > >> >> > >> >> Frank thanks for your answer. > >> >> > >> >> > You?re probably new to Erlang. > >> >> > >> >> Yes, but... > >> >> > >> >> > You can achieve the same with parse_transform: > >> >> > https://github.com/mad-cocktail/gin/blob/master/README.rst > >> >> > >> >> ...I can say parse_transform is not the solution Erlang needs. > >> >> > >> >> > There?s no point to add new syntax to the language. > >> >> > >> >> Yes we need it, an easy to use built-in "in (tuple or list I'm not > >> >> sure of the right semantic)" syntactic sugar for guards. > >> >> > >> >> Hope some other advices. > >> >> > >> >> Florent > >> >> > >> >> > /Frank > >> >> > > >> >> >> Hello everybody, > >> >> >> > >> >> >> I'm not very experimented in Erlang but I read carefully books and > >> >> >> official documention. > >> >> >> > >> >> >> It seems to me that the guards syntax is not as good as it should be, > >> >> >> i.e. too much verbose for multiple values. > >> >> >> > >> >> >> do(val1) -> val1; > >> >> >> do(val2) -> val2; > >> >> >> do(val3) -> val3; > >> >> >> do(val4) -> val4; > >> >> >> do(val5) -> val5. > >> >> >> > >> >> >> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4; > >> >> >> Val =:= val5 -> Val. > >> >> >> > >> >> >> It's boring and error prone to write. > >> >> >> > >> >> >> Has a "in tuple" syntax already be considered ? Something like : > >> >> >> > >> >> >> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val. > >> >> >> > >> >> >> Cheers > >> >> >> > >> >> >> Florent > >> >> >> > >> >> >> -- > >> >> >> FLOSS Engineer & Lawyer > >> >> >> _______________________________________________ > >> >> >> erlang-questions mailing list > >> >> >> erlang-questions@REDACTED > >> >> >> http://erlang.org/mailman/listinfo/erlang-questions > >> >> > >> >> > >> >> > >> >> -- > >> >> FLOSS Engineer & Lawyer > >> >> _______________________________________________ > >> >> erlang-questions mailing list > >> >> erlang-questions@REDACTED > >> >> http://erlang.org/mailman/listinfo/erlang-questions > >> > >> > >> > >> -- > >> FLOSS Engineer & Lawyer > > > > -- > FLOSS Engineer & Lawyer -- FLOSS Engineer & Lawyer From oliver.bollmann@REDACTED Thu Mar 28 01:02:44 2019 From: oliver.bollmann@REDACTED (Oliver Bollmann) Date: Thu, 28 Mar 2019 01:02:44 +0100 Subject: [erlang-questions] Hipe and Binary - Bitstring In-Reply-To: References: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> <279725e33f4b420fd95841dbe69378d5919fba50.camel@erlang.org> Message-ID: Hi Kostis, attached the missing module! The fact is: the factor is stable, 3 seconds with native, 20 minutes without native, the result of the function is the same! Between the 1,000 steps i do not get any traces messages on native! If i trace the gc, the last lines, at the end, with native are: 2019-03-28 00:08:47.834 gc_minor_start [{wordsize,0},{old_heap_block_size,0},{heap_block_size,410034027},{mbuf_size,105},{recent_size,285921217},{stack_size,30},{old_heap_size,0},{heap_size,410033946},{bin_vheap_size,4539999},{bin_vheap_block_size,7427891},{bin_old_vheap_size,0},{bin_old_vheap_block_size,1090210}] 2019-03-28 00:08:51.778 gc_minor_end [{wordsize,124112863},{old_heap_block_size,590448998},{heap_block_size,79467343},{mbuf_size,0},{recent_size,120},{stack_size,30},{old_heap_size,285921068},{heap_size,120},{bin_vheap_size,2},{bin_vheap_block_size,3713945},{bin_old_vheap_size,3736072},{bin_old_vheap_block_size,1090210}] 2019-03-28 00:08:53.716 gc_minor_start [{wordsize,0},{old_heap_block_size,590448998},{heap_block_size,79467343},{mbuf_size,0},{recent_size,120},{stack_size,60},{old_heap_size,285921068},{heap_size,79467276},{bin_vheap_size,651374},{bin_vheap_block_size,3713945},{bin_old_vheap_size,3736072},{bin_old_vheap_block_size,1090210}] 2019-03-28 00:08:53.716 gc_minor_end [{wordsize,0},{old_heap_block_size,590448998},{heap_block_size,79467343},{mbuf_size,0},{recent_size,120},{stack_size,60},{old_heap_size,285921068},{heap_size,79467276},{bin_vheap_size,651374},{bin_vheap_block_size,3713945},{bin_old_vheap_size,3736072},{bin_old_vheap_block_size,1090210}] 2019-03-28 00:08:53.716 gc_major_start [{wordsize,0},{old_heap_block_size,590448998},{heap_block_size,79467343},{mbuf_size,0},{recent_size,120},{stack_size,60},{old_heap_size,285921068},{heap_size,79467276},{bin_vheap_size,651374},{bin_vheap_block_size,3713945},{bin_old_vheap_size,3736072},{bin_old_vheap_block_size,1090210}] 2019-03-28 00:08:57.587 gc_major_end [{wordsize,79467130},{old_heap_block_size,0},{heap_block_size,410034027},{mbuf_size,0},{recent_size,285921226},{stack_size,60},{old_heap_size,0},{heap_size,285921226},{bin_vheap_size,3736074},{bin_vheap_block_size,6009163},{bin_old_vheap_size,0},{bin_old_vheap_block_size,1090210}] 2019-03-28 00:09:03.228 gc_minor_start [{wordsize,0},{old_heap_block_size,0},{heap_block_size,410034027},{mbuf_size,15972166},{recent_size,285921226},{stack_size,19},{old_heap_size,0},{heap_size,402266882},{bin_vheap_size,4689732},{bin_vheap_block_size,6009163},{bin_old_vheap_size,0},{bin_old_vheap_block_size,1090210}] 2019-03-28 00:09:07.676 gc_minor_end [{wordsize,116345800},{old_heap_block_size,590448998},{heap_block_size,79467343},{mbuf_size,0},{recent_size,15972177},{stack_size,19},{old_heap_size,285921071},{heap_size,15972177},{bin_vheap_size,0},{bin_vheap_block_size,3004581},{bin_old_vheap_size,3736072},{bin_old_vheap_block_size,1090210}] On not using native i get between the 1,000 steps: ... 2019-03-28 00:54:45.408 gc_minor_start [{wordsize,10970},{old_heap_block_size,410034027},{heap_block_size,17731},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516968},{heap_size,11001},{bin_vheap_size,31252},{bin_vheap_block_size,46422},{bin_old_vheap_size,5156641},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:46.123 gc_minor_end [{wordsize,0},{old_heap_block_size,410034027},{heap_block_size,28690},{mbuf_size,0},{recent_size,10980},{stack_size,38},{old_heap_size,287516989},{heap_size,10980},{bin_vheap_size,0},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:46.135 gc_minor_start [{wordsize,15627},{old_heap_block_size,410034027},{heap_block_size,28690},{mbuf_size,0},{recent_size,10980},{stack_size,38},{old_heap_size,287516989},{heap_size,22186},{bin_vheap_size,62502},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:46.838 gc_minor_end [{wordsize,22165},{old_heap_block_size,410034027},{heap_block_size,28690},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516989},{heap_size,21},{bin_vheap_size,31252},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:46.838 gc_minor_start [{wordsize,0},{old_heap_block_size,410034027},{heap_block_size,28690},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516989},{heap_size,161},{bin_vheap_size,46878},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:47.549 gc_minor_end [{wordsize,137},{old_heap_block_size,410034027},{heap_block_size,233},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516992},{heap_size,21},{bin_vheap_size,15626},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:47.946 gc_minor_start [{wordsize,15627},{old_heap_block_size,410034027},{heap_block_size,233},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516992},{heap_size,135},{bin_vheap_size,62502},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:48.313 gc_minor_end [{wordsize,114},{old_heap_block_size,410034027},{heap_block_size,17731},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516992},{heap_size,21},{bin_vheap_size,31252},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:48.313 gc_minor_start [{wordsize,0},{old_heap_block_size,410034027},{heap_block_size,17731},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516992},{heap_size,155},{bin_vheap_size,46878},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:49.030 gc_minor_end [{wordsize,131},{old_heap_block_size,410034027},{heap_block_size,233},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516995},{heap_size,21},{bin_vheap_size,15626},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:49.788 gc_minor_start [{wordsize,15627},{old_heap_block_size,410034027},{heap_block_size,233},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516995},{heap_size,135},{bin_vheap_size,62502},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:49.789 gc_minor_end [{wordsize,114},{old_heap_block_size,410034027},{heap_block_size,17731},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516995},{heap_size,21},{bin_vheap_size,31252},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:49.789 gc_minor_start [{wordsize,0},{old_heap_block_size,410034027},{heap_block_size,17731},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516995},{heap_size,161},{bin_vheap_size,46878},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:50.508 gc_minor_end [{wordsize,137},{old_heap_block_size,410034027},{heap_block_size,233},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516998},{heap_size,21},{bin_vheap_size,15626},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:50.520 gc_minor_start [{wordsize,15627},{old_heap_block_size,410034027},{heap_block_size,233},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516998},{heap_size,135},{bin_vheap_size,62502},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:51.271 gc_minor_end [{wordsize,114},{old_heap_block_size,410034027},{heap_block_size,17731},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516998},{heap_size,21},{bin_vheap_size,31252},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:51.271 gc_minor_start [{wordsize,0},{old_heap_block_size,410034027},{heap_block_size,17731},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287516998},{heap_size,155},{bin_vheap_size,46878},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:51.981 gc_minor_end [{wordsize,131},{old_heap_block_size,410034027},{heap_block_size,233},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287517001},{heap_size,21},{bin_vheap_size,15626},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:51.993 gc_minor_start [{wordsize,15627},{old_heap_block_size,410034027},{heap_block_size,233},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287517001},{heap_size,135},{bin_vheap_size,62503},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:52.738 gc_minor_end [{wordsize,114},{old_heap_block_size,410034027},{heap_block_size,17731},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287517001},{heap_size,21},{bin_vheap_size,31252},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] 2019-03-28 00:54:52.739 gc_minor_start [{wordsize,0},{old_heap_block_size,410034027},{heap_block_size,17731},{mbuf_size,0},{recent_size,21},{stack_size,38},{old_heap_size,287517001},{heap_size,155},{bin_vheap_size,46878},{bin_vheap_block_size,46422},{bin_old_vheap_size,5187893},{bin_old_vheap_block_size,5708181}] ... Oliver On 27.03.19 21:30, Kostis Sagonas wrote: > On 3/27/19 1:04 PM, John H?gberg wrote: >> Hi Oliver, >> >> I've tried to reproduce this discrepancy on my machine, but I can >> only see a modest difference on latest OTP 21 (the results are in >> microseconds): >> >> Erlang/OTP 21 [erts-10.3.1] [source] [64-bit] [smp:24:24] >> [ds:24:24:10] [async-threads:1] [hipe] >> >> >> Eshell V10.3.1??(abort with ^G) >> >> 1> c(t, []). >> >> {ok,t} >> >> 2> t:bench(one). >> >> 15957304 >> >> 3> t:bench(union). >> >> 559470 >> >> 4> c(t, [native]). >> >> {ok,t} >> >> 5> t:bench(one). >> >> 3611371 >> >> 6> t:bench(union). >> >> 501871 >> >> >> I've attached the source code I used for this test, am I missing >> something? > > > We are obviously missing the benchmark program that Oliver used to get > numbers.? But the "400x faster" figure cannot possibly be right. > > Personally, I cannot see how one could turn function union/2, which is > a one-liner with two bitstring matches and one construction, into a > benchmark.? So, it's not surprising that the performance difference > there is very small. > > On the other hand, I would not call the performance difference between > BEAM and HiPE that you observed "modest".? Four times faster execution > is IMO something that deserves a better adjective. > > Kostis > > >> On Wed, 2019-03-27 at 10:09 +0100, Oliver Bollmann wrote: >>> >>> I use, with binaries like <<1:1000000>>, >>> >>> one(F,<>) -> >>> ?? one(F,Bitmap,0,[]). >>> one(F, <<0:1,R/bitstring>>,N,Acc) -> >>> ?? one(F,R,N +1,Acc); >>> one(F, <<1:1,R/bitstring>>,N,Acc) -> >>> ?? one(F,R,N +1, [F(N) |Acc]); >>> one(_, <<>>,_,Acc) ->Acc. >>> union(<>, >>> <>) -> >>> ?? <>. >>> >>> and call this functions 1,000,000 times, this takes for 1,000 calls >>> about 20 minutes, >>> >>> if i compile with native -compile([native,{hipe, o2}])it takes 3 >>> seconds for 1,000 calls, so it is about 400x faster !! >>> >>> OS: OSX >>> >>> What is the secret? >>> >>> -- >>> Gr??e >>> Oliver Bollmann >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- Gr??e Oliver Bollmann -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- -module(bitmap_hipe_test). %-compile([native]). %Erlang 20.3 % native on %bitmap_hipe_test:run(1000000,100,1000,true,false). %{3634346,done} % native off %bitmap_hipe_test:run(1000000,100,1000,true,false). %{13435975,done} % % factor 3,7 %% API -export([run/0,run/5]). run() -> run(1000000,100,1000,true,true). run(Size,Count,Loop,UseTC,UseProf) -> % first make count bitmaps Bitmaps = make_bitmaps(Size,Count), % function F F = fun(N) -> case get(N) of _ -> N end end, FRun = fun() -> run_(F,Bitmaps,Bitmaps,Loop) end, profiling(UseProf,start), Res = case UseTC of true -> timer:tc(FRun); _-> FRun() end, profiling(UseProf,stop), Res. profiling(false,_) -> ok; profiling(true,start) -> consider_profiling(); profiling(true,stop) -> profile_output(). run_(_,_,_,0) -> done; run_(F,[],OrgBitmaps,Loop) -> run_(F,OrgBitmaps,OrgBitmaps,Loop-1); run_(F,[Bitmap1,Bitmap2|Bitmaps],OrgBitmaps,Loop) -> one(F,Bitmap1), union(Bitmap1,Bitmap2), run_(F,[Bitmap2|Bitmaps],OrgBitmaps,Loop-1); run_(F,[Bitmap|Bitmaps],OrgBitmaps,Loop) -> one(F,Bitmap), run_(F,Bitmaps,OrgBitmaps,Loop-1). one(F,<>) -> one(F,Bitmap,0,[]). one(F, <<0:1, R/bitstring>>, N, Acc) -> one(F, R, N + 1, Acc); one(F, <<1:1, R/bitstring>>, N, Acc) -> one(F, R, N + 1, [F(N) | Acc]); one(_, <<>>, _, Acc) -> Acc. union(<>, <>) -> <>. make_bitmaps(Size,Count) -> make_bitmaps(Size,Count,[]). make_bitmaps(_Size,0,Acc) -> Acc; make_bitmaps(Size,Count,Acc) -> make_bitmaps(Size,Count-1,[random_bitmap(Size)|Acc]). random_bitmap(Size) -> % we set 20% of the bitmap, about Bytes = bytes(Size) - 8, Bits = Bytes * 8, Elements = lists:usort([0|[begin R = rand:uniform(Bits-1), erlang:phash2(R,2)*R end || _ <- lists:seq(1, 100000)]]), from_list(Elements,[{size,Size}]). new([{size, Size}]) when Size > 0-> %% bytes gives us the total bytes of a bitmap, including the %% 8 byte size prefix, so we need to substract that. Bytes = bytes(Size) - 8, Bits = Bytes * 8, <>. bytes(Size) -> ceiling(Size / 8) + 8. ceiling(X) when X < 0 -> trunc(X); ceiling(X) -> T = trunc(X), case X - T == 0 of true -> T; false -> T + 1 end. size(<>) -> Size. from_list(Elements, [{size, Size}]) -> R = from_list_(0, Elements, <<>>), Bytes = bytes(Size) - 8, Bits = Bytes * 8, Missing = Bits - bit_size(R), <>. from_list_(Pos, [X | R], Acc) when X > Pos -> Missing = X - Pos, from_list_(X + 1, R, <>); from_list_(Pos, [Pos | R], Acc) -> from_list_(Pos + 1, R, <>); from_list_(_, [], R) -> R. profile_output() -> eprof:stop_profiling(), %eprof:log("procs.profile"), %eprof:analyze(procs), eprof:log("total.profile"), eprof:analyze(total). consider_profiling() -> {ok, Pid} = case eprof:start() of {error,{already_started,Pid}} -> {ok,Pid}; {ok, Pid} -> {ok, Pid} end, eprof:start_profiling([self()]).%processes() -- [Pid]). From icfp.publicity@REDACTED Thu Mar 28 03:45:07 2019 From: icfp.publicity@REDACTED (Sam Tobin-Hochstadt) Date: Wed, 27 Mar 2019 22:45:07 -0400 Subject: [erlang-questions] Call for Tutorial Proposals: ICFP 2019 Message-ID: <5c9c3533f2e7f_79832ab973eda5c499873@homer.mail> CALL FOR TUTORIAL PROPOSALS ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming August 18 - 23, 2019 Berlin, Germany https://icfp19.sigplan.org/ The 24th ACM SIGPLAN International Conference on Functional Programming will be held in Berlin, Germany on August 18-23, 2019. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". Tutorials may occur after ICFP co-located with the associated workshops, from August 22 till August 23. ---------------------------------------------------------------------- Submission details Deadline for submission: May 10th, 2019 Notification of acceptance: May 17th, 2019 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2018 workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019@REDACTED by May 10th, 2019. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by May 17, 2019. The proposal form is available at: http://www.icfpconference.org/icfp2019-files/icfp19-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2019 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Christophe Scholliers (University of Ghent) General Chair: Derek Dreyer (MPI-SWS) Program Chair: Fran?ois Pottier ( Inria, France) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs ( Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019@REDACTED From oliver.bollmann@REDACTED Thu Mar 28 06:50:04 2019 From: oliver.bollmann@REDACTED (Oliver Bollmann) Date: Thu, 28 Mar 2019 06:50:04 +0100 Subject: [erlang-questions] Hipe and Binary - Bitstring In-Reply-To: <5c1fa977cb2df1c976a622ea17c3105254c5de7f.camel@erlang.org> References: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> <279725e33f4b420fd95841dbe69378d5919fba50.camel@erlang.org> <5c1fa977cb2df1c976a622ea17c3105254c5de7f.camel@erlang.org> Message-ID: <80b6aceb-44d1-3c5b-3825-fa9e35d6f847@t-online.de> Hi John, gc tracer(native) *1,000,000* steps: #{gc_major_end => 36,gc_major_start => 36,gc_max_heap_size => 0,gc_minor_end => 116,gc_minor_start => 116} gc tracer(*NOT* native)*1,000* steps: #{gc_major_end => 35,gc_major_start => 35,gc_max_heap_size => 0,gc_minor_end => 1202,gc_minor_start => 1202} Oliver On 27.03.19 17:22, John H?gberg wrote: > Nevermind, I'm blind, I just noticed "UseProf" now. I may need more > coffee :o) > > It's possible that the native code generates less garbage on the heap, > causing fewer GCs, which will be a lot faster if your processes have a > lot of live data as it won't have to copy it over and over. Try > comparing how many garbage collections the process has gone through > with process_info(Pid, garbage_collection), maybe it will provide some > clue. > > /John > > On Wed, 2019-03-27 at 16:31 +0100, John H?gberg wrote: >> Hi Oliver, >> >> Have you tried comparing performance without eprof? >> >> eprof uses tracing to figure out which functions take a long time to >> run, which adds considerable overhead to small functions that are >> repeated extremely often. HiPE doesn't support tracing at all, so >> that overhead simply disappears when the module is native-compiled. >> >> Regards, >> John H?gberg >> >> On Wed, 2019-03-27 at 16:18 +0100, Oliver Bollmann wrote: >>> >>> Hi John, >>> >>> indeed, on standalone the factor is about 3.7 only :-( >>> >>> Attached the module i used. The code is part of: >>> https://gitlab.com/Project-FiFo/DalmatinerDB/bitmap >>> >>> I wonder, where comes the boost? >>> >>> Facts: OS OSX 10.14.3(64GB) >>> ????????? Erlang 20.3.18, >>> ????????? the "boost" module use a lot of process directory (about >>> 10GB, almost of this are binaries!) >>> >>> Any hints? >>> >>> Oliver >>> >>> On 27.03.19 13:04, John H?gberg wrote: >>>> Hi Oliver, >>>> >>>> I've tried to reproduce this discrepancy on my machine, but I can >>>> only see a modest difference on latest OTP 21 (the results are in >>>> microseconds): >>>> >>>> Erlang/OTP 21 [erts-10.3.1] [source] [64-bit] [smp:24:24] [ds:24:24:10] [async-threads:1] [hipe] >>>> Eshell V10.3.1??(abort with ^G) >>>> 1> c(t, []). >>>> {ok,t} >>>> 2> t:bench(one). >>>> 15957304 >>>> 3> t:bench(union). >>>> 559470 >>>> 4> c(t, [native]). >>>> {ok,t} >>>> 5> t:bench(one). >>>> 3611371 >>>> 6> t:bench(union). >>>> 501871 >>>> >>>> I've attached the source code I used for this test, am I missing >>>> something? >>>> >>>> Regards, >>>> John H?gberg >>>> >>>> On Wed, 2019-03-27 at 10:09 +0100, Oliver Bollmann wrote: >>>>> >>>>> I use, with binaries like <<1:1000000>>, >>>>> >>>>> one(F,<>) -> >>>>> one(F,Bitmap,0,[]). >>>>> one(F, <<0:1,R/bitstring>>,N,Acc) -> >>>>> one(F,R,N +1,Acc); >>>>> one(F, <<1:1,R/bitstring>>,N,Acc) -> >>>>> one(F,R,N +1, [F(N) |Acc]); >>>>> one(_, <<>>,_,Acc) ->Acc. >>>>> union(<>, >>>>> <>) -> >>>>> <>. >>>>> >>>>> and call this functions 1,000,000 times, this takes for 1,000 >>>>> calls about 20 minutes, >>>>> >>>>> if i compile with native -compile([native,{hipe, o2}])it takes 3 >>>>> seconds for 1,000 calls, so it is about 400x faster !! >>>>> >>>>> OS: OSX >>>>> >>>>> What is the secret? >>>>> >>>>> -- >>>>> Gr??e >>>>> Oliver Bollmann >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> -- >>> Gr??e >>> Oliver Bollmann -- Gr??e Oliver Bollmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Thu Mar 28 08:27:29 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Thu, 28 Mar 2019 08:27:29 +0100 Subject: [erlang-questions] Can Erlang supervise a c node Message-ID: I have a c node (written in golang) that I've written to interface with a particular library. I know how to monitor it, but I'm interested to know if there's some "off the shelf" Erlang API for supervising/restarting it or if I have to implement it myself. --Albin -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.bollmann@REDACTED Thu Mar 28 08:34:43 2019 From: oliver.bollmann@REDACTED (Oliver Bollmann) Date: Thu, 28 Mar 2019 08:34:43 +0100 Subject: [erlang-questions] Hipe and Binary - Bitstring In-Reply-To: <80b6aceb-44d1-3c5b-3825-fa9e35d6f847@t-online.de> References: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> <279725e33f4b420fd95841dbe69378d5919fba50.camel@erlang.org> <5c1fa977cb2df1c976a622ea17c3105254c5de7f.camel@erlang.org> <80b6aceb-44d1-3c5b-3825-fa9e35d6f847@t-online.de> Message-ID: <98c63437-bf40-affb-8921-847c8ed220a5@t-online.de> Hi John, *problem solved!* The secret is: process_flag(min_heap_size,1024*1024*10),process_flag(*min_bin_vheap_size*,1024*1024*10*10), with this i get *without native* 1,000,000 steps: #{gc_major_end => 8,gc_major_start => 8,gc_max_heap_size => 0,gc_minor_end => 85,gc_minor_start => 85} Performance is 100 time faster, the missing factor 4 comes from hipe itself! Very nice! Oliver On 28.03.19 06:50, Oliver Bollmann wrote: > > Hi John, > > gc tracer(native) *1,000,000* steps: > > #{gc_major_end => 36,gc_major_start => 36,gc_max_heap_size => 0,gc_minor_end => 116,gc_minor_start => 116} > > gc tracer(*NOT* native)*1,000* steps: > #{gc_major_end => 35,gc_major_start => 35,gc_max_heap_size => 0,gc_minor_end => 1202,gc_minor_start => 1202} > > Oliver > > > On 27.03.19 17:22, John H?gberg wrote: >> Nevermind, I'm blind, I just noticed "UseProf" now. I may need more >> coffee :o) >> >> It's possible that the native code generates less garbage on the >> heap, causing fewer GCs, which will be a lot faster if your processes >> have a lot of live data as it won't have to copy it over and over. >> Try comparing how many garbage collections the process has gone >> through with process_info(Pid, garbage_collection), maybe it will >> provide some clue. >> >> /John >> >> On Wed, 2019-03-27 at 16:31 +0100, John H?gberg wrote: >>> Hi Oliver, >>> >>> Have you tried comparing performance without eprof? >>> >>> eprof uses tracing to figure out which functions take a long time to >>> run, which adds considerable overhead to small functions that are >>> repeated extremely often. HiPE doesn't support tracing at all, so >>> that overhead simply disappears when the module is native-compiled. >>> >>> Regards, >>> John H?gberg >>> >>> On Wed, 2019-03-27 at 16:18 +0100, Oliver Bollmann wrote: >>>> >>>> Hi John, >>>> >>>> indeed, on standalone the factor is about 3.7 only :-( >>>> >>>> Attached the module i used. The code is part of: >>>> https://gitlab.com/Project-FiFo/DalmatinerDB/bitmap >>>> >>>> I wonder, where comes the boost? >>>> >>>> Facts: OS OSX 10.14.3(64GB) >>>> ????????? Erlang 20.3.18, >>>> ????????? the "boost" module use a lot of process directory (about >>>> 10GB, almost of this are binaries!) >>>> >>>> Any hints? >>>> >>>> Oliver >>>> >>>> On 27.03.19 13:04, John H?gberg wrote: >>>>> Hi Oliver, >>>>> >>>>> I've tried to reproduce this discrepancy on my machine, but I can >>>>> only see a modest difference on latest OTP 21 (the results are in >>>>> microseconds): >>>>> >>>>> Erlang/OTP 21 [erts-10.3.1] [source] [64-bit] [smp:24:24] [ds:24:24:10] [async-threads:1] [hipe] >>>>> Eshell V10.3.1??(abort with ^G) >>>>> 1> c(t, []). >>>>> {ok,t} >>>>> 2> t:bench(one). >>>>> 15957304 >>>>> 3> t:bench(union). >>>>> 559470 >>>>> 4> c(t, [native]). >>>>> {ok,t} >>>>> 5> t:bench(one). >>>>> 3611371 >>>>> 6> t:bench(union). >>>>> 501871 >>>>> >>>>> I've attached the source code I used for this test, am I missing >>>>> something? >>>>> >>>>> Regards, >>>>> John H?gberg >>>>> >>>>> On Wed, 2019-03-27 at 10:09 +0100, Oliver Bollmann wrote: >>>>>> >>>>>> I use, with binaries like <<1:1000000>>, >>>>>> >>>>>> one(F,<>) -> >>>>>> one(F,Bitmap,0,[]). >>>>>> one(F, <<0:1,R/bitstring>>,N,Acc) -> >>>>>> one(F,R,N +1,Acc); >>>>>> one(F, <<1:1,R/bitstring>>,N,Acc) -> >>>>>> one(F,R,N +1, [F(N) |Acc]); >>>>>> one(_, <<>>,_,Acc) ->Acc. >>>>>> union(<>, >>>>>> <>) -> >>>>>> <>. >>>>>> >>>>>> and call this functions 1,000,000 times, this takes for 1,000 >>>>>> calls about 20 minutes, >>>>>> >>>>>> if i compile with native -compile([native,{hipe, o2}])it takes 3 >>>>>> seconds for 1,000 calls, so it is about 400x faster !! >>>>>> >>>>>> OS: OSX >>>>>> >>>>>> What is the secret? >>>>>> >>>>>> -- >>>>>> Gr??e >>>>>> Oliver Bollmann >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> -- >>>> Gr??e >>>> Oliver Bollmann > -- > Gr??e > Oliver Bollmann > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Gr??e Oliver Bollmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Mar 28 08:55:23 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 28 Mar 2019 08:55:23 +0100 Subject: [erlang-questions] Hipe and Binary - Bitstring In-Reply-To: <98c63437-bf40-affb-8921-847c8ed220a5@t-online.de> References: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> <279725e33f4b420fd95841dbe69378d5919fba50.camel@erlang.org> <5c1fa977cb2df1c976a622ea17c3105254c5de7f.camel@erlang.org> <80b6aceb-44d1-3c5b-3825-fa9e35d6f847@t-online.de> <98c63437-bf40-affb-8921-847c8ed220a5@t-online.de> Message-ID: Can someone shed some light on the difference between min_heap_size & *min_bin_vheap_size* on how to tweak them per process to tune VM?s perfs? Thanks Hi John, > > *problem solved!* > > The secret is: process_flag(min_heap_size,1024*1024*10),process_flag( > *min_bin_vheap_size*,1024*1024*10*10), > > with this i get *without native* 1,000,000 steps: > > #{gc_major_end => 8,gc_major_start => 8,gc_max_heap_size => 0,gc_minor_end => 85,gc_minor_start => 85} > > Performance is 100 time faster, the missing factor 4 comes from hipe itself! > > Very nice! > > Oliver > > On 28.03.19 06:50, Oliver Bollmann wrote: > > Hi John, > > gc tracer(native) *1,000,000* steps: > > #{gc_major_end => 36,gc_major_start => 36,gc_max_heap_size => 0,gc_minor_end => 116,gc_minor_start => 116} > > gc tracer(*NOT* native) *1,000* steps: > > #{gc_major_end => 35,gc_major_start => 35,gc_max_heap_size => 0,gc_minor_end => 1202,gc_minor_start => 1202} > > Oliver > > > > On 27.03.19 17:22, John H?gberg wrote: > > Nevermind, I'm blind, I just noticed "UseProf" now. I may need more coffee > :o) > > It's possible that the native code generates less garbage on the heap, > causing fewer GCs, which will be a lot faster if your processes have a lot > of live data as it won't have to copy it over and over. Try comparing how > many garbage collections the process has gone through with process_info(Pid, > garbage_collection), maybe it will provide some clue. > > /John > > On Wed, 2019-03-27 at 16:31 +0100, John H?gberg wrote: > > Hi Oliver, > > Have you tried comparing performance without eprof? > > eprof uses tracing to figure out which functions take a long time to run, > which adds considerable overhead to small functions that are repeated > extremely often. HiPE doesn't support tracing at all, so that overhead > simply disappears when the module is native-compiled. > > Regards, > John H?gberg > > On Wed, 2019-03-27 at 16:18 +0100, Oliver Bollmann wrote: > > Hi John, > > indeed, on standalone the factor is about 3.7 only :-( > > Attached the module i used. The code is part of: > https://gitlab.com/Project-FiFo/DalmatinerDB/bitmap > > I wonder, where comes the boost? > > Facts: OS OSX 10.14.3(64GB) > Erlang 20.3.18, > the "boost" module use a lot of process directory (about 10GB, > almost of this are binaries!) > > Any hints? > > Oliver > On 27.03.19 13:04, John H?gberg wrote: > > Hi Oliver, > > I've tried to reproduce this discrepancy on my machine, but I can only see > a modest difference on latest OTP 21 (the results are in microseconds): > > Erlang/OTP 21 [erts-10.3.1] [source] [64-bit] [smp:24:24] [ds:24:24:10] [async-threads:1] [hipe] > > Eshell V10.3.1 (abort with ^G) > > 1> c(t, []). > > {ok,t} > > 2> t:bench(one). > > 15957304 > > 3> t:bench(union). > > 559470 > > 4> c(t, [native]). > > {ok,t} > > 5> t:bench(one). > > 3611371 > > 6> t:bench(union). > > 501871 > > > I've attached the source code I used for this test, am I missing something? > > Regards, > John H?gberg > > On Wed, 2019-03-27 at 10:09 +0100, Oliver Bollmann wrote: > > I use, with binaries like <<1:1000000>>, > > one(F,<>) -> > > one(F,Bitmap,0,[]). > > one(F, <<0:1, R/bitstring>>, N, Acc) -> > > one(F, R, N + 1, Acc); > > one(F, <<1:1, R/bitstring>>, N, Acc) -> > > one(F, R, N + 1, [F(N) | Acc]); > > one(_, <<>>, _, Acc) -> Acc. > > union(<>, > > <>) -> > > <>. > > and call this functions 1,000,000 times, this takes for 1,000 calls about > 20 minutes, > > if i compile with native -compile([native,{hipe, o2}]) it takes 3 seconds > for 1,000 calls, so it is about 400x faster !! > > OS: OSX > > What is the secret? > > -- > > Gr??e > > Oliver Bollmann > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- > > Gr??e > > Oliver Bollmann > > -- > Gr??e > Oliver Bollmann > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > -- > Gr??e > Oliver Bollmann > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfredlund@REDACTED Thu Mar 28 10:00:55 2019 From: lfredlund@REDACTED (=?UTF-8?Q?Lars-=c3=85ke_Fredlund?=) Date: Thu, 28 Mar 2019 10:00:55 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> <36153248.xv1vtEgLtn@takoyaki> Message-ID: <2d98b004-e41e-f962-6c1e-5a59f9546c8e@fi.upm.es> A good analysis. Please consider generalising the if statements (and/or finally introduce a cond expression) to permit arbitrary functions; the separation between guard functions and normal "predicate" functions has always felt very artificial to me when writing code. There is a reason as Mikael says to keep it for the receive, but in other contexts... It just hurts expressitivity. /Lars-Ake On 27/3/19 9:57, Mikael Pettersson wrote: > Instead of focusing on syntax, people should focus on semantics. > > The basic problem is the very presence of so-called "guard > expressions", as a highly restricted subset of the general set of > expressions. The guard expression restriction is only needed in > receives, to ensure that the mailbox doesn't change as a side-effect > of evaluating the pattern match + guard combination. In other > contexts, guards could be fully general boolean expressions -- only > historical reasons prevent them from being so. > > Personally I tend to write code to dispatch on the result of > classification functions instead of relying on complex guards. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From fly@REDACTED Thu Mar 28 10:09:53 2019 From: fly@REDACTED (Fred Youhanaie) Date: Thu, 28 Mar 2019 09:09:53 +0000 Subject: [erlang-questions] Can Erlang supervise a c node In-Reply-To: References: Message-ID: A c-node is an external OS process, so perhaps erlexec may help: https://hex.pm/packages/erlexec Cheers, Fred On 28/03/2019 07:27, Albin Stig? wrote: > I have a c node (written in golang) that I've written to interface with a particular library. > > I know how to monitor it, but I'm interested to know if there's some "off the shelf" Erlang API for supervising/restarting it or if I have to implement it myself. > > > --Albin From raoknz@REDACTED Thu Mar 28 12:36:42 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Fri, 29 Mar 2019 00:36:42 +1300 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: I believe I already said that an OR-pattern is allowed anywhere a pattern is allowed. Further, an alternative of an OR-pattern may bind variables if and only if every alternative of the OR-pattern binds the same variables (ignoring wild cards). (Not entirely unlike Erlang 'case'.) It's the same in F#. Here's an example from the manual. let detectZeroOR point = match point with | (0, 0) | (0, _) | (_, 0) -> printfn "Zero found." | _ -> printfn "Both nonzero." So that is at least three functional languages that currently support OR-patterns: Caml, F#, and SML (both SML/NJ and MLton). However, it seems likely that this fills a much-needed gap. Complex patterns are probably wrong. On Thu, 28 Mar 2019 at 01:29, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > On Wed, Mar 27, 2019 at 2:17 AM Jos? Valim < > jose.valim@REDACTED> wrote: > >> > Everybody seems to be chasing after how to express "X in [...]" as a >> guard >> without responding to the suggestion of copying SML/NJ's "or patterns" >> >> What are the restrictions for OR patterns? >> Can OR patterns be allowed anywhere in a pattern (i.e. arbitrarily >> nested) or are they allowed only at the root? >> Can we bind variables inside OR patterns? >> >> > I'll use Ocaml as the language for this, since it has the same pattern as > SML/NJ, and I happen to have Ocaml installed, but not SML/NJ. > > In erlang we write: > > case Exp of > P1 -> E1; > P2 -> E2; > P3 -> E3 > end > > In Ocaml, we would write > > match Exp With > | P1 -> E1 > | P2 -> E2 > | P3 -> E3 > > Note that we prefix each pattern by '|' rather than separate them with ';' > as in Erlang. The semantics are otherwise the same at least up to a very > high level of equivalence. Now suppose, we have a case where we want to > write > > match Exp with > | P1 -> E > | P2 -> E > | P3 -> E3 > > That is, both patterns P1 and P2 runs the same function body E. In this > case, Ocaml allows us to avoid the repetition, the so-called OR-pattern: > > match Exp with > | P1 | P2 -> E > | P3 -> E3 > > What are the rules? Any use of a variable 'x' in E must be bound in the > scope and must have the same type. That is, if P1 binds 'x : t' i.e., with > type t, then P2 must also bind 'x : t'. In principle, we could allow it if > the scope/context has 'x : t' and it isn't bound in P2, but this is > currently rejected by the language, probably on the grounds of being prone > to error. > > The compiler has a relatively easy rewrite to make: > > let body_E x = E in > match Exp with > | P1 x -> body_E x > | P2 x -> body_E x > ... > > more or less (caveat: capture! body_E must be be passed parameters > appropriately if it uses them from the context. Further optimizations might > then lift them). Extract the common body into a local function and apply > that function. Further optimizations are often able to remove 'body_E' from > the generated code. Since we are in ML-land with Standard ML and Ocaml, the > Mlton compiler has a contification optimization which will fuse the body_E > continutation appropriately. This can then uncover further optimizations > down the road. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.petrauskas@REDACTED Thu Mar 28 12:56:42 2019 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Thu, 28 Mar 2019 13:56:42 +0200 Subject: [erlang-questions] [ANN] Paxoid - distributed sequence generator. Message-ID: I have released an application for generating a sequence of unique numbers in a master-less cluster. The algorithm is based on the classical Paxos. It was build primarily to assign short unique identifiers to nodes in a cluster. I hope you will find it useful. More details at: https://github.com/erisata/paxoid Karolis Petrauskas From rtrlists@REDACTED Thu Mar 28 13:02:44 2019 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 28 Mar 2019 13:02:44 +0100 Subject: [erlang-questions] Can Erlang supervise a c node In-Reply-To: References: Message-ID: Hi Albin, if you are starting the C node from the Erlang side, you can wrap the starting and monitoring of the C node in a tiny gen_server and in turn have that in a normal supervision tree. Cheers, Robby On Thu, 28 Mar 2019 08:27 Albin Stig?, wrote: > I have a c node (written in golang) that I've written to interface with a > particular library. > > I know how to monitor it, but I'm interested to know if there's some "off > the shelf" Erlang API for supervising/restarting it or if I have to > implement it myself. > > > --Albin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Thu Mar 28 15:05:34 2019 From: john@REDACTED (John =?ISO-8859-1?Q?H=F6gberg?=) Date: Thu, 28 Mar 2019 15:05:34 +0100 Subject: [erlang-questions] Hipe and Binary - Bitstring In-Reply-To: References: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> <279725e33f4b420fd95841dbe69378d5919fba50.camel@erlang.org> Message-ID: On Wed, 2019-03-27 at 21:30 +0100, Kostis Sagonas wrote: > On the other hand, I would not call the performance difference > between > BEAM and HiPE that you observed "modest". Four times faster > execution > is IMO something that deserves a better adjective. > > Kostis Yes, it's a very impressive improvement. "Modest" was in relation to that 400x number and I should've been clearer about that, "reasonable difference" would have been better wording. On Thu, 2019-03-28 at 08:34 +0100, Oliver Bollmann wrote: > Hi John, > problem solved! > The secret is: > process_flag(min_heap_size,1024*1024*10),process_flag(min_bin_vheap_s > ize,1024*1024*10*10), > with this i get without native 1,000,000 steps: > #{gc_major_end => 8,gc_major_start => 8,gc_max_heap_size => > 0,gc_minor_end => 85,gc_minor_start => 85} > > Performance is 100 time faster, the missing factor 4 comes from hipe > itself! > > Very nice! > > Oliver I'm glad it worked out! However, you're still going to copy those ~2GB of live data when a full GC finally happens, and I think you should consider reducing that figure. Do you really need all that data in one process? On Thu, 2019-03-28 at 08:55 +0100, Frank Muller wrote: > Can someone shed some light on the difference between min_heap_size > & min_bin_vheap_size > > on how to tweak them per process to tune VM?s perfs? > > > Thanks On the process heap, off-heap binaries are essentially just a small chunk with a pointer and size, so if we decided to GC based on the process heap alone we would keep an unreachable 1GB binary alive for just as long as a 1KB one (all else equal), which is a bit suboptimal. We therefore track the combined size of all our off-heap data and GC when they exceed the "virtual binary heap size," even if the process heap nowhere near full. This "virtual binary heap" grows and shrinks much like the ordinary process heap, and the min_bin_vheap_size option is analogous to min_heap_size. In general you shouldn't need to play around with these settings, but if you have a process that you know will grow really fast then there may be something to gain by bumping its minimum heap size. I don't recommend doing this without careful consideration though. http://erlang.org/doc/efficiency_guide/processes.html#initial-heap-size /John From zxq9@REDACTED Thu Mar 28 15:16:21 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Thu, 28 Mar 2019 23:16:21 +0900 Subject: [erlang-questions] true In-Reply-To: <24277fb4-695d-b361-2c73-284a7825695d@aim.com> References: <24277fb4-695d-b361-2c73-284a7825695d@aim.com> Message-ID: <1776061.yOx8LKc8me@takoyaki> On 2019?3?27???? 18?21?36? JST Donald Steven wrote: > As someone very new to Erlang, I find it interesting to follow the > discussion on guards. > > > FWIW, the *only* thing about Erlang that drives me to distraction is the > use of the atom 'true' as a reliable "or, if the above ain't so" default > value for the expression. If only (how I wish it were so) the atom > wasn't so often completely at odds -- and at times the inverse -- of the > normal English 'read' of the if expression. Please consider > grandfathering 'true' (not to break old code) and coming up with a > logically less committed atom-of-the-future such as 'default' or > 'otherwise'. Use `case` and general matching instead of `if` and other boolean constructs and your life will be better. In Erlang boolean comparison constructs apply mostly in *range* comparisons, not general comparisons. `if` means something *very* different in Erlang than you're used to. -Craig From oliver.bollmann@REDACTED Thu Mar 28 17:55:23 2019 From: oliver.bollmann@REDACTED (Oliver Bollmann) Date: Thu, 28 Mar 2019 17:55:23 +0100 Subject: [erlang-questions] Hipe and Binary - Bitstring In-Reply-To: References: <7f23a93d-5c4b-2fd2-74f0-d445280cb830@t-online.de> <279725e33f4b420fd95841dbe69378d5919fba50.camel@erlang.org> Message-ID: <33c431e5-8a49-36a0-ded4-ae8c812ed095@t-online.de> Hi, > I'm glad it worked out! > However, you're still going to copy those ~2GB of live data when a full > GC finally happens, and I think you should consider reducing that > figure. Do you really need all that data in one process? The problem i solved with this process is to resolve nested groups, using diagraph:in_neighbours. I have 1M groups with each have at least 100,000 members. The nested level is at least 100. Loops are allowed! Question: Which group have which members =/= group. I started with ets, ets copy at each access the value, i got a lot of memory peaks, not good. I tried lists,maps and so on. I finished at the process directory, perfect, if the process died the memory is gone and using binaries only no copy of data on get. Now i use a bitmap a 1Mx1M grid which each bit is a nested group, using union,intersection to resolve the nested groups. The process runs now about 10mins and save the result in mnesia(about 5GB) and die. BTW, the persistent_term looks good, cause the grid is a onetime grid, to split in more than one process, but what i need 10M terms with about 1TB binaries, for the next step :-) Oliver On 28.03.19 15:05, John H?gberg wrote: > On Wed, 2019-03-27 at 21:30 +0100, Kostis Sagonas wrote: >> On the other hand, I would not call the performance difference >> between >> BEAM and HiPE that you observed "modest". Four times faster >> execution >> is IMO something that deserves a better adjective. >> >> Kostis > Yes, it's a very impressive improvement. "Modest" was in relation to > that 400x number and I should've been clearer about that, "reasonable > difference" would have been better wording. > > On Thu, 2019-03-28 at 08:34 +0100, Oliver Bollmann wrote: >> Hi John, >> problem solved! >> The secret is: >> process_flag(min_heap_size,1024*1024*10),process_flag(min_bin_vheap_s >> ize,1024*1024*10*10), >> with this i get without native 1,000,000 steps: >> #{gc_major_end => 8,gc_major_start => 8,gc_max_heap_size => >> 0,gc_minor_end => 85,gc_minor_start => 85} >> >> Performance is 100 time faster, the missing factor 4 comes from hipe >> itself! >> >> Very nice! >> >> Oliver > I'm glad it worked out! > > However, you're still going to copy those ~2GB of live data when a full > GC finally happens, and I think you should consider reducing that > figure. Do you really need all that data in one process? > > On Thu, 2019-03-28 at 08:55 +0100, Frank Muller wrote: >> Can someone shed some light on the difference between min_heap_size >> & min_bin_vheap_size >> >> on how to tweak them per process to tune VM?s perfs? >> >> >> Thanks > On the process heap, off-heap binaries are essentially just a small > chunk with a pointer and size, so if we decided to GC based on the > process heap alone we would keep an unreachable 1GB binary alive for > just as long as a 1KB one (all else equal), which is a bit suboptimal. > > We therefore track the combined size of all our off-heap data and GC > when they exceed the "virtual binary heap size," even if the process > heap nowhere near full. This "virtual binary heap" grows and shrinks > much like the ordinary process heap, and the min_bin_vheap_size option > is analogous to min_heap_size. > > In general you shouldn't need to play around with these settings, but > if you have a process that you know will grow really fast then there > may be something to gain by bumping its minimum heap size. I don't > recommend doing this without careful consideration though. > > http://erlang.org/doc/efficiency_guide/processes.html#initial-heap-size > > /John > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Gr??e Oliver Bollmann -------------- next part -------------- An HTML attachment was scrubbed... URL: From areege.alzubaidi@REDACTED Thu Mar 28 19:25:08 2019 From: areege.alzubaidi@REDACTED (Areege Al Zubaidi) Date: Thu, 28 Mar 2019 18:25:08 +0000 Subject: [erlang-questions] Code BEAM STO 19 - one week left to get early bird tickets! Message-ID: Hi all, It?s Code BEAM STO time! If you?re not already aware, Code BEAM STO is the reincarnation of the much loved Erlang User Conference, the biggest, longest running, and best Erlang and Elixir conference in the world. It?s back this May with a host of brilliant speakers and trainers to share, learn, inspire. You can currently get tickets at the early bird rate , until 05 April! If you?re interested in training too, you can get 10% off of your conference ticket via a special bundled ticket at checkout. Code BEAM STO offers training courses and certification , as well as a host of talks from leaders and innovators in the community, including: - Madeleine Malmsten - Boyd Multerer - Peter van Roy - Ingela Anderton Andin - Ayanda Dube - Viktoria Fordos - Kenji Rikitake - Anayeli Malvaez - Thomas Arts - ? and more! Learn more about the conference, and the 2019 speakers: https://codesync.global/conferences/code-beam-sto-2019/#speakers What: Code BEAM STO 2019 When: 16-17 May 2019 Where: M?nchenbryggeriet, Stockholm Sweden How to attend: - Attend the conference Secure an early bird rate ticket to the conference by Friday 05 April. You can find out more and register here . - Diversity ticket We are pleased to announce that Code BEAM STO 2019 is implementing a diversity scheme . The goal of the programme is to increase the diversity of attendees and offer support to those in the tech community who would not otherwise be able to attend the conference. Applications are open now and close on 21 April. - Student tickets Code BEAM STO offers a 50% discount to students. To learn more, email info@REDACTED from your academic email address to get a unique discount code. - Sponsor If you want your company to join Klarna and support the BEAM community, please do not hesitate to contact us about community support and sponsorship. If you have any further questions, please don?t hesitate to let me know, I hope to see you in Stockholm, the home of Erlang! Areege -- *Areege Al Zubaidi* *Conferences Marketing Executive* T: +44 (0) 2076550332 W: www.codesync.global A: Erlang Solutions Ltd, The Loom,14 Gower's Walk, London, E1 8PY *Code Sync & Erlang Solutions Conferences* ElixirConf EU - Prague - 8-9 April 2019 Code BEAM STO - Stockholm - 16-17 May 2019 Code Elixir LDN - London - 18 July 2019 Code Mesh LDN - London - 7-8 November 2019 Lambda Days - Krak?w - 13-14 February 2020 *Erlang Solutions and Code Sync care about your data and privacy; please find all details about the basis for communicating with you and the way we process your data in our Privacy Policy . You can update your email preferences or opt-out from receiving marketing emails here .* -------------- next part -------------- An HTML attachment was scrubbed... URL: From krzysztof.jurewicz@REDACTED Thu Mar 28 21:46:47 2019 From: krzysztof.jurewicz@REDACTED (Krzysztof Jurewicz) Date: Thu, 28 Mar 2019 21:46:47 +0100 Subject: [erlang-questions] [ANN] Ercoin 0.1.0 Message-ID: <87lg0yrako.fsf@gmail.com> Ercoin 0.1.0 has been released. The test network is scheduled to launch at 6 P.M. UTC on Friday, 29 March. As the version number suggests, this is not a stable release, which means that we are not in production yet. The process of achieving version 1.0 and starting the main network will consist of several areas of activity, including: ? finding bugs on the test network and improving the code; ? working towards adoption by exchanges; ? improving documentation; ? marketing. When a satisfactory level in these areas is achieved, it is planned to announce Initial Burn Offering (IBO) ? initial set of ercoins is going to be distributed proportionally to the amount of blackcoins burnt in some time window. Some links: ? Website: https://ercoin.tech ? Main repository: https://gitlab.com/Ercoin/ercoin ? Whitepaper: https://ercoin.tech/whitepaper.html ? Browser wallet: https://ercoin.gitlab.io/ercoin-browser-wallet/ Comparing the code with the version released after the initial announcement ( http://erlang.org/pipermail/erlang-questions/2017-July/092980.html ), it should be better structured, more accessible. Feedback is welcome. -- Krzysztof From bjorn@REDACTED Fri Mar 29 10:41:20 2019 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 29 Mar 2019 10:41:20 +0100 Subject: [erlang-questions] Guards syntax for multiple values In-Reply-To: References: <8917B7B6-5150-4A42-A810-36A7FC80F750@erlang-solutions.com> Message-ID: On Tue, Mar 26, 2019 at 3:51 PM Florent Gallaire wrote: > thanks a lot for your attention to this thread. > > > Yes, that would work. As long as the list is a literal, the compiler > > can rewrite it in a smarter way to reduce the complexity to O(log(N)), > > which would be acceptable. > > Very happy to hear that it's technicaly feasible and that the > complexity is acceptable. > I should probably have pointed out in my answer that I don't recommend implementing a new is_member/2 guard. Just because it is possible doesn't mean that it is a good idea. In informal discussions in the OTP team, it seems that we prefer OR patterns over is_member/2 because OR patterns would be applicable in more situations. In fact, if someone would write a good EEP for OR patterns, it is possible that it could be approved and implemented as early as in the OTP 23 release. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From ingela.andin@REDACTED Fri Mar 29 17:17:59 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Fri, 29 Mar 2019 17:17:59 +0100 Subject: [erlang-questions] OTP 22 socket module In-Reply-To: References: Message-ID: Hi! Den ons 27 mars 2019 kl 08:20 skrev Andreas Schultz < andreas.schultz@REDACTED>: > Hi, > > Is a {active, N} like delivery of data planed for the new socket or will > polling the recv methods be the only way the receive data? What about > non-blocking connect and accept? > > It is planned to have behaviours that implement the active behaviour but not as part of the socket module. The socket module should be the primitives. > My preference would be to get an active notification when data is > available for receive and another one when when a non-blocking write is > possible. Sending and reception should then be left to the caller. > Same goes for non-block accept and connect. Call accept/connect with a > async option and get some message when the procedures finishes. > > I do realize that all this could be build with a gen_server/gen_statem > around socket, so I guess the real question is does it make sense to start > build such a wrapper or are the plans to make async functions part of the > socket module? > > Maybe Michael will have some more comments. > Thanks > Andreas > -- > -- > Dipl.-Inform. Andreas Schultz > > ----------------------- enabling your networks ---------------------- > Travelping GmbH Phone: +49-391-81 90 99 0 > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > 39108 Magdeburg Email: info@REDACTED > GERMANY Web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > --------------------------------------------------------------------- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Fri Mar 29 17:22:13 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Fri, 29 Mar 2019 17:22:13 +0100 Subject: [erlang-questions] State of use_srtp ext in DTLS and TLS 1.3 support. In-Reply-To: References: Message-ID: Hi! Den ons 20 mars 2019 kl 09:33 skrev Albin Stig? : > I looked at GnuTLS and they have the option to use a pull and a push > callback function when the SSL stack wants data and wants to send data > respectively. I think it's a nice idea because it decouples the SSL stack > completely from the underlying socket. It seems this is sometimes > desirable.. > > The "active once" emulation between the DTLS statemachine and the demultiplexer process would be like pull. But we do not do push as that would be a bottleneck. Regards Ingela Erlang/OTP team - Ericsson AB > > --Albin > > On Sat, Mar 16, 2019, 11:53 Albin Stig? wrote: > >> True... A callback receiving {udp, Socket, IP, InPortNo, Packet} and >> deciding whether to use the the ssl demuxer or pass it on to another >> process might be enough. The STUN packets could come from any IP >> unsolicited when doing ICE nat traversal path discovery (as described by >> WebRTC). >> >> >> --Albin >> >> On Sat, Mar 16, 2019, 11:00 Ingela Andin wrote: >> >>> >>> Hi! >>> >>> Den l?r 16 mars 2019 kl 10:21 skrev Albin Stig? : >>> >>>> Ok sorry about the confusion. What's needed is a second level of >>>> demultiplexing after the first... But I realize now this will be very >>>> difficult to achieve with the current implementation because that relies on >>>> one socket per connection. Otherwise you won't know which process to send >>>> the none DTLS packets to... Or am i missing something? >>>> >>>> >>> You will have to extend the demultiplexor process so that it sends >>> packets to different processes depending on some criteria. It is ok to >>> change the internals of >>> the process if that is necessary. But we like the basic functionality to >>> be the framework of the process and then add extended features mainly >>> through callbacks. >>> >>> Regards Ingela Erlang/OTP Team - Ericsson AB >>> >>> >>>> I might have to attempt a separate DTLS use_srtp app just for this >>>> application... >>>> >>>> >>>> --Albin >>>> >>>> On Sat, Mar 16, 2019, 09:05 Ingela Andin >>>> wrote: >>>> >>>>> Hi Albin! >>>>> >>>>> Den fre 15 mars 2019 kl 17:25 skrev Albin Stig? >>>> >: >>>>> >>>>>> Ok thanks! >>>>>> >>>>>> Maybe demultiplexing should just be default when the use_srtp >>>>>> extension is used, since that's how it's supposed to be used anyway... or a >>>>>> rfc7983_demux option... >>>>>> >>>>>> >>>>> ? A DTLS server will always have a demultiplexing process as UDP does >>>>> not have a connection concept. >>>>> >>>>> >>>>> >>>>>> What's the name in the #state that holds the pid of the controlling >>>>>> process (the process that receives {ssl.. data)? >>>>>> >>>>>> >>>>> It is part of the "user" in the state of the TLS/DTLS connection >>>>> process. You should not have to care. You set the controlling process with >>>>> ssl:controlling_process/2. >>>>> >>>>> I guess what you care about is the demultiplexing process and which >>>>> Pid it sends the incoming UDP packets to. All the code is defined in the >>>>> dtls_packet_demux.erl >>>>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>> >>>>> >>>>>> --Albin >>>>>> >>>>>> On Fri, Mar 15, 2019, 17:01 Ingela Andin >>>>>> wrote: >>>>>> >>>>>>> Hi Albin! >>>>>>> >>>>>>> There is the handshake_compleation option together with the >>>>>>> handshake_continue functions that let you pause the handshake and retrieve >>>>>>> the hello extensions and possibly provide more options before >>>>>>> continuing the handshake. >>>>>>> >>>>>>> Den fre 15 mars 2019 kl 13:20 skrev Albin Stig? < >>>>>>> albin.stigo@REDACTED>: >>>>>>> >>>>>>>> Am I right to assume this is the single point of udp receive for >>>>>>>> dtls? >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/erlang/otp/blob/702ef9b0fa0a9b7345e3b397f23d8a76a2ac4df2/lib/ssl/src/dtls_connection.erl#L906 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> If you want to multiplex UDP packets to other processes than the >>>>>>> DTLS connection process that is not encrypted under DTLS you >>>>>>> should not look at the DTLS connection process but at the >>>>>>> >>>>>>> >>>>>>> https://github.com/erlang/otp/blob/master/lib/ssl/src/dtls_packet_demux.erl#L140 >>>>>>> >>>>>>> Regards Ingela Erlang/OTP team Ericsson AB >>>>>>> >>>>>>> >>>>>>>> --Albin >>>>>>>> >>>>>>>> On Fri, Mar 15, 2019 at 1:10 PM Albin Stig? >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > There're all kinds of abuse of DTLS it seems :-) >>>>>>>> > >>>>>>>> > I still think the use cases are orthogonal though... Demuxing as >>>>>>>> > described in https://tools.ietf.org/html/rfc7983 is trivial and >>>>>>>> > requires no state. A demux_fun would solve that problem. >>>>>>>> > >>>>>>>> > DTLS packets wrapped in extra headers with the need of state >>>>>>>> > information is much more complicated... Maybe what is needed are >>>>>>>> two >>>>>>>> > different approaches? Especially since you will need forward and >>>>>>>> > backwards transform..? >>>>>>>> > >>>>>>>> > Ingela, is there already an API for getting the key data from >>>>>>>> use_srtp >>>>>>>> > (when implemented) or will that have to be added also? >>>>>>>> > >>>>>>>> > >>>>>>>> > --Albin >>>>>>>> > >>>>>>>> > On Fri, Mar 15, 2019 at 11:35 AM Andreas Schultz >>>>>>>> > wrote: >>>>>>>> > > >>>>>>>> > > Albin Stig? schrieb am Do., 14. M?rz >>>>>>>> 2019 um 18:49 Uhr: >>>>>>>> > >> >>>>>>>> > >> Hi Ingela and Andreas, >>>>>>>> > >> >>>>>>>> > >> > No, that's not enough. Some protocols put additional headers >>>>>>>> in front of the DTLS packets. So there needs to be a way to strip >>>>>>>> > >> > headers on Rx and add it on Tx (with session information if >>>>>>>> needed). >>>>>>>> > >> >>>>>>>> > >> I have to admit I have not encountered this practice... do you >>>>>>>> have a >>>>>>>> > >> particular protocol in mind or is it a part of dtls-srtp I have >>>>>>>> > >> missed? One could argue that if you add additional headers and >>>>>>>> > >> maintain some kind of state you are actually dealing with a >>>>>>>> different >>>>>>>> > >> transport layer...? >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > CAPWAP is doing that >>>>>>>> https://tools.ietf.org/html/rfc5415#section-4.1 >>>>>>>> > > >>>>>>>> > >> I would very much like a way where filtered out packages were >>>>>>>> sent to >>>>>>>> > >> the controlling process as {udp,Socket instead of {ssl, >>>>>>>> Socket... The >>>>>>>> > >> question in the latter case is if Socket should be the ssl >>>>>>>> socket or >>>>>>>> > >> the transport socket. Messing with the transport socket could >>>>>>>> be >>>>>>>> > >> detrimental to dtls. >>>>>>>> > >> >>>>>>>> > >> One could also extend the filter_fun idea to a transform_fun >>>>>>>> where one >>>>>>>> > >> could transform in packet in addition to demultiplexing, but >>>>>>>> like I >>>>>>>> > >> said, I think additional headers to dtls packets belong to the >>>>>>>> > >> transport layer. >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > Passing a State in and out of such a transform would be good. >>>>>>>> > > >>>>>>>> > > Andreas >>>>>>>> > > >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> I don't have in-depth knowledge of the ssl app but it seems >>>>>>>> adding a >>>>>>>> > >> filter_fun would be almost trivial? >>>>>>>> > >> >>>>>>>> > >> > Maybe transport_send as compared to the existing >>>>>>>> transport_accept. Would only work for DTLS. >>>>>>>> > >> >>>>>>>> > >> Well either that or some way of accessing the transport >>>>>>>> socket, but >>>>>>>> > >> transport_send for sure plays well with existing API! >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> --Albin >>>>>>>> > >> >>>>>>>> > >> On Thu, Mar 14, 2019 at 6:22 PM Ingela Andin < >>>>>>>> ingela.andin@REDACTED> wrote: >>>>>>>> > >> > >>>>>>>> > >> > Hi! >>>>>>>> > >> > >>>>>>>> > >> > Andreas, see comment below. >>>>>>>> > >> > >>>>>>>> > >> > Den tors 14 mars 2019 kl 17:38 skrev Andreas Schultz < >>>>>>>> andreas.schultz@REDACTED>: >>>>>>>> > >> >> >>>>>>>> > >> >> Hi >>>>>>>> > >> >> >>>>>>>> > >> >> Ingela Andin schrieb am Do., 14. >>>>>>>> M?rz 2019 um 17:34 Uhr: >>>>>>>> > >> >>> >>>>>>>> > >> >>> Hi Albin! >>>>>>>> > >> >>> >>>>>>>> > >> >>> Den tors 14 mars 2019 kl 15:38 skrev Albin Stig? < >>>>>>>> albin.stigo@REDACTED>: >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> Hi Ingela, >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> Thanks for the quick reply! >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> While cb_info certainly is one way of doing it, it feels >>>>>>>> a bit >>>>>>>> > >> >>>> complicated... specifically if switching between active >>>>>>>> and passive >>>>>>>> > >> >>>> mode. Not sure if ssl ever use passive mode internally? >>>>>>>> Demuxing is a >>>>>>>> > >> >>>> different use case, I think.. >>>>>>>> > >> >>>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> The cb_info is intended so that you may replace the >>>>>>>> transport layer, with most likely, an SCTP transport (can be done for both >>>>>>>> TLS and DTLS although there are some extensions needed for the DLTS version >>>>>>>> to work properly). I think some people also use it to implement WebSockets. >>>>>>>> > >> >>> >>>>>>>> > >> >>> ssl internally uses active n for TLS (since latest >>>>>>>> release) and active once for DTLS (we might change it) but an OTP >>>>>>>> supervised process will not use passive recv as we do not want it to block. >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> Something that IMHO would be fantastic and simple (?) >>>>>>>> would be a >>>>>>>> > >> >>>> dtls_filter_fun option. If true packet is passed up the >>>>>>>> ssl stack, >>>>>>>> > >> >>>> otherwise passed on like a normal udp packet! >>>>>>>> > >> >>>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> Sounds reasonable. Otherwise sent to some other Erlang >>>>>>>> process than the "DTLS-connection" process that is. >>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>>> > >> >> No, that's not enough. Some protocols put additional >>>>>>>> headers in front of the DTLS packets. So there needs to be a way to strip >>>>>>>> headers on Rx and add it on Tx (with session information if needed). >>>>>>>> > >> >> >>>>>>>> > >> > >>>>>>>> > >> > Maybe the demultiplexor process can have a "packet mode" >>>>>>>> that is set to "no packet" default and needs a callback handler for >>>>>>>> anything else? >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>>> > >> > >>>>>>>> > >> >> >>>>>>>> > >> >> Andreas >>>>>>>> > >> >> >>>>>>>> > >> >>> >>>>>>>> > >> >>> >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> There's an RFC regarding the demultiplexing of SRTP/DTLS, >>>>>>>> it basically >>>>>>>> > >> >>>> boils down to looking at the first byte of the packet, if >>>>>>>> it's >>>>>>>> > >> >>>> [20..63] it should be treated as DTLS otherwise something >>>>>>>> else. So >>>>>>>> > >> >>>> this would be absolutely trivial to implement if there >>>>>>>> was a >>>>>>>> > >> >>>> dtls_filter_fun... >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> https://tools.ietf.org/html/rfc7983 >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> Then of course there also has to be a way to bypass DTLS >>>>>>>> when sending >>>>>>>> > >> >>>> data... maybe send/3 (Socket, Data, Options)... >>>>>>>> > >> >>>> >>>>>>>> > >> >>> >>>>>>>> > >> >>> Maybe transport_send as compared to the existing >>>>>>>> transport_accept. Would only work for DTLS. >>>>>>>> > >> >>> >>>>>>>> > >> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>>> > >> >>> >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> What do you think? >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> --Albin >>>>>>>> > >> >>>> >>>>>>>> > >> >>>> On Thu, Mar 14, 2019 at 1:52 PM Ingela Andin < >>>>>>>> ingela.andin@REDACTED> wrote: >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > Hi! >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > Den tors 14 mars 2019 kl 12:29 skrev Albin Stig? < >>>>>>>> albin.stigo@REDACTED>: >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> Hi, >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> I'm working on an Erlang WebRTC peer client (to send >>>>>>>> audio/video to >>>>>>>> > >> >>>> >> the browser). >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> WebRTC requires dtls-srtp and that in turn requires: >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> 1. The use_srtp extension for key exchange. >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > We will be implementing this as part of TLS-1.3 that we >>>>>>>> are currently working on, and we will have something runnable for OTP-22.0, >>>>>>>> although we are not promising that it will complete or that use_srtp will >>>>>>>> be part of OTP-22.0 >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> 2. Multiplexing of stun/turn/srtp packets on the >>>>>>>> socket. >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> I know there's been work towards use_srtp and it's >>>>>>>> even in the source, >>>>>>>> > >> >>>> >> but commented out. Ingela has been working on it for >>>>>>>> OTP 2, I believe, >>>>>>>> > >> >>>> >> is there an ETA on this feature? >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> Is multiplexing on the DTLS socket already possible >>>>>>>> using the cb_info? >>>>>>>> > >> >>>> >> Has anyone tried that? >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> >>>>>>>> http://erlang.org/pipermail/erlang-questions/2018-October/096457.html >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > The code has been written to make such extensions >>>>>>>> possible. There might be a need for more callbacks. I have not really had >>>>>>>> time to work on that as >>>>>>>> > >> >>>> > TLS-1.3, optimizations and erlang distribution over TLS >>>>>>>> has been prioritized higher. Suggestions are welcome. >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> > >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> >>>>>>>> > >> >>>> >> --Albin >>>>>>>> > >> >>>> >> _______________________________________________ >>>>>>>> > >> >>>> >> erlang-questions mailing list >>>>>>>> > >> >>>> >> erlang-questions@REDACTED >>>>>>>> > >> >>>> >> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>>> > >> >>> >>>>>>>> > >> >>> _______________________________________________ >>>>>>>> > >> >>> erlang-questions mailing list >>>>>>>> > >> >>> erlang-questions@REDACTED >>>>>>>> > >> >>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>>> > >> >> >>>>>>>> > >> >> -- >>>>>>>> > >> >> -- >>>>>>>> > >> >> Dipl.-Inform. Andreas Schultz >>>>>>>> > >> >> >>>>>>>> > >> >> ----------------------- enabling your networks >>>>>>>> ---------------------- >>>>>>>> > >> >> Travelping GmbH Phone: +49-391-81 90 >>>>>>>> 99 0 >>>>>>>> > >> >> Roentgenstr. 13 Fax: +49-391-81 90 >>>>>>>> 99 299 >>>>>>>> > >> >> 39108 Magdeburg Email: >>>>>>>> info@REDACTED >>>>>>>> > >> >> GERMANY Web: >>>>>>>> http://www.travelping.com >>>>>>>> > >> >> >>>>>>>> > >> >> Company Registration: Amtsgericht Stendal Reg No.: >>>>>>>> HRB 10578 >>>>>>>> > >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>>>>>> DE236673780 >>>>>>>> > >> >> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> > > >>>>>>>> > > -- >>>>>>>> > > -- >>>>>>>> > > Dipl.-Inform. Andreas Schultz >>>>>>>> > > >>>>>>>> > > ----------------------- enabling your networks >>>>>>>> ---------------------- >>>>>>>> > > Travelping GmbH Phone: +49-391-81 90 99 0 >>>>>>>> > > Roentgenstr. 13 Fax: +49-391-81 90 99 299 >>>>>>>> > > 39108 Magdeburg Email: info@REDACTED >>>>>>>> > > GERMANY Web: >>>>>>>> http://www.travelping.com >>>>>>>> > > >>>>>>>> > > Company Registration: Amtsgericht Stendal Reg No.: HRB >>>>>>>> 10578 >>>>>>>> > > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: >>>>>>>> DE236673780 >>>>>>>> > > >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Sat Mar 30 06:45:08 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Sat, 30 Mar 2019 18:45:08 +1300 Subject: [erlang-questions] true In-Reply-To: <1776061.yOx8LKc8me@takoyaki> References: <24277fb4-695d-b361-2c73-284a7825695d@aim.com> <1776061.yOx8LKc8me@takoyaki> Message-ID: Just for the record, every functional programming language I know that *has* guards uses true just the way Erlang does. This actually goes back all the way to Lisp, where "if" had no "else". You wrote (COND (g1 b1) ... (gn bn) (T be)), where T was (and remains) Lisp's version of 'true'. Clean and Haskell allow 'otherwise' as a synonym of 'True'. I stick with 'True' because it is easier for me to understand. On Fri, 29 Mar 2019 at 03:16, wrote: > On 2019?3?27???? 18?21?36? JST Donald Steven wrote: > > As someone very new to Erlang, I find it interesting to follow the > > discussion on guards. > > > > > > FWIW, the *only* thing about Erlang that drives me to distraction is the > > use of the atom 'true' as a reliable "or, if the above ain't so" default > > value for the expression. If only (how I wish it were so) the atom > > wasn't so often completely at odds -- and at times the inverse -- of the > > normal English 'read' of the if expression. Please consider > > grandfathering 'true' (not to break old code) and coming up with a > > logically less committed atom-of-the-future such as 'default' or > > 'otherwise'. > > Use `case` and general matching instead of `if` and other boolean > constructs > and your life will be better. > > In Erlang boolean comparison constructs apply mostly in *range* > comparisons, > not general comparisons. `if` means something *very* different in Erlang > than you're used to. > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t6sn7gt@REDACTED Sat Mar 30 12:41:38 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Sat, 30 Mar 2019 07:41:38 -0400 Subject: [erlang-questions] true In-Reply-To: References: <24277fb4-695d-b361-2c73-284a7825695d@aim.com> <1776061.yOx8LKc8me@takoyaki> Message-ID: <69780c7b-6193-ffe4-fc7f-8968560d16e9@aim.com> I didn't know that about other functional languages.? As a retiree, I just program for fun and have done some in Haskell, whence I picked up 'otherwise', which I much prefer. On 3/30/2019 1:45 AM, Richard O'Keefe wrote: > Just for the record, every functional programming > language I know that *has* guards uses true just > the way Erlang does. This actually goes back all > the way to Lisp, where "if" had no "else".? You > wrote (COND (g1 b1) ... (gn bn) (T be)), where T > was (and remains) Lisp's version of 'true'. > Clean and Haskell allow 'otherwise' as a synonym > of 'True'.? I stick with 'True' because it is > easier for me to understand. > > On Fri, 29 Mar 2019 at 03:16, > > wrote: > > On 2019?3?27???? 18?21?36? JST Donald Steven wrote: > > As someone very new to Erlang, I find it interesting to follow the > > discussion on guards. > > > > > > FWIW, the *only* thing about Erlang that drives me to > distraction is the > > use of the atom 'true' as a reliable "or, if the above ain't so" > default > > value for the expression.? If only (how I wish it were so) the atom > > wasn't so often completely at odds -- and at times the inverse > -- of the > > normal English 'read' of the if expression.? Please consider > > grandfathering 'true' (not to break old code) and coming up with a > > logically less committed atom-of-the-future such as 'default' or > > 'otherwise'. > > Use `case` and general matching instead of `if` and other boolean > constructs > and your life will be better. > > In Erlang boolean comparison constructs apply mostly in *range* > comparisons, > not general comparisons. `if` means something *very* different in > Erlang > than you're used to. > > -Craig > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From getonga2018@REDACTED Sat Mar 30 14:12:46 2019 From: getonga2018@REDACTED (=?UTF-8?B?MTjlubTmoqbphpI=?=) Date: Sat, 30 Mar 2019 21:12:46 +0800 Subject: [erlang-questions] erlang:open_port/2 return eaddrinuse while running with docker, in open network mode. Message-ID: I use netlink(https://github.com/Feuerlabs/netlink) in my docker container, which use erlang:open_port/2. It works fine on my linux host, but something goes wrong in the docker container with docker open network. I build a simple project in the github, https://github.com/getong/netlink_docker , you can check it out. The things goes wrong when the second container starts with the same image. As https://github.com/getong/netlink_docker#error-message show: application: netlink exited: {{shutdown, {failed_to_start_child,netlink, {eaddrinuse, [{erlang,open_port, [{spawn_driver,"netlink_drv 0"},[binary]], []}, {netlink,init_drv,2, [{file, "/build_temp/_build/default/lib/netlink/src/netlink.erl"}, {line,207}]}, {gen_server,init_it,2, [{file,"gen_server.erl"},{line,374}]}, {gen_server,init_it,6, [{file,"gen_server.erl"},{line,342}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,249}]}]}}}, {netlink_app,start,[normal,[]]}} type: permanent Kernel pid terminated (application_controller) ({application_start_failure,netlink,{{shutdown,{failed_to_start_child,netlink,{eaddrinuse,[{erlang,open_port,[{spawn_driver,"netlink_drv 0"},[binary]],[] -------------- next part -------------- An HTML attachment was scrubbed... URL: