From sperber@REDACTED Mon Apr 1 08:24:25 2019 From: sperber@REDACTED (Michael Sperber) Date: Mon, 01 Apr 2019 08:24:25 +0200 Subject: [erlang-questions] Call for Contributions: Summer BOB 2019 [Aug 21, Berlin, deadline May 17] Message-ID: Erlang contributions extremely welcome at BOB! Moreover, the Erlang workshop will be right around the corner! Summer BOB Conference 2019 "What happens when we use what's best for a change?" http://bobkonf.de/2019-summer/cfc.html Berlin, August 21 co-located with ICFP 2019 Call for Contributions Deadline: May 17, 2019 You are engaged in software development or software architecture, and have an interesting story to tell about an advanced tools, technique, language or technology that you're using? Or a gnarly problems that these tools fail to address but should? Summer BOB is a one-time-only event, in the spirit of the spectacular Winter BOB. The International Conference on Functional Programming is coming to town, and Summer BOB will be right in the middle of it, on the last day of ICFP proper, prior to all the workshops. Summer BOB will feature two tracks: one from practitioners, and one from researchers, and foster communication and cross-pollination between these communities. If you share our vision and want to contribute, submit a proposal for a talk! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - ? everything really that isn?t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We're especially interested in experience reports. Other topics are also relevant, e.g.: - demos and how-tos - reports on problems that cutting-edge languages and tools should address but don't - overviews of a given field Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, ?) - Don't be confused: The system calls a submission event. Submit here ----------- https://bobcfc.active-group.de/bob2019-summer/cfp Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Shepherding The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: May 17, 2019 - Notification: May 31, 2019 - Program: June 14, 2019 Program Committee ----------------- - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni T?bingen - Peter Thiemann, Uni Freiburg More information here: http://bobkonf.de/2019-summer/programmkomitee.html From eckard.brauer@REDACTED Mon Apr 1 13:08:48 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Mon, 1 Apr 2019 13:08:48 +0200 Subject: [erlang-questions] Web toolkit, N2O guide Message-ID: <20190401130825.6b72c6b1@gmx.de> Hello, as I will have to develop a little web application for serving >~80 % pure static and < 20 % dynamic (DB frontend, sessoins - DB choice is still free) content, I thought of using N2O as the toolkit of choice. Some questions arise from that: * Are there better alternatives to N2O for that? * Is there a (preferrably step by step) guide for beginners available, as most of the tutorials I found seem outdated for years? Thanks in advance for hints! Eckard -- :) From marc@REDACTED Mon Apr 1 14:55:19 2019 From: marc@REDACTED (Marc Worrell) Date: Mon, 1 Apr 2019 14:55:19 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: <20190401130825.6b72c6b1@gmx.de> References: <20190401130825.6b72c6b1@gmx.de> Message-ID: Hi Eckard, You can also use Zotonic CMS (http://zotonic.org/ ) Static files can be served using `controller_static_pages` or directly as assets from their the `lib` directory, or as templates from the `templates/static` directory. The nice thing with using Zotonic for your site is that you also get: * Rich and very flexible templating system * Full content management environment * Multi-lingual * Access control modules * Email handling (send & receive) * Timezone handling * Module system * etc. etc. etc. Zotonic uses PostgreSQL for its database. Currently the 0.x version is the ?stable? branch. We are working towards a 1.x (really soon now). The 1.x will have deep MQTT integration. Cheers, Marc > On 1 Apr 2019, at 13:08, Eckard Brauer wrote: > > Hello, > > as I will have to develop a little web application for serving >~80 % > pure static and < 20 % dynamic (DB frontend, sessoins - DB choice is > still free) content, I thought of using N2O as the toolkit of choice. > Some questions arise from that: > > * Are there better alternatives to N2O for that? > > * Is there a (preferrably step by step) guide for beginners available, > as most of the tutorials I found seem outdated for years? > > Thanks in advance for hints! > Eckard > > -- > :) > _______________________________________________ > 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 Mon Apr 1 15:45:05 2019 From: otp@REDACTED (Erlang/OTP) Date: Mon, 1 Apr 2019 15:45:05 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.3 Released Message-ID: <20190401134505.GA2745@erix.ericsson.se> Patch Package: OTP 21.3.3 Git Tag: OTP-21.3.3 Date: 2019-04-01 Trouble Report Id: OTP-15704, OTP-15706, OTP-15709 Seq num: ERIERL-336, ERIERL-337 System: OTP Release: 21 Application: erts-10.3.2, kernel-6.3.1, stdlib-3.8.1 Predecessor: OTP 21.3.2 Check out the git tag OTP-21.3.3, 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.2 ----------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.3.2 application *cannot* 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-15704 Application(s): erts Fixed a bug in seq_trace:reset_trace/0 that could crash the emulator. OTP-15709 Application(s): erts Related Id(s): ERIERL-337 Fixed bug in process_info(reductions) causing it to sometimes return invalid results. Full runtime dependencies of erts-10.3.2: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- kernel-6.3.1 ---------------------------------------------------- --------------------------------------------------------------------- Note! The kernel-6.3.1 application *cannot* 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-15706 Application(s): kernel, stdlib Related Id(s): ERIERL-336 Fixed a performance regression when reading files opened with the compressed flag. Full runtime dependencies of kernel-6.3.1: erts-10.2.5, sasl-3.0, stdlib-3.5 --------------------------------------------------------------------- --- stdlib-3.8.1 ---------------------------------------------------- --------------------------------------------------------------------- The stdlib-3.8.1 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15706 Application(s): kernel, stdlib Related Id(s): ERIERL-336 Fixed a performance regression when reading files opened with the compressed flag. Full runtime dependencies of stdlib-3.8.1: compiler-5.0, crypto-3.3, erts-10.0, kernel-6.0, sasl-3.0 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From vladdu55@REDACTED Mon Apr 1 16:46:33 2019 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 1 Apr 2019 16:46:33 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: References: <20190401130825.6b72c6b1@gmx.de> Message-ID: Hi! Should the link be to http://zotonic.com? The org one goes to the default page of an unitialized server. best regards, Vlad On Mon, Apr 1, 2019 at 2:55 PM Marc Worrell wrote: > Hi Eckard, > > You can also use Zotonic CMS (http://zotonic.org/) > > Static files can be served using `controller_static_pages` or directly as > assets from their > the `lib` directory, or as templates from the `templates/static` directory. > > The nice thing with using Zotonic for your site is that you also get: > > * Rich and very flexible templating system > * Full content management environment > * Multi-lingual > * Access control modules > * Email handling (send & receive) > * Timezone handling > * Module system > * etc. etc. etc. > > Zotonic uses PostgreSQL for its database. > > Currently the 0.x version is the ?stable? branch. > We are working towards a 1.x (really soon now). > > The 1.x will have deep MQTT integration. > > Cheers, Marc > > > On 1 Apr 2019, at 13:08, Eckard Brauer wrote: > > Hello, > > as I will have to develop a little web application for serving >~80 % > pure static and < 20 % dynamic (DB frontend, sessoins - DB choice is > still free) content, I thought of using N2O as the toolkit of choice. > Some questions arise from that: > > * Are there better alternatives to N2O for that? > > * Is there a (preferrably step by step) guide for beginners available, > as most of the tutorials I found seem outdated for years? > > Thanks in advance for hints! > Eckard > > -- > :) > _______________________________________________ > 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 marc@REDACTED Mon Apr 1 16:57:57 2019 From: marc@REDACTED (Marc Worrell) Date: Mon, 1 Apr 2019 16:57:57 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: References: <20190401130825.6b72c6b1@gmx.de> Message-ID: <74BC850D-2270-4E1E-B6EA-DC195C4E1214@worrell.nl> Ah yes, http://zotonic.com One more thing to check for the new site :-) Thanks, Marc > On 1 Apr 2019, at 16:46, Vlad Dumitrescu wrote: > > Hi! > > Should the link be to http://zotonic.com ? The org one goes to the default page of an unitialized server. > > best regards, > Vlad > > > On Mon, Apr 1, 2019 at 2:55 PM Marc Worrell > wrote: > Hi Eckard, > > You can also use Zotonic CMS (http://zotonic.org/ ) > > Static files can be served using `controller_static_pages` or directly as assets from their > the `lib` directory, or as templates from the `templates/static` directory. > > The nice thing with using Zotonic for your site is that you also get: > > * Rich and very flexible templating system > * Full content management environment > * Multi-lingual > * Access control modules > * Email handling (send & receive) > * Timezone handling > * Module system > * etc. etc. etc. > > Zotonic uses PostgreSQL for its database. > > Currently the 0.x version is the ?stable? branch. > We are working towards a 1.x (really soon now). > > The 1.x will have deep MQTT integration. > > Cheers, Marc > > >> On 1 Apr 2019, at 13:08, Eckard Brauer > wrote: >> >> Hello, >> >> as I will have to develop a little web application for serving >~80 % >> pure static and < 20 % dynamic (DB frontend, sessoins - DB choice is >> still free) content, I thought of using N2O as the toolkit of choice. >> Some questions arise from that: >> >> * Are there better alternatives to N2O for that? >> >> * Is there a (preferrably step by step) guide for beginners available, >> as most of the tutorials I found seem outdated for years? >> >> Thanks in advance for hints! >> Eckard >> >> -- >> :) >> _______________________________________________ >> 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 andres.mareca@REDACTED Mon Apr 1 18:49:48 2019 From: andres.mareca@REDACTED (Andres Mareca) Date: Mon, 1 Apr 2019 18:49:48 +0200 Subject: [erlang-questions] Rebar3 plugin for transitive dependencies erlang-elixir Message-ID: Hello, I have read some threads related to erlang-elixir apps and libraries interoperability. In my company, Coowry, we have code written in Erlang and Elixir and we have some code already factored in both languages. We are using our own plugin that I implemented. The most important feature of the plugin is that allows to manage transitive dependencies. I have been working to make the plugin public and now I would like to share it with you: https://github.com/Supersonido/rebar3_elixir I hope it helps others. Anything do not hesitate to ask. A greeting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From t@REDACTED Mon Apr 1 19:44:58 2019 From: t@REDACTED (Tristan Sloughter) Date: Mon, 01 Apr 2019 13:44:58 -0400 Subject: [erlang-questions] =?utf-8?q?Rebar3_plugin_for_transitive_depende?= =?utf-8?q?ncies=09erlang-elixir?= In-Reply-To: References: Message-ID: <01f30ecf-249b-43be-89d7-e9d657357fb8@www.fastmail.com> I'm confused what the issue with transitive dependencies is in rebar_mix. The only transitive dependencies that won't work are if the mix dep has git deps. So if you depend on a Elixir application as a hex dependency everything should work fine. Did you not find that to be the case? Or is this to resolve the issue with using Elixir git deps? Tristan On Mon, Apr 1, 2019, at 11:40, Andres Mareca wrote: > Hello, > I have read some threads related to erlang-elixir apps and libraries interoperability. > > In my company, Coowry, we have code written in Erlang and Elixir and we have some code already factored in both languages. We are using our own plugin that I implemented. > > The most important feature of the plugin is that allows to manage transitive dependencies. > > I have been working to make the plugin public and now I would like to share it with you: https://github.com/Supersonido/rebar3_elixir > > I hope it helps others. > > Anything do not hesitate to ask. > > A greeting. > _______________________________________________ > 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 Mon Apr 1 21:37:04 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Mon, 1 Apr 2019 21:37:04 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: References: <20190401130825.6b72c6b1@gmx.de> Message-ID: <20190401213704.5b276ba8@gmx.de> Hi Marc, thanks for the response. I already had Zotonic on the focus, but for my current web app (may be proved wrong at any given point) it seems a bit overkill. Most of the nice features (I'd be glad with for a larger app) I don't really need there, current idea is to: * serve only static pages with only a single variable element (header colour dependent on date) and * two user accounts, one for administering (uploading/changing pages) and one for enabling download of specific content (PDFs). Further improvement will only include: * Template based page generation, * (ToDo like) database application, to be filled only from admin account, public list display, history. As I'm rather new to Erlang, I'm looking for the/a toolkit with least possible learning effort for me on one hand, runtime footprint on the second and not too much difference from a "conventional", static web server, as the application is to be mostly administered by non-IT people. What I was stuck of with the N2O manual, is the fact that they forgot to mention "mad" as a requirement... hope I'll closer get to it now. Cheers, Eckard Am Mon, 1 Apr 2019 14:55:19 +0200 schrieb Marc Worrell : > Hi Eckard, > > You can also use Zotonic CMS (http://zotonic.org/ > ) > > Static files can be served using `controller_static_pages` or > directly as assets from their the `lib` directory, or as templates > from the `templates/static` directory. > > The nice thing with using Zotonic for your site is that you also get: > > * Rich and very flexible templating system > * Full content management environment > * Multi-lingual > * Access control modules > * Email handling (send & receive) > * Timezone handling > * Module system > * etc. etc. etc. > > Zotonic uses PostgreSQL for its database. > > Currently the 0.x version is the ?stable? branch. > We are working towards a 1.x (really soon now). > > The 1.x will have deep MQTT integration. > > Cheers, Marc > > > > On 1 Apr 2019, at 13:08, Eckard Brauer wrote: > > > > Hello, > > > > as I will have to develop a little web application for serving >~80 > > % pure static and < 20 % dynamic (DB frontend, sessoins - DB choice > > is still free) content, I thought of using N2O as the toolkit of > > choice. Some questions arise from that: > > > > * Are there better alternatives to N2O for that? > > > > * Is there a (preferrably step by step) guide for beginners > > available, as most of the tutorials I found seem outdated for years? > > > > Thanks in advance for hints! > > Eckard > > > > -- > > :) > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -- :) From andres.mareca@REDACTED Mon Apr 1 21:40:05 2019 From: andres.mareca@REDACTED (Andres Mareca) Date: Mon, 1 Apr 2019 21:40:05 +0200 Subject: [erlang-questions] Rebar3 plugin for transitive dependencies erlang-elixir In-Reply-To: <01f30ecf-249b-43be-89d7-e9d657357fb8@www.fastmail.com> References: <01f30ecf-249b-43be-89d7-e9d657357fb8@www.fastmail.com> Message-ID: <81C73DA6-0E5B-4372-996C-83D1741E8EB0@gmail.com> Solves the problem of git dependencies and also works with previous versions of elixir. However, we tried to use the plugins that rebar3 recommended but none of them worked well at all, so we decided to implement ours. > El 1 abr 2019, a las 19:44, Tristan Sloughter escribi?: > > I'm confused what the issue with transitive dependencies is in rebar_mix. > > The only transitive dependencies that won't work are if the mix dep has git deps. So if you depend on a Elixir application as a hex dependency everything should work fine. > > Did you not find that to be the case? Or is this to resolve the issue with using Elixir git deps? > > Tristan > > On Mon, Apr 1, 2019, at 11:40, Andres Mareca wrote: >> Hello, >> I have read some threads related to erlang-elixir apps and libraries interoperability. >> >> In my company, Coowry, we have code written in Erlang and Elixir and we have some code already factored in both languages. We are using our own plugin that I implemented. >> >> The most important feature of the plugin is that allows to manage transitive dependencies. >> >> I have been working to make the plugin public and now I would like to share it with you: https://github.com/Supersonido/rebar3_elixir >> >> I hope it helps others. >> >> Anything do not hesitate to ask. >> >> A greeting. >> _______________________________________________ >> 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 comptekki@REDACTED Mon Apr 1 21:59:46 2019 From: comptekki@REDACTED (Wes James) Date: Mon, 1 Apr 2019 13:59:46 -0600 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: <20190401213704.5b276ba8@gmx.de> References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> Message-ID: How about cowboy: https://github.com/ninenines/cowboy -wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From dm.klionsky@REDACTED Tue Apr 2 08:57:36 2019 From: dm.klionsky@REDACTED (Dmitry Klionsky) Date: Tue, 2 Apr 2019 09:57:36 +0300 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> Message-ID: +1 for cowboy. You serve static files using https://ninenines.eu/docs/en/cowboy/2.6/guide/static_files/ For templating you can use https://github.com/erlydtl/erlydtl On 4/1/19 10:59 PM, Wes James wrote: > How about cowboy: > > https://github.com/ninenines/cowboy > > > > > -wes > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From m4ver1k.a@REDACTED Tue Apr 2 17:04:34 2019 From: m4ver1k.a@REDACTED (maverik a) Date: Tue, 2 Apr 2019 11:04:34 -0400 Subject: [erlang-questions] Cowboy Crash with Postman works fine with CURL Message-ID: Hi Erlangers, I'm learning Cowboy and facing a peculiar issue. *My handler code* is here. I have a rest endpoint (POST) and accessing it with Postman show a crash report after giving response. But the very same request works find with CURL. *CURL Request:* curl -X POST -d '{"name":"M4ver1k"}' -i -H "User-Agent: PostmanRuntime/7.6.1" -H "Cache-Control: no-cache" -H "postman-token: cc241d1b-d2f0-488d-86ec-0a06bbb13234" -H "connection: keep-alive" -H "Accept-Encoding: gzip, deflate" -H "Content-Type: application/json" -H "Accept: application/json" http://localhost:8080/api/ *Crash Report:* crasher: initial call: cowboy_stream_h:request_process/3 pid: <0.1023.0> registered_name: [] exception error: no try clause matching #{bindings => #{},body_length => 17,cert => undefined, charset => undefined,has_body => true, has_read_body => true,has_sent_resp => true, headers => #{<<"accept">> => <<"application/json">>, <<"accept-encoding">> => <<"gzip, deflate">>, <<"cache-control">> => <<"no-cache">>, <<"connection">> => <<"keep-alive">>, <<"content-length">> => <<"17">>, <<"content-type">> => <<"application/json">>, <<"host">> => <<"localhost:8080">>, <<"postman-token">> => <<"04b305c1-5214-461e-a1c3-8dcd6b80a621">>, <<"user-agent">> => <<"PostmanRuntime/7.6.1">>}, host => <<"localhost">>,host_info => undefined, media_type => {<<"application">>,<<"json">>,[]}, method => <<"POST">>,path => <<"/api/">>, path_info => undefined, peer => {{127,0,0,1},59002}, pid => <0.1022.0>,port => 8080,qs => <<>>, ref => my_http_listener,scheme => <<"http">>, sock => {{127,0,0,1},8080}, streamid => 1,version => 'HTTP/1.1'} in function cowboy_rest:call/3 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, line 1576) in call from cowboy_rest:process_content_type/3 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, line 1100) in call from cowboy_rest:upgrade/4 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, line 288) in call from cowboy_stream_h:execute/3 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl, line 296) in call from cowboy_stream_h:request_process/3 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl, line 274) ancestors: [<0.1022.0>,<0.407.0>,<0.406.0>,ranch_sup,<0.395.0>] message_queue_len: 0 messages: [] links: [<0.1022.0>] dictionary: [] trap_exit: false status: running heap_size: 1598 stack_size: 27 reductions: 770 neighbours: I have run out of options to triage this,trying to understand this behavior. Regards Maverick -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc@REDACTED Tue Apr 2 17:44:22 2019 From: marc@REDACTED (Marc Worrell) Date: Tue, 2 Apr 2019 17:44:22 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: <20190401213704.5b276ba8@gmx.de> References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> Message-ID: Hi Eckard, Given your requirements it is really straight forward to make in Zotonic. As Zotonic is made for sites like you describe (content uploading, pages, template driven etc.). Though if you like to roll your own administrative interfaces then you can use other tools :) Cheers, Marc > On 1 Apr 2019, at 21:37, Eckard Brauer wrote: > > Hi Marc, > > thanks for the response. I already had Zotonic on the focus, but for my > current web app (may be proved wrong at any given point) it seems a bit > overkill. Most of the nice features (I'd be glad with for a larger app) > I don't really need there, current idea is to: > > * serve only static pages with only a single variable element (header > colour dependent on date) and > * two user accounts, one for administering (uploading/changing pages) > and one for enabling download of specific content (PDFs). > > Further improvement will only include: > > * Template based page generation, > * (ToDo like) database application, to be filled only from admin > account, public list display, history. > > As I'm rather new to Erlang, I'm looking for the/a toolkit with least > possible learning effort for me on one hand, runtime footprint on the > second and not too much difference from a "conventional", static web > server, as the application is to be mostly administered by non-IT > people. > > What I was stuck of with the N2O manual, is the fact that they forgot > to mention "mad" as a requirement... hope I'll closer get to it now. > > Cheers, > Eckard > > Am Mon, 1 Apr 2019 14:55:19 +0200 > schrieb Marc Worrell : > >> Hi Eckard, >> >> You can also use Zotonic CMS (http://zotonic.org/ >> ) >> >> Static files can be served using `controller_static_pages` or >> directly as assets from their the `lib` directory, or as templates >> from the `templates/static` directory. >> >> The nice thing with using Zotonic for your site is that you also get: >> >> * Rich and very flexible templating system >> * Full content management environment >> * Multi-lingual >> * Access control modules >> * Email handling (send & receive) >> * Timezone handling >> * Module system >> * etc. etc. etc. >> >> Zotonic uses PostgreSQL for its database. >> >> Currently the 0.x version is the ?stable? branch. >> We are working towards a 1.x (really soon now). >> >> The 1.x will have deep MQTT integration. >> >> Cheers, Marc >> >> >>> On 1 Apr 2019, at 13:08, Eckard Brauer wrote: >>> >>> Hello, >>> >>> as I will have to develop a little web application for serving >~80 >>> % pure static and < 20 % dynamic (DB frontend, sessoins - DB choice >>> is still free) content, I thought of using N2O as the toolkit of >>> choice. Some questions arise from that: >>> >>> * Are there better alternatives to N2O for that? >>> >>> * Is there a (preferrably step by step) guide for beginners >>> available, as most of the tutorials I found seem outdated for years? >>> >>> Thanks in advance for hints! >>> Eckard >>> >>> -- >>> :) >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > :) From dieter@REDACTED Tue Apr 2 18:43:11 2019 From: dieter@REDACTED (=?UTF-8?Q?Dieter_Sch=c3=b6n?=) Date: Tue, 2 Apr 2019 18:43:11 +0200 Subject: [erlang-questions] Test system for automatic testing of an application Message-ID: <2ecde907-2837-b3df-53b5-b5dceda8aa79@schoen.or.at> Hi all, I am thinking about creating a test environment for automatically testing an application, which is written in C++ and JavaScript. The application produces several files (logfiles and binary archives) and acts as a network server (GUI via HTTP, some other socket interfaces). The test harness will have to *? start the application (with parameters) *? check that it successfully starts (checking the logfile, listening ports) *? run a test suite for all interfaces and scenarios *? shutdown the application I already have an erlang application which can act as a protocol simulator for the socket interfaces. The test harness can run on the same node as the application, so the test harness can start it via os:cmd() or a port. I am considering to use Common Test for the job. Has anybody used Common Test to verify the correctness of a non-Erlang application? Would it be a good choice? So far, I think that I can map all my test scenarios to test cases, groups and suites. Ciao, Dieter From roger@REDACTED Tue Apr 2 19:01:40 2019 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 2 Apr 2019 18:01:40 +0100 Subject: [erlang-questions] Test system for automatic testing of an application In-Reply-To: <2ecde907-2837-b3df-53b5-b5dceda8aa79@schoen.or.at> References: <2ecde907-2837-b3df-53b5-b5dceda8aa79@schoen.or.at> Message-ID: On Tue, 2 Apr 2019 at 17:43, Dieter Sch?n wrote: > Has anybody used Common Test to verify the correctness of a non-Erlang > application? Sort of. We use Common Test to run tests against an application, which happens to be written in Erlang, but the test suites don't know or care about that. From hugo@REDACTED Tue Apr 2 19:19:57 2019 From: hugo@REDACTED (Hugo Mills) Date: Tue, 2 Apr 2019 17:19:57 +0000 Subject: [erlang-questions] [ANN] Lagra 0.2.0 Message-ID: <20190402171957.GC29117@carfax.org.uk> I'm tentatively announcing the first public release of Lagra, a tool implementing an RDF API in Erlang. RDF is the graph-structured data model underlying the Semantic Web and Linked Data concepts. Lagra is intended to support serialisation and deserialisation of RDF documents (supporting 1.5 of the available formats in this initial release), and to provide an API for manipulating RDF graphs. The code, and a basic README with a simple example in it, is on GitHub: https://github.com/darkling/lagra Hugo. -- Hugo Mills | You've read the project plan. Forget that. We're hugo@REDACTED carfax.org.uk | going to Do Stuff and Have Fun doing it. http://carfax.org.uk/ | PGP: E2AB1DE4 | Jeremy Frey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From essen@REDACTED Tue Apr 2 21:06:50 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 2 Apr 2019 21:06:50 +0200 Subject: [erlang-questions] Cowboy Crash with Postman works fine with CURL In-Reply-To: References: Message-ID: Your hello_post function is returning Req instead of {boolean(), Req, State}. On 02/04/2019 17:04, maverik a wrote: > Hi Erlangers, > > I'm learning Cowboy and facing a peculiar issue. > *My handler code* is here. > > I have a rest endpoint (POST) and accessing it with Postman show a crash > report after giving response. But the very same request works find with > CURL. > > _*CURL Request*:_ > curl -X POST -d '{"name":"M4ver1k"}' -i -H "User-Agent: > PostmanRuntime/7.6.1" -H "Cache-Control: no-cache" -H "postman-token: > cc241d1b-d2f0-488d-86ec-0a06bbb13234" -H "connection: keep-alive" -H > "Accept-Encoding: gzip, deflate" -H "Content-Type: application/json" -H > "Accept: application/json" http://localhost:8080/api/ > > _*Crash Report:*_ > crasher: > ??? initial call: cowboy_stream_h:request_process/3 > ??? pid: <0.1023.0> > ??? registered_name: [] > ??? exception error: no try clause matching > ???????????????????? #{bindings => #{},body_length => 17,cert => undefined, > ?????????????????????? charset => undefined,has_body => true, > ?????????????????????? has_read_body => true,has_sent_resp => true, > ?????????????????????? headers => > ?????????????????????????? #{<<"accept">> => <<"application/json">>, > ???????????????????????????? <<"accept-encoding">> => <<"gzip, deflate">>, > ???????????????????????????? <<"cache-control">> => <<"no-cache">>, > ???????????????????????????? <<"connection">> => <<"keep-alive">>, > ???????????????????????????? <<"content-length">> => <<"17">>, > ???????????????????????????? <<"content-type">> => <<"application/json">>, > ???????????????????????????? <<"host">> => <<"localhost:8080">>, > ???????????????????????????? <<"postman-token">> => > > <<"04b305c1-5214-461e-a1c3-8dcd6b80a621">>, > ???????????????????????????? <<"user-agent">> => > <<"PostmanRuntime/7.6.1">>}, > ?????????????????????? host => <<"localhost">>,host_info => undefined, > ?????????????????????? media_type => {<<"application">>,<<"json">>,[]}, > ?????????????????????? method => <<"POST">>,path => <<"/api/">>, > ?????????????????????? path_info => undefined, > ?????????????????????? peer => {{127,0,0,1},59002}, > ?????????????????????? pid => <0.1022.0>,port => 8080,qs => <<>>, > ?????????????????????? ref => my_http_listener,scheme => <<"http">>, > ?????????????????????? sock => {{127,0,0,1},8080}, > ?????????????????????? streamid => 1,version => 'HTTP/1.1'} > ????? in function? cowboy_rest:call/3 > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, > line 1576) > ????? in call from cowboy_rest:process_content_type/3 > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, > line 1100) > ????? in call from cowboy_rest:upgrade/4 > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, > line 288) > ????? in call from cowboy_stream_h:execute/3 > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl, > line 296) > ????? in call from cowboy_stream_h:request_process/3 > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl, > line 274) > ??? ancestors: [<0.1022.0>,<0.407.0>,<0.406.0>,ranch_sup,<0.395.0>] > ??? message_queue_len: 0 > ??? messages: [] > ??? links: [<0.1022.0>] > ??? dictionary: [] > ??? trap_exit: false > ??? status: running > ??? heap_size: 1598 > ??? stack_size: 27 > ??? reductions: 770 > ? neighbours: > > > I have run out of options to triage this,trying to understand this > behavior. > > Regards > Maverick > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin https://ninenines.eu From essen@REDACTED Tue Apr 2 21:13:48 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Tue, 2 Apr 2019 21:13:48 +0200 Subject: [erlang-questions] [ANN] Lagra 0.2.0 In-Reply-To: <20190402171957.GC29117@carfax.org.uk> References: <20190402171957.GC29117@carfax.org.uk> Message-ID: Nice! On 02/04/2019 19:19, Hugo Mills wrote: > I'm tentatively announcing the first public release of Lagra, a > tool implementing an RDF API in Erlang. > > RDF is the graph-structured data model underlying the Semantic Web > and Linked Data concepts. Lagra is intended to support serialisation > and deserialisation of RDF documents (supporting 1.5 of the available > formats in this initial release), and to provide an API for > manipulating RDF graphs. > > The code, and a basic README with a simple example in it, is on > GitHub: > > https://github.com/darkling/lagra > > Hugo. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin https://ninenines.eu From albin.stigo@REDACTED Wed Apr 3 08:23:21 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Wed, 3 Apr 2019 08:23:21 +0200 Subject: [erlang-questions] ei_x_format but no ei_x_match? Message-ID: Hi, Looking at ei in erl_interface. Seems ei is replacing erl since erl is marked as deprecated in the source? The erl_format function had a very convenient pattern matching function erl_match? What happened to that in ei? I can't seem to find a replacement... --Albin From jesper.louis.andersen@REDACTED Wed Apr 3 10:39:52 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 3 Apr 2019 10:39:52 +0200 Subject: [erlang-questions] Test system for automatic testing of an application In-Reply-To: References: <2ecde907-2837-b3df-53b5-b5dceda8aa79@schoen.or.at> Message-ID: On Tue, Apr 2, 2019 at 7:02 PM Roger Lipscombe wrote: > > Sort of. We use Common Test to run tests against an application, which > happens to be written in Erlang, but the test suites don't know or > care about that. > Back in the day, when I wrote BitTorrent clients for fun, I used CT to handle other clients and trackers. Basically set up a network and test your client against the other clients, while maintaining them through CT. The reason this is efficient is because you often want concurrent testing, and the framework allows one to spawn processes to help with that. In fact, using CT for this is one of the main points of it I think. Especially because it has tooling for direct communication with a SUT over ssh/ftp, ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From eckard.brauer@REDACTED Wed Apr 3 12:21:15 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Wed, 3 Apr 2019 12:21:15 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> Message-ID: <20190403122104.351c55ce@gmx.de> Hello, OK, tried the "Getting started" at (https://ninenines.eu/docs/en/cowboy/2.6/guide/getting_started/). When following that page, I don't get a 500 response as promised, but a compile: warnings being treated as errors src/hello_erlang_handler.erl:9: function start/2 is unused when building. So defining routes in paragraph "Listening for connections" should probably be corrected - what's the correct way / where is the correct position to define routes? Thanks in advance! Eckard Am Tue, 2 Apr 2019 09:57:36 +0300 schrieb Dmitry Klionsky : > +1 for cowboy. > > You serve static files using > https://ninenines.eu/docs/en/cowboy/2.6/guide/static_files/ > For templating you can use https://github.com/erlydtl/erlydtl > > > On 4/1/19 10:59 PM, Wes James wrote: > > How about cowboy: > > > > https://github.com/ninenines/cowboy > > > > > > > > > > -wes > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions -- :) From hugo@REDACTED Wed Apr 3 12:31:29 2019 From: hugo@REDACTED (Hugo Mills) Date: Wed, 3 Apr 2019 10:31:29 +0000 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: <20190403122104.351c55ce@gmx.de> References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> <20190403122104.351c55ce@gmx.de> Message-ID: <20190403103129.GG29117@carfax.org.uk> On Wed, Apr 03, 2019 at 12:21:15PM +0200, Eckard Brauer wrote: > Hello, > > OK, tried the "Getting started" at > (https://ninenines.eu/docs/en/cowboy/2.6/guide/getting_started/). > > When following that page, I don't get a 500 response as promised, but a > > compile: warnings being treated as errors > src/hello_erlang_handler.erl:9: function start/2 is unused Is the function exported? Hugo. > when building. So defining routes in paragraph "Listening for > connections" should probably be corrected - what's the correct way / > where is the correct position to define routes? > > Thanks in advance! > Eckard > > Am Tue, 2 Apr 2019 09:57:36 +0300 > schrieb Dmitry Klionsky : > > > +1 for cowboy. > > > > You serve static files using > > https://ninenines.eu/docs/en/cowboy/2.6/guide/static_files/ > > For templating you can use https://github.com/erlydtl/erlydtl > > > > > > On 4/1/19 10:59 PM, Wes James wrote: > > > How about cowboy: > > > > > > https://github.com/ninenines/cowboy > > > > > > > > > > > > > > > -wes > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > -- Hugo Mills | "I don't like the look of it, I tell you." hugo@REDACTED carfax.org.uk | "Well, stop looking at it, then." http://carfax.org.uk/ | PGP: E2AB1DE4 | The Goons -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From eckard.brauer@REDACTED Wed Apr 3 13:15:12 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Wed, 3 Apr 2019 13:15:12 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: <20190403103129.GG29117@carfax.org.uk> References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> <20190403122104.351c55ce@gmx.de> <20190403103129.GG29117@carfax.org.uk> Message-ID: <20190403131512.51114695@gmx.de> Hello Hugo, you hit the nail - I should have known that, but the next problem arises: Even if [{port, 8080}] is the 2nd arg of cowboy:start_clear/3, the server doesn't listen on 8080 - at least netstat doesn't see that, and I don't get a connection. How to diagnose that problem - what am I doing wrong? Thanks again, Eckard Am Wed, 3 Apr 2019 10:31:29 +0000 schrieb Hugo Mills : > On Wed, Apr 03, 2019 at 12:21:15PM +0200, Eckard Brauer wrote: > [...] > > Is the function exported? > > Hugo. > > [...] > [...] > [...] > [...] > -- :) From roger@REDACTED Wed Apr 3 13:37:26 2019 From: roger@REDACTED (Roger Lipscombe) Date: Wed, 3 Apr 2019 12:37:26 +0100 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: <20190403122104.351c55ce@gmx.de> References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> <20190403122104.351c55ce@gmx.de> Message-ID: > Open the src/hello_erlang_app.erl file and add the necessary code to the start/2 function start/2 goes in hello_erlang_app.erl, not hello_erlang_handler.erl. On Wed, 3 Apr 2019 at 11:21, Eckard Brauer wrote: > > Hello, > > OK, tried the "Getting started" at > (https://ninenines.eu/docs/en/cowboy/2.6/guide/getting_started/). > > When following that page, I don't get a 500 response as promised, but a > > compile: warnings being treated as errors > src/hello_erlang_handler.erl:9: function start/2 is unused > > when building. So defining routes in paragraph "Listening for > connections" should probably be corrected - what's the correct way / > where is the correct position to define routes? > > Thanks in advance! > Eckard > > Am Tue, 2 Apr 2019 09:57:36 +0300 > schrieb Dmitry Klionsky : > > > +1 for cowboy. > > > > You serve static files using > > https://ninenines.eu/docs/en/cowboy/2.6/guide/static_files/ > > For templating you can use https://github.com/erlydtl/erlydtl > > > > > > On 4/1/19 10:59 PM, Wes James wrote: > > > How about cowboy: > > > > > > https://github.com/ninenines/cowboy > > > > > > > > > > > > > > > -wes > > > > > > _______________________________________________ > > > 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 eckard.brauer@REDACTED Wed Apr 3 14:09:16 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Wed, 3 Apr 2019 14:09:16 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> <20190403122104.351c55ce@gmx.de> Message-ID: <20190403140916.14f76d2c@gmx.de> Hello Roger, thanks - now it works. Will have to study the documentation a bit more to understand the structure of cowboy apps. Cheers, Eckard > [...] > > start/2 goes in hello_erlang_app.erl, not hello_erlang_handler.erl. > > On Wed, 3 Apr 2019 at 11:21, Eckard Brauer > wrote: [...] > [...] > [...] > [...] -- :) From jesper.louis.andersen@REDACTED Wed Apr 3 14:42:19 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 3 Apr 2019 14:42:19 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: <20190401130825.6b72c6b1@gmx.de> References: <20190401130825.6b72c6b1@gmx.de> Message-ID: On Mon, Apr 1, 2019 at 1:09 PM Eckard Brauer wrote: > > * Are there better alternatives to N2O for that? > > N2O is a loosely coupled specification of protocols where each part work together. You can mix-and-match between them, though a lot of the power stems from them working well together. The protocols are available over many different transports, so it is a really strong toolbox for integration. Alternative solutions depends on your requirements, and what you want to achieve. The best advice I can give is "software grows". Any complex system starts from a simple system. So if you start with something "simple", you might outgrow that in time. N2O takes the concepts of messaging and formality to a far greater level than other systems, so if you imagine you grow in that direction (i.e., *everything* is a websocket, we need to implement this from scratch in a $industrial-crap-language, etc), then it might be suitable. * Is there a (preferrably step by step) guide for beginners available, > as most of the tutorials I found seem outdated for years? > > Age of a tutorial might not be a problem. If things are stable, there will be less updates needed. In fact, I have a graphql-tutorial which needs treatment now, because things changed too much! And I don't have that much time allotted for it right now. https://ws.n2o.space/ would be the entry-point. There are some examples along the way where the 'mad' tool generates examples for you to work on. And it seems it was updated Nov 2018, which isn't that far in the past to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Wed Apr 3 16:31:29 2019 From: comptekki@REDACTED (Wes James) Date: Wed, 3 Apr 2019 08:31:29 -0600 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: <20190403122104.351c55ce@gmx.de> References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> <20190403122104.351c55ce@gmx.de> Message-ID: Take a look at the examples. wes On Wed, Apr 3, 2019 at 4:21 AM Eckard Brauer wrote: > Hello, > > OK, tried the "Getting started" at > (https://ninenines.eu/docs/en/cowboy/2.6/guide/getting_started/). > > When following that page, I don't get a 500 response as promised, but a > > compile: warnings being treated as errors > src/hello_erlang_handler.erl:9: function start/2 is unused > > when building. So defining routes in paragraph "Listening for > connections" should probably be corrected - what's the correct way / > where is the correct position to define routes? > > Thanks in advance! > Eckard > > Am Tue, 2 Apr 2019 09:57:36 +0300 > schrieb Dmitry Klionsky : > > > +1 for cowboy. > > > > You serve static files using > > https://ninenines.eu/docs/en/cowboy/2.6/guide/static_files/ > > For templating you can use https://github.com/erlydtl/erlydtl > > > > > > On 4/1/19 10:59 PM, Wes James wrote: > > > How about cowboy: > > > > > > https://github.com/ninenines/cowboy > > > > > > > > > > > > > > > -wes > > > > > > _______________________________________________ > > > 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 m4ver1k.a@REDACTED Wed Apr 3 18:14:30 2019 From: m4ver1k.a@REDACTED (maverik a) Date: Wed, 3 Apr 2019 12:14:30 -0400 Subject: [erlang-questions] Cowboy Crash with Postman works fine with CURL In-Reply-To: References: Message-ID: Thank you Loic and Zsolt that helped, my bad didn't RTFM properly :( Now I'm facing a different Issue. *But something that still baffles me why is this only happening when calling from POSTMAN and not CURL.* *I'm on a Arch Linux machine with Sway/Wayland Compositor. * New error stacktrace after changing return value from *hello_json *handler: =CRASH REPORT==== 2-Apr-2019::16:20:53.649647 === crasher: initial call: cowboy_stream_h:request_process/3 pid: <0.445.0> registered_name: [] exception error: function_clause in function cowboy_req:reply/4 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_req.erl, line 763) in call from cowboy_rest:respond/3 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, line 1616) in call from cowboy_rest:process_content_type/3 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, line 1106) in call from cowboy_rest:upgrade/4 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, line 288) in call from cowboy_stream_h:execute/3 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl, line 296) in call from cowboy_stream_h:request_process/3 (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl, line 274) ancestors: [<0.444.0>,<0.407.0>,<0.406.0>,ranch_sup,<0.395.0>] message_queue_len: 0 messages: [] links: [<0.444.0>] dictionary: [] trap_exit: false status: running heap_size: 1598 stack_size: 27 reductions: 782 neighbours: =ERROR REPORT==== 2-Apr-2019::16:20:53.651090 === Ranch listener my_http_listener, connection process <0.444.0>, stream 1 had its request process <0.445.0> exit with reason function_clause and stacktrace [{cowboy_req,reply,4,[{file,"/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_req.erl"},{line,763}]},{cowboy_rest,respond,3,[{file,"/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl"},{line,1616}]},{cowboy_rest,process_content_type,3,[{file,"/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl"},{line,1106}]},{cowboy_rest,upgrade,4,[{file,"/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl"},{line,288}]},{cowboy_stream_h,execute,3,[{file,"/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl"},{line,296}]},{cowboy_stream_h,request_process,3,[{file,"/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl"},{line,274}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,249}]}] On Tue, Apr 2, 2019 at 3:06 PM Lo?c Hoguin wrote: > Your hello_post function is returning Req instead of {boolean(), Req, > State}. > > On 02/04/2019 17:04, maverik a wrote: > > Hi Erlangers, > > > > I'm learning Cowboy and facing a peculiar issue. > > *My handler code* is here. > > > > I have a rest endpoint (POST) and accessing it with Postman show a crash > > report after giving response. But the very same request works find with > > CURL. > > > > _*CURL Request*:_ > > curl -X POST -d '{"name":"M4ver1k"}' -i -H "User-Agent: > > PostmanRuntime/7.6.1" -H "Cache-Control: no-cache" -H "postman-token: > > cc241d1b-d2f0-488d-86ec-0a06bbb13234" -H "connection: keep-alive" -H > > "Accept-Encoding: gzip, deflate" -H "Content-Type: application/json" -H > > "Accept: application/json" http://localhost:8080/api/ > > > > _*Crash Report:*_ > > crasher: > > initial call: cowboy_stream_h:request_process/3 > > pid: <0.1023.0> > > registered_name: [] > > exception error: no try clause matching > > #{bindings => #{},body_length => 17,cert => > undefined, > > charset => undefined,has_body => true, > > has_read_body => true,has_sent_resp => true, > > headers => > > #{<<"accept">> => <<"application/json">>, > > <<"accept-encoding">> => <<"gzip, > deflate">>, > > <<"cache-control">> => <<"no-cache">>, > > <<"connection">> => <<"keep-alive">>, > > <<"content-length">> => <<"17">>, > > <<"content-type">> => > <<"application/json">>, > > <<"host">> => <<"localhost:8080">>, > > <<"postman-token">> => > > > > <<"04b305c1-5214-461e-a1c3-8dcd6b80a621">>, > > <<"user-agent">> => > > <<"PostmanRuntime/7.6.1">>}, > > host => <<"localhost">>,host_info => undefined, > > media_type => {<<"application">>,<<"json">>,[]}, > > method => <<"POST">>,path => <<"/api/">>, > > path_info => undefined, > > peer => {{127,0,0,1},59002}, > > pid => <0.1022.0>,port => 8080,qs => <<>>, > > ref => my_http_listener,scheme => <<"http">>, > > sock => {{127,0,0,1},8080}, > > streamid => 1,version => 'HTTP/1.1'} > > in function cowboy_rest:call/3 > > > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, > > > line 1576) > > in call from cowboy_rest:process_content_type/3 > > > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, > > > line 1100) > > in call from cowboy_rest:upgrade/4 > > > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_rest.erl, > > > line 288) > > in call from cowboy_stream_h:execute/3 > > > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl, > > > line 296) > > in call from cowboy_stream_h:request_process/3 > > > (/m4ver1k/learn/erlang/hello_cowboy/_build/default/lib/cowboy/src/cowboy_stream_h.erl, > > > line 274) > > ancestors: [<0.1022.0>,<0.407.0>,<0.406.0>,ranch_sup,<0.395.0>] > > message_queue_len: 0 > > messages: [] > > links: [<0.1022.0>] > > dictionary: [] > > trap_exit: false > > status: running > > heap_size: 1598 > > stack_size: 27 > > reductions: 770 > > neighbours: > > > > > > I have run out of options to triage this,trying to understand this > > behavior. > > > > Regards > > Maverick > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lo?c Hoguin > https://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eckard.brauer@REDACTED Wed Apr 3 18:44:17 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Wed, 3 Apr 2019 18:44:17 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: References: <20190401130825.6b72c6b1@gmx.de> <20190401213704.5b276ba8@gmx.de> <20190403122104.351c55ce@gmx.de> Message-ID: <20190403184417.24b64745@gmx.de> Hello Wes, was my fault - I put the start/2 into hello_erlang_handler instead of *_app by accident (in fact, I made a shell script, and that was a consequence of copy/paste). But thanks for the hints - I appreciate both the simplicity and expressiveness of Erlang. Cheers, Eckard Am Wed, 3 Apr 2019 08:31:29 -0600 schrieb Wes James : > Take a look at the examples. > > wes > > On Wed, Apr 3, 2019 at 4:21 AM Eckard Brauer > wrote: > > > Hello, > > > > OK, tried the "Getting started" at > > (https://ninenines.eu/docs/en/cowboy/2.6/guide/getting_started/). > > > > When following that page, I don't get a 500 response as promised, > > but a > > > > compile: warnings being treated as errors > > src/hello_erlang_handler.erl:9: function start/2 is unused > > > > when building. So defining routes in paragraph "Listening for > > connections" should probably be corrected - what's the correct way / > > where is the correct position to define routes? > > > > Thanks in advance! > > Eckard > > > > Am Tue, 2 Apr 2019 09:57:36 +0300 > > schrieb Dmitry Klionsky : > > > > > +1 for cowboy. > > > > > > You serve static files using > > > https://ninenines.eu/docs/en/cowboy/2.6/guide/static_files/ > > > For templating you can use https://github.com/erlydtl/erlydtl > > > > > > > > > On 4/1/19 10:59 PM, Wes James wrote: > > > > How about cowboy: > > > > > > > > https://github.com/ninenines/cowboy > > > > > > > > > > > > > > > > > > > > -wes > > > > > > > > _______________________________________________ > > > > 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 eckard.brauer@REDACTED Wed Apr 3 19:25:35 2019 From: eckard.brauer@REDACTED (Eckard Brauer) Date: Wed, 3 Apr 2019 19:25:35 +0200 Subject: [erlang-questions] Web toolkit, N2O guide In-Reply-To: References: <20190401130825.6b72c6b1@gmx.de> Message-ID: <20190403192535.5dda3f26@gmx.de> Hello Jesper, Jesper Louis Andersen : > On Mon, Apr 1, 2019 at 1:09 PM Eckard Brauer > wrote: > > > > > * Are there better alternatives to N2O for that? > > > > > N2O is a loosely coupled specification of protocols where each part > work together. You can mix-and-match between them, though a lot of > the power stems from them working well together. The protocols are > available over many different transports, so it is a really strong > toolbox for integration. I originally selected N2O for it's compactness - to me, it seemed to include all and everything I could think of needing in this case (rather small application for a friend, I don't want to put too much effort in before it starts working, adding some functionality at a later point should easy be possible, and for me it's a good occasion to learn some more Erlang). Where I initially stumbled over is the need of the "mad" tool - I suspected, it could belong to (is included in) either N2O or some more general tool, like e.g. rebar. After I installed it, everything went fine. In the meanwhile, I also wanted to give Zotonic a try, gave up becauso of it's pure extent (it looks to me too oversized for the little app - some choir website intented to be run on a raspberry or the like). I'd most probably choose that for some larger application. And, just now I'm playing with (pure) cowboy. With some custom handler(s) for (authenticated) upload and access limitation, maybe that will fit (most of) the needs. Maybe that's what you told below with "software grows", so far I'd like to agree. > Alternative solutions depends on your requirements, and what you want > to achieve. The best advice I can give is "software grows". Any > complex system starts from a simple system. So if you start with > something "simple", you might outgrow that in time. N2O takes the > concepts of messaging and formality to a far greater level than other > systems, so if you imagine you grow in that direction (i.e., > *everything* is a websocket, we need to implement this from scratch > in a $industrial-crap-language, etc), then it might be suitable. > > * Is there a (preferrably step by step) guide for beginners available, > > as most of the tutorials I found seem outdated for years? > > > > > Age of a tutorial might not be a problem. If things are stable, there > will be less updates needed. In fact, I have a graphql-tutorial which > needs treatment now, because things changed too much! And I don't > have that much time allotted for it right now. > > https://ws.n2o.space/ would be the entry-point. There are some > examples along the way where the 'mad' tool generates examples for > you to work on. And it seems it was updated Nov 2018, which isn't > that far in the past to me. Of course, age in terms of months (or even years) is not a problem, but I had a few occasions where dependencies grew further and didn't fit the needs of some tools using them (maybe simply beginner problems, I'm just learning how Erlang handles dependencies). Even the toolset in Erlang is not very common for me (usually I did mostly Shell scripting, C(++), some assembly languages etc. for the last years or decades, no functional programming at all, except maybe a few little tries with Python and Prolog), so it's easy to struggle when tools and documentation have some difference or semantics are changed slightly. Playing with Erlang more as a hobbyist I'm still hitting beginner's problems - hope I'll still get it somehow.. So thanks for the valuable hints @all here! Cheers, Eckardo -- :) From bchesneau@REDACTED Thu Apr 4 15:58:35 2019 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 4 Apr 2019 15:58:35 +0200 Subject: [erlang-questions] rust c-node ? Message-ID: Is anyone aware of a library that would allow the creation of an app in rust acting as a c-node ? Beno?t -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmytro.lytovchenko@REDACTED Thu Apr 4 16:05:00 2019 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Thu, 4 Apr 2019 16:05:00 +0200 Subject: [erlang-questions] rust c-node ? In-Reply-To: References: Message-ID: While I adore Rust as a language and a development tool, I did not see any significant demand in creating such a project. I have created Python Erlang node (https://github.com/Pyrlang/Pyrlang) so there is all the knowledge and technology to make Rust node happen. But I have many more reasons to think about PHP Erlang node, for the great impact this might potentially have, although not in Rust, no. The demand is too low and there is no business willing to sponsor it. On Thu, 4 Apr 2019 at 15:59, Benoit Chesneau wrote: > Is anyone aware of a library that would allow the creation of an app in > rust acting as a c-node ? > > Beno?t > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felixgallo@REDACTED Thu Apr 4 16:07:59 2019 From: felixgallo@REDACTED (felixgallo@REDACTED) Date: Thu, 4 Apr 2019 07:07:59 -0700 Subject: [erlang-questions] rust c-node ? In-Reply-To: References: Message-ID: <3AA8A75F-2A2E-4269-BADF-48873006B129@gmail.com> Could https://github.com/rusterlium/rustler suffice for your needs, Benoit? F. > On Apr 4, 2019, at 7:05 AM, Dmytro Lytovchenko wrote: > > While I adore Rust as a language and a development tool, I did not see any significant demand in creating such a project. I have created Python Erlang node (https://github.com/Pyrlang/Pyrlang) so there is all the knowledge and technology to make Rust node happen. But I have many more reasons to think about PHP Erlang node, for the great impact this might potentially have, although not in Rust, no. The demand is too low and there is no business willing to sponsor it. > >> On Thu, 4 Apr 2019 at 15:59, Benoit Chesneau wrote: >> Is anyone aware of a library that would allow the creation of an app in rust acting as a c-node ? >> >> Beno?t >> _______________________________________________ >> 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 andre@REDACTED Thu Apr 4 16:20:30 2019 From: andre@REDACTED (Andre Nathan) Date: Thu, 4 Apr 2019 11:20:30 -0300 Subject: [erlang-questions] rust c-node ? In-Reply-To: References: Message-ID: <63477f5e-3b0d-dad4-5185-2aecc5d2cd7f@digirati.com.br> On 4/4/19 11:05 AM, Dmytro Lytovchenko wrote: > But I have many more > reasons to think about PHP Erlang node, for the great impact this might > potentially have, For what it's worth, such a thing exists, although it was never updated to work with PHP 7. https://github.com/videlalvaro/mypeb I also have a small (incomplete) library for Go: https://gitlab.com/andrenathan/go/ei Best regards, Andre From erlang@REDACTED Thu Apr 4 16:30:07 2019 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 4 Apr 2019 16:30:07 +0200 Subject: [erlang-questions] Running old code and TCL in particular Message-ID: I've been having fun digging up some old programs to see if they still work. It's a good test of stability - can I run 20 year old code - or does it need a lot of fixing. Most (not all) of my pre 2000 Erlang still works - one advantage of using no NIFS and trying to write clean code. Most of my old TCL works (with the latest TCL) Most of my old makefiles and bash scripts still work. Most of my old C does not work (but then I always wrote crap C) Back to TCL - It's still great - when did we chuck gs? - I think this was a big mistake. The only thing wrong with TCL is the smallish user base and the somewhat cryptic documentation. Are there any other TCL fans out there? Specifically is anybody using TCL (latest) through sockets and "sans NIFS" as it were. Has anybody done the round trip Erlang -> TCL -> Erlang with binaries without loss of data - TCL's "everything is a string" philosophy does not mesh well with Erlang binaries :-) Cheers /Joe From fly@REDACTED Thu Apr 4 16:52:14 2019 From: fly@REDACTED (Fred Youhanaie) Date: Thu, 4 Apr 2019 15:52:14 +0100 Subject: [erlang-questions] Running old code and TCL in particular In-Reply-To: References: Message-ID: Hi Joe, I have a couple of Erlang/Tcl projects, both need some time and attention from me! - Tcl code as c-node: https://github.com/fredyouhanaie/etclface - Tcl code as a port: https://github.com/fredyouhanaie/portcl Although Tcl treats "everything as string", If you have a number, and use it in a numeric expression, then the numeric version will be stored internally. I haven't tried the round trip test, but I'll add it to my todo list. Cheers, Fred On 04/04/2019 15:30, Joe Armstrong wrote: > I've been having fun digging up some old programs to see if they still > work. > > It's a good test of stability - can I run 20 year old code - or does > it need a lot of fixing. > > Most (not all) of my pre 2000 Erlang still works - one advantage of > using no NIFS > and trying to write clean code. > > Most of my old TCL works (with the latest TCL) > > Most of my old makefiles and bash scripts still work. > > Most of my old C does not work (but then I always wrote crap C) > > Back to TCL - > > It's still great - when did we chuck gs? - I think this was a big mistake. > > The only thing wrong with TCL is the smallish user base and the somewhat cryptic > documentation. > > Are there any other TCL fans out there? > > Specifically is anybody using TCL (latest) through sockets and "sans > NIFS" as it were. > > Has anybody done the round trip Erlang -> TCL -> Erlang with binaries > without loss of > data - TCL's "everything is a string" philosophy does not mesh well > with Erlang binaries :-) > > Cheers > > /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From erlang@REDACTED Thu Apr 4 16:53:23 2019 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 4 Apr 2019 16:53:23 +0200 Subject: [erlang-questions] The unfathomable beauty of quines Message-ID: I've been playing with the idea of a quine. Here are three that are fun Smalltalk TiddlyWiki Meta II A quine is a self-reproducing program - once the first version works it is used to make the second version and so on ad infinitum. It's especially fun when it's made as a single file. WARNING - do not read the rest if you want to get any work done for the next month. Dan Ingalls (the guy who made Smalltalk) told me about Dewey Val Schorre's paper http://www.ibm-1401.info/Meta-II-schorre.pdf With strict instructions *not* to read it. Well, of course, I immediately read it and implemented it in Erlang - and poof - 3-6 weeks vanished in a blur (and don't get me started on O'meta etc.) Unfortunately, Erlang is not a quine - it actually was (or has been) (or was for a short time) but now it's very definitely not - all these BIFs and NIFS and dirty this-and-that's have destroyed any possibility for quine like behaviour. Is there a subset of Erlang that can be made into a quine with a new VM to support it? Cheers /Joe From bobgus@REDACTED Thu Apr 4 23:08:44 2019 From: bobgus@REDACTED (Bob Gustafson) Date: Thu, 4 Apr 2019 16:08:44 -0500 Subject: [erlang-questions] Running old code and TCL in particular In-Reply-To: References: Message-ID: I remember my Expect scripts using TCL/Expect. A lot easier to change than buggy 2019 Fabric scripts... On 4/4/19 9:30 AM, Joe Armstrong wrote: > I've been having fun digging up some old programs to see if they still > work. > > It's a good test of stability - can I run 20 year old code - or does > it need a lot of fixing. > > Most (not all) of my pre 2000 Erlang still works - one advantage of > using no NIFS > and trying to write clean code. > > Most of my old TCL works (with the latest TCL) > > Most of my old makefiles and bash scripts still work. > > Most of my old C does not work (but then I always wrote crap C) > > Back to TCL - > > It's still great - when did we chuck gs? - I think this was a big mistake. > > The only thing wrong with TCL is the smallish user base and the somewhat cryptic > documentation. > > Are there any other TCL fans out there? > > Specifically is anybody using TCL (latest) through sockets and "sans > NIFS" as it were. > > Has anybody done the round trip Erlang -> TCL -> Erlang with binaries > without loss of > data - TCL's "everything is a string" philosophy does not mesh well > with Erlang binaries :-) > > Cheers > > /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mjtruog@REDACTED Fri Apr 5 08:34:35 2019 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 4 Apr 2019 23:34:35 -0700 Subject: [erlang-questions] The unfathomable beauty of quines In-Reply-To: References: Message-ID: On 4/4/19 7:53 AM, Joe Armstrong wrote: > I've been playing with the idea of a quine. > > Here are three that are fun > > Smalltalk > TiddlyWiki > Meta II > > A quine is a self-reproducing program - once the first version works it is used > to make the second version and so on ad infinitum. It's especially fun when it's > made as a single file. > > WARNING - do not read the rest if you want to get any work done for > the next month. > > Dan Ingalls (the guy who made Smalltalk) told me about Dewey Val Schorre's paper > > http://www.ibm-1401.info/Meta-II-schorre.pdf > > With strict instructions *not* to read it. > > Well, of course, I immediately read it and implemented it in Erlang - > and poof - 3-6 weeks vanished in a blur (and don't get me started on > O'meta etc.) > > Unfortunately, Erlang is not a quine - it actually was (or has been) > (or was for a short time) > but now it's very definitely not - all these BIFs and NIFS and dirty > this-and-that's > have destroyed any possibility for quine like behaviour. > > Is there a subset of Erlang that can be made into a quine with a new > VM to support it? > > Cheers > > /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > Hi Joe, I know you want to do more than a simple regex to mutate the quine, but the simplest approach to a quine in Erlang should be in an escript.? An example is below (I put it at https://gist.github.com/okeuday/0fc551e2a5b1f346d64646d2cd2b66c7 , just save it as "quine0"): #!/usr/bin/env escript %%! %-*-Mode:erlang;coding:utf-8;tab-width:4;c-basic-offset:4;indent-tabs-mode:()-*- % ex: set ft=erlang fenc=utf-8 sts=4 ts=4 sw=4 et: -mode(compile). main(["-i" | _]) -> ??? MagicNumber = 0, ??? GenerationName = filename:basename(escript:script_name()), ??? "quine" ++ GenerationIndexStr = GenerationName, ??? io:format("Hi, my name is \"~s\" (generation ~s)~n" ????????????? "my magic number is ~w!~n", [GenerationName,GenerationIndexStr,MagicNumber]), ??? exit_code(0); main([]) -> ??? Path = filename:dirname(?FILE), ??? "quine" ++ GenerationIndexStr = filename:basename(?FILE), ??? NewGenerationIndex = erlang:list_to_integer(GenerationIndexStr) + 1, ??? NewGenerationName = "quine" ++ erlang:integer_to_list(NewGenerationIndex), ??? {ok, GenerationCurrent} = file:read_file(?FILE), ??? S = erlang:integer_to_list(binary:decode_unsigned( ??????? crypto:strong_rand_bytes(2))), ??? GenerationNew = re:replace(GenerationCurrent, ?????????????????????????????? "MagicNumber = [0-9]+,", ?????????????????????????????? "MagicNumber = " ++ S ++ ",", ?????????????????????????????? [global, {return, binary}]), ??? FilePath = filename:join(Path,NewGenerationName), ??? ok = file:write_file(FilePath,GenerationNew), ??? ok = file:change_mode(FilePath,8#00775), ??? io:format("~s is born!~n", [NewGenerationName]), ??? exit_code(0). exit_code(ExitCode) -> ??? erlang:halt(ExitCode, [{flush, true}]). From bchesneau@REDACTED Sun Apr 7 08:15:28 2019 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sun, 7 Apr 2019 08:15:28 +0200 Subject: [erlang-questions] rust c-node ? In-Reply-To: <3AA8A75F-2A2E-4269-BADF-48873006B129@gmail.com> References: <3AA8A75F-2A2E-4269-BADF-48873006B129@gmail.com> Message-ID: sorry for the late answer. no i really want to have it as an extra node in the distribution. so it can be isolated an have its own scheduling. A nif pe dirry nif wouldn't be ok jn the case i'm thinking of. Not without a lot of work at least On Thu 4 Apr 2019 at 16:08, wrote: > Could https://github.com/rusterlium/rustler suffice for your needs, > Benoit? > > F. > > On Apr 4, 2019, at 7:05 AM, Dmytro Lytovchenko < > dmytro.lytovchenko@REDACTED> wrote: > > While I adore Rust as a language and a development tool, I did not see any > significant demand in creating such a project. I have created Python Erlang > node (https://github.com/Pyrlang/Pyrlang) so there is all the knowledge > and technology to make Rust node happen. But I have many more reasons to > think about PHP Erlang node, for the great impact this might potentially > have, although not in Rust, no. The demand is too low and there is no > business willing to sponsor it. > > On Thu, 4 Apr 2019 at 15:59, Benoit Chesneau wrote: > >> Is anyone aware of a library that would allow the creation of an app in >> rust acting as a c-node ? >> >> Beno?t >> _______________________________________________ >> 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 > > -- Sent from my Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sun Apr 7 08:25:05 2019 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sun, 7 Apr 2019 08:25:05 +0200 Subject: [erlang-questions] rust c-node ? In-Reply-To: References: Message-ID: i saw pyerlang but i require a more low level access to the system in that case that can't be achieved in python. thanks for the lib anyway i definitely see some usage for it when i have to use some products in python like those in ml. Benoit On Thu 4 Apr 2019 at 16:05, Dmytro Lytovchenko wrote: > While I adore Rust as a language and a development tool, I did not see any > significant demand in creating such a project. I have created Python Erlang > node (https://github.com/Pyrlang/Pyrlang) so there is all the knowledge > and technology to make Rust node happen. But I have many more reasons to > think about PHP Erlang node, for the great impact this might potentially > have, although not in Rust, no. The demand is too low and there is no > business willing to sponsor it. > > On Thu, 4 Apr 2019 at 15:59, Benoit Chesneau wrote: > >> Is anyone aware of a library that would allow the creation of an app in >> rust acting as a c-node ? >> >> Beno?t >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- Sent from my Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Sun Apr 7 11:22:22 2019 From: roger@REDACTED (Roger Lipscombe) Date: Sun, 7 Apr 2019 10:22:22 +0100 Subject: [erlang-questions] rust c-node ? In-Reply-To: References: <3AA8A75F-2A2E-4269-BADF-48873006B129@gmail.com> Message-ID: On Sun, 7 Apr 2019 at 07:15, Benoit Chesneau wrote: > > sorry for the late answer. no i really want to have it as an extra node in the distribution. so it can be isolated an have its own scheduling. A nif pe dirry nif wouldn't be ok jn the case i'm thinking of. Not without a lot of work at least Not directly answering your question, but we've achieved the isolation by having a separate Erlang node dedicated to running the NIF. It does a few other things, but primarily it was for the isolation. From soverdor@REDACTED Mon Apr 8 00:15:40 2019 From: soverdor@REDACTED (Sam Overdorf) Date: Sun, 7 Apr 2019 15:15:40 -0700 Subject: [erlang-questions] pre-built erlang for windows Message-ID: Does anyone provide a pre-build version of erlang 21.3.* updates for windows ? Thanks, Sam From frank.muller.erl@REDACTED Mon Apr 8 08:39:15 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Mon, 8 Apr 2019 08:39:15 +0200 Subject: [erlang-questions] process mailbox empty Message-ID: Hi everyone When I check the process mailbox of my gen_server size with recon:info/1 or erlang:process_info(PID, message_queue_len), both return 236. But erlang:process_info(PID, messages) returns and empty list []. Any idea? I?m running Erlang 21.3.3 on Ubuntu LTS16.04 /Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From Catenacci@REDACTED Mon Apr 8 15:27:06 2019 From: Catenacci@REDACTED (Onorio Catenacci) Date: Mon, 8 Apr 2019 09:27:06 -0400 Subject: [erlang-questions] pre-built erlang for windows In-Reply-To: References: Message-ID: > Today's Topics: > > 1. pre-built erlang for windows (Sam Overdorf) > 2. process mailbox empty (Frank Muller) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 7 Apr 2019 15:15:40 -0700 > From: Sam Overdorf > To: Erlang Questions > Subject: [erlang-questions] pre-built erlang for windows > Message-ID: > < > CAE5PUX+5S+GYsi5pciMSgPRBR00XD5JVxaDZD1C668Fv-1hL3A@REDACTED> > Content-Type: text/plain; charset="UTF-8" > > Does anyone provide a pre-build version of erlang 21.3.* updates for > windows ? > Thanks, > Sam > No, as far as I know, only the minor versions (as in 21.x or 20.x etc) are pre-built for windows. The Erlang folks have another name for those minor versions but it escapes me right now. There is no 21.3.3 pre-built for windows--at least not from any official source that I am aware of. -- Onorio Catenacci http://onor.io https://twitter.com/OldDutchCap -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Mon Apr 8 15:52:16 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Mon, 8 Apr 2019 15:52:16 +0200 Subject: [erlang-questions] WebRTC and DTLS and use_srtp Message-ID: Hi, For anyone interested in WebRTC... After thinking more about this I decided to write a GnuTLS DTLS NIF that allows me to multiplex STUN, TURN and DTLS on one UDP socket (as required by WebRTC) and supports use_srtp. It's in it's very early stages but it's working and I feel it's on the right track. Suggestions are welcome! https://github.com/ast/webrtc --Albin From tommy.mattsson@REDACTED Mon Apr 8 16:56:12 2019 From: tommy.mattsson@REDACTED (Mattsson, Tommy) Date: Mon, 8 Apr 2019 14:56:12 +0000 Subject: [erlang-questions] rebar3 release add extra directories Message-ID: Hello. I am trying to build a release using rebar3. The release is supposed to include nitrogen which has some extra directories that needs to be included. For example the dependency simple_bridge has a directory named "etc" that needs to end up in the release. When using reltool for creatiing the release it is possible to to add this in the a config file {app, simple_bridge, [{incl_cond, include}, {mod, yaws_simple_bridge_sup, [{incl_cond, exclude}]}, {incl_app_filters, ["^include", "^priv", "^ebin", "^etc"]}, But when using rebar3 and relx I can't find any options for relx that acts in a similar way as the incl_app_filters option does for reltool. Am I missing something or does the functionality just not exist for relx? If it doesn't exist, does anyone have an idea of if and/or when it will be added? Best regards, Tommy -------------- next part -------------- An HTML attachment was scrubbed... URL: From t@REDACTED Mon Apr 8 17:13:17 2019 From: t@REDACTED (Tristan Sloughter) Date: Mon, 08 Apr 2019 11:13:17 -0400 Subject: [erlang-questions] rebar3 release add extra directories In-Reply-To: References: Message-ID: <2c00735b-29f7-4413-95a0-c30372900340@www.fastmail.com> Hi Tommy, there is not support for include filters per application in relx. I don't have a good answer for how to make this work at this time besides a hack overlay that involves hard coding versions like: {copy, "_build/default/simple_bridge/etc", "lib/simple_bridge-X.Y.Z/etc"} We want to have feature parity with reltool but have never prioritized it as a whole, instead only adding such features as they are requested. But I also find this to be a questionable feature since it means application authors can expect the user to have to use this feature to properly use their app in a release when they should just put the additional files in the priv directory. Though I suppose it is possible that you'd have multiple directories under priv and want to exclude specific ones in a release, so I take it back on being questionable, but it might be best as a way to only limit what in priv is kept. I also just took a look at what is in simple_bridge/etc and it is a .config file. Is the application loading this file at run time? How is the user expected to modify the values if that is the case? Defaults should be kept in simple_bridge.app's env list and the user building the release can override them with their own sys.config. Tristan On Mon, Apr 8, 2019, at 08:56, Mattsson, Tommy wrote: > Hello. > I am trying to build a release using rebar3. The release is supposed to include nitrogen which has some extra directories that needs to be included. For example the dependency simple_bridge has a directory named "etc" that needs to end up in the release. > When using reltool for creatiing the release it is possible to to add this in the a config file > > {app, simple_bridge, [{incl_cond, include}, > {mod, yaws_simple_bridge_sup, [{incl_cond, exclude}]}, > {incl_app_filters, ["^include", "^priv", "^ebin", "^etc"]}, > But when using rebar3 and relx I can't find any options for relx that acts in a similar way as the incl_app_filters option does for reltool. > Am I missing something or does the functionality just not exist for relx? If it doesn't exist, does anyone have an idea of if and/or when it will be added? > > > Best regards, > Tommy > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Mon Apr 8 21:54:44 2019 From: mjtruog@REDACTED (Michael Truog) Date: Mon, 8 Apr 2019 12:54:44 -0700 Subject: [erlang-questions] [erlang-announce] Erlang OTP 22.0-rc2 is available for testing! In-Reply-To: References: Message-ID: <70c49875-a44e-304c-e752-d403101b2d93@gmail.com> On 3/26/19 8:47 AM, Kenneth Lundin wrote: > > > 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. > o The binary matching optimizations are now applicable in many > more circumstances than before. > o 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! > > _______________________________________________ > erlang-announce mailing list > erlang-announce@REDACTED > http://erlang.org/mailman/listinfo/erlang-announce Hi Kenneth, It looks like the Erlang Binary Term Format change previously added in 19.0rc-1 was never documented (to cause the creation integer to be 32bits for pids, ports and refs) though the new format is being forced with a recent commit for 22.0rc-2 (https://github.com/erlang/otp/commit/78ea501bcc84bd8bd49da97e514c1c3b20682d86). The change wasn't announced in your email, nor the necessity of the switch to NEW_PID_EXT/NEW_PORT_EXT/NEWER_REFERENCE_EXT for all future Erlang integration. Best Regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Tue Apr 9 01:28:49 2019 From: lloyd@REDACTED (lloyd@REDACTED) Date: Mon, 8 Apr 2019 19:28:49 -0400 (EDT) Subject: [erlang-questions] digraph questions Message-ID: <1554766129.61628629@apps.rackspace.com> The Erlang digraph library looks like it may provide an interesting way to diagram scenes in a novel. 1> Scene10 = digraph:new(). Imagine: Setting:"park" Character1:"Franco" Character2:"Sophia" 2> digraph:add_vertex(Scene10, "Park", "Night"). 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). OK to here EXCEPT command 5 returns: ['$e'|0] 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). OK to here EXCEPT command 5 returns: ['$e'|0] 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). ['$e'|1] Wah! Question 1: How do I see labels? Question 2: Be cool to add a sequence of actions. I can probably figure this out, but is there an elegant solution? Question 3: I'd love to visualize the graph. I see it can be done in Elixir. But I don't know Elixir. Has anyone programmed a way to visualize digraphs in Erlang? Comment: Digraph is crying out for a comprehensive tutorial. I'd love to do it, but just don't know enough yet. Many thanks, LRP -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Tue Apr 9 02:46:21 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Tue, 9 Apr 2019 12:46:21 +1200 Subject: [erlang-questions] digraph questions In-Reply-To: <1554766129.61628629@apps.rackspace.com> References: <1554766129.61628629@apps.rackspace.com> Message-ID: The obvious way to visualise a graph would be to drive something like GraphViz or Gephi or, ideally, UbiGraph (https://github.com/alan86alves/ubigraph_server has a copy of the Linux x86-64 version; the official source is currently unreachable). There is an erlubi. But perhaps the thing you might want to look at first is https://github.com/aol/erlgraph It will take a bit of patching to get up to date with current versions of Erlang and Cowboy. On Tue, 9 Apr 2019 at 11:29, wrote: > The Erlang digraph library looks like it may provide an interesting way to > diagram scenes in a novel. > > > > 1> Scene10 = digraph:new(). > > > > Imagine: > > > > Setting:"park" > > Character1:"Franco" > > Character2:"Sophia" > > > > 2> digraph:add_vertex(Scene10, "Park", "Night"). > > 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). > > 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). > > 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). > > > > OK to here EXCEPT command 5 returns: > > > > ['$e'|0] > > > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > > > OK to here EXCEPT command 5 returns: > > > > ['$e'|0] > > > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > ['$e'|1] > > > > Wah! > > > > Question 1: How do I see labels? > > > > Question 2: Be cool to add a sequence of actions. I can probably figure > this out, but is there an elegant solution? > > > > Question 3: I'd love to visualize the graph. I see it can be done in > Elixir. But I don't know Elixir. Has anyone programmed a way to visualize > digraphs in Erlang? > > > > Comment: Digraph is crying out for a comprehensive tutorial. I'd love to > do it, but just don't know enough yet. > > > > Many thanks, > > > > LRP > > > > > > > > > _______________________________________________ > 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 Tue Apr 9 05:33:35 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Mon, 8 Apr 2019 23:33:35 -0400 Subject: [erlang-questions] digraph questions In-Reply-To: References: <1554766129.61628629@apps.rackspace.com> Message-ID: <6C9599F5-E8AE-4011-B6BF-9F553EFBAB26@writersglen.com> Many thanks, Richard. I?ll definitively follow up. Can you tell me how to return the labels? All the best, Lloyd Sent from my iPad > On Apr 8, 2019, at 8:46 PM, Richard O'Keefe wrote: > > The obvious way to visualise a graph would be to drive > something like GraphViz or Gephi or, ideally, UbiGraph > (https://github.com/alan86alves/ubigraph_server has a > copy of the Linux x86-64 version; the official source > is currently unreachable). There is an erlubi. But > perhaps the thing you might want to look at first is > https://github.com/aol/erlgraph > It will take a bit of patching to get up to date with > current versions of Erlang and Cowboy. > >> On Tue, 9 Apr 2019 at 11:29, wrote: >> The Erlang digraph library looks like it may provide an interesting way to diagram scenes in a novel. >> >> 1> Scene10 = digraph:new(). >> >> Imagine: >> >> Setting:"park" >> Character1:"Franco" >> Character2:"Sophia" >> >> 2> digraph:add_vertex(Scene10, "Park", "Night"). >> 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). >> 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). >> 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). >> >> OK to here EXCEPT command 5 returns: >> >> ['$e'|0] >> >> 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). >> >> OK to here EXCEPT command 5 returns: >> >> ['$e'|0] >> >> 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). >> ['$e'|1] >> >> Wah! >> >> Question 1: How do I see labels? >> >> Question 2: Be cool to add a sequence of actions. I can probably figure this out, but is there an elegant solution? >> >> Question 3: I'd love to visualize the graph. I see it can be done in Elixir. But I don't know Elixir. Has anyone programmed a way to visualize digraphs in Erlang? >> >> Comment: Digraph is crying out for a comprehensive tutorial. I'd love to do it, but just don't know enough yet. >> >> Many thanks, >> >> LRP >> >> >> >> >> _______________________________________________ >> 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 Tue Apr 9 07:59:23 2019 From: bob@REDACTED (Bob Ippolito) Date: Mon, 8 Apr 2019 22:59:23 -0700 Subject: [erlang-questions] digraph questions In-Reply-To: <6C9599F5-E8AE-4011-B6BF-9F553EFBAB26@writersglen.com> References: <1554766129.61628629@apps.rackspace.com> <6C9599F5-E8AE-4011-B6BF-9F553EFBAB26@writersglen.com> Message-ID: The data structures here are all opaque, which is why their representations in the terminal don't see very useful. To get the label, you use the digraph:vertex/2 or digraph:edge/2 functions. You can discover this by reading the documentation and search for label, these are the only functions that have a label anywhere in their return types. You can traverse the whole graph by using digraph:vertices/1 and then get the label and edges for each vertex from there (and get the label of each edge along the way). Usage of digraph would look something like: 1> Scene10 = digraph:new(). {digraph,#Ref<0.1177877097.1300365313.19691>, #Ref<0.1177877097.1300365313.19692>, #Ref<0.1177877097.1300365313.19693>,true} 2> digraph:add_vertex(Scene10, "Franco", "Old and fat"). "Franco" 3> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). "Sophia" 4> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). ['$e'|0] 5> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). ['$e'|1] 6> digraph:vertex(Scene10, "Franco"). {"Franco","Old and fat"} 7> digraph:edges(Scene10, "Franco"). [['$e'|1],['$e'|0]] 8> [digraph:edge(Scene10, E) || E <- digraph:edges(Scene10, "Franco")]. [{['$e'|1],"Sophia","Franco","hates"}, {['$e'|0],"Franco","Sophia","loves"}] Using digraph in the shell is probably not an ideal user experience because it uses ets tables behind the scene, and they'll be destroyed when your shell process crashes (e.g. the first time you make a mistake!). Searching for "erlang digraph graphviz" comes up with a few projects that seem relevant to your visualization needs. -bob On Mon, Apr 8, 2019 at 8:33 PM Lloyd R. Prentice wrote: > Many thanks, Richard. I?ll definitively follow up. > > Can you tell me how to return the labels? > > All the best, > > Lloyd > > Sent from my iPad > > On Apr 8, 2019, at 8:46 PM, Richard O'Keefe wrote: > > The obvious way to visualise a graph would be to drive > something like GraphViz or Gephi or, ideally, UbiGraph > (https://github.com/alan86alves/ubigraph_server has a > copy of the Linux x86-64 version; the official source > is currently unreachable). There is an erlubi. But > perhaps the thing you might want to look at first is > https://github.com/aol/erlgraph > It will take a bit of patching to get up to date with > current versions of Erlang and Cowboy. > > On Tue, 9 Apr 2019 at 11:29, wrote: > >> The Erlang digraph library looks like it may provide an interesting way >> to diagram scenes in a novel. >> >> >> >> 1> Scene10 = digraph:new(). >> >> >> >> Imagine: >> >> >> >> Setting:"park" >> >> Character1:"Franco" >> >> Character2:"Sophia" >> >> >> >> 2> digraph:add_vertex(Scene10, "Park", "Night"). >> >> 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). >> >> 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). >> >> 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). >> >> >> >> OK to here EXCEPT command 5 returns: >> >> >> >> ['$e'|0] >> >> >> >> 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). >> >> >> >> OK to here EXCEPT command 5 returns: >> >> >> >> ['$e'|0] >> >> >> >> 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). >> >> ['$e'|1] >> >> >> >> Wah! >> >> >> >> Question 1: How do I see labels? >> >> >> >> Question 2: Be cool to add a sequence of actions. I can probably figure >> this out, but is there an elegant solution? >> >> >> >> Question 3: I'd love to visualize the graph. I see it can be done in >> Elixir. But I don't know Elixir. Has anyone programmed a way to visualize >> digraphs in Erlang? >> >> >> >> Comment: Digraph is crying out for a comprehensive tutorial. I'd love to >> do it, but just don't know enough yet. >> >> >> >> Many thanks, >> >> >> >> LRP >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 mfrench@REDACTED Tue Apr 9 09:27:59 2019 From: mfrench@REDACTED (Mike French) Date: Tue, 9 Apr 2019 07:27:59 +0000 Subject: [erlang-questions] digraph questions In-Reply-To: <1554766129.61628629@apps.rackspace.com> References: <1554766129.61628629@apps.rackspace.com> Message-ID: I understand you are looking for a digraph use case, but to answer the actual question, see StoryFlow: http://www.ycwu.org/projects/infovis13.html Mike ________________________________ From: erlang-questions-bounces@REDACTED on behalf of lloyd@REDACTED Sent: Tuesday, April 9, 2019 2:28:49 AM To: erlang-questions@REDACTED Subject: [erlang-questions] digraph questions The Erlang digraph library looks like it may provide an interesting way to diagram scenes in a novel. 1> Scene10 = digraph:new(). Imagine: Setting:"park" Character1:"Franco" Character2:"Sophia" 2> digraph:add_vertex(Scene10, "Park", "Night"). 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). OK to here EXCEPT command 5 returns: ['$e'|0] 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). OK to here EXCEPT command 5 returns: ['$e'|0] 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). ['$e'|1] Wah! Question 1: How do I see labels? Question 2: Be cool to add a sequence of actions. I can probably figure this out, but is there an elegant solution? Question 3: I'd love to visualize the graph. I see it can be done in Elixir. But I don't know Elixir. Has anyone programmed a way to visualize digraphs in Erlang? Comment: Digraph is crying out for a comprehensive tutorial. I'd love to do it, but just don't know enough yet. Many thanks, LRP -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugo@REDACTED Tue Apr 9 10:43:06 2019 From: hugo@REDACTED (Hugo Mills) Date: Tue, 9 Apr 2019 08:43:06 +0000 Subject: [erlang-questions] digraph questions In-Reply-To: <1554766129.61628629@apps.rackspace.com> References: <1554766129.61628629@apps.rackspace.com> Message-ID: <20190409084306.GG1084@carfax.org.uk> On Mon, Apr 08, 2019 at 07:28:49PM -0400, lloyd@REDACTED wrote: > > The Erlang digraph library looks like it may provide an interesting way to diagram scenes in a novel. > > 1> Scene10 = digraph:new(). > > Imagine: > > Setting:"park" > Character1:"Franco" > Character2:"Sophia" > > 2> digraph:add_vertex(Scene10, "Park", "Night"). > 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). > 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). > 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). Congratulations, you just invented a subset of RDF. :) Also, I fear that contextus.net has now vanished, but there were a bunch of people at Southampton University about 10 years ago (including me) who were working on narrative descriptions in RDF. It gets more complicated when you have to deal with temporal descriptions (X loved Y until X discovered that Y was having an affair with Z), and different narrative timelines (the audience's experience of the timeline of Pulp Fiction is very different to that of the characters; CSI usually shows multiple inconsistent views of the crime over the course of an episode). You can also start modelling different characters' beliefs (see, for example, the end of Romeo and Juliet, where the plot hinges critically on what people think they know). I'm not sure if I've got any of the ontologies any more, but I can ask around the group and see if it's on someone's hard disk still... Hugo. > OK to here EXCEPT command 5 returns: > > ['$e'|0] > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > OK to here EXCEPT command 5 returns: > > ['$e'|0] > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > ['$e'|1] > > Wah! > > Question 1: How do I see labels? > > Question 2: Be cool to add a sequence of actions. I can probably figure this out, but is there an elegant solution? > > Question 3: I'd love to visualize the graph. I see it can be done in Elixir. But I don't know Elixir. Has anyone programmed a way to visualize digraphs in Erlang? > > Comment: Digraph is crying out for a comprehensive tutorial. I'd love to do it, but just don't know enough yet. -- Hugo Mills | Books are superior to radio: the soundtrack is hugo@REDACTED carfax.org.uk | better 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 hugo@REDACTED Tue Apr 9 10:52:02 2019 From: hugo@REDACTED (Hugo Mills) Date: Tue, 9 Apr 2019 08:52:02 +0000 Subject: [erlang-questions] digraph questions In-Reply-To: References: <1554766129.61628629@apps.rackspace.com> Message-ID: <20190409085202.GH1084@carfax.org.uk> On Tue, Apr 09, 2019 at 12:46:21PM +1200, Richard O'Keefe wrote: > The obvious way to visualise a graph would be to drive > something like GraphViz or Gephi or, ideally, UbiGraph > (https://github.com/alan86alves/ubigraph_server has a > copy of the Linux x86-64 version; the official source > is currently unreachable). There is an erlubi. But > perhaps the thing you might want to look at first is > https://github.com/aol/erlgraph > It will take a bit of patching to get up to date with > current versions of Erlang and Cowboy. These kinds of graphs get *very* dense, and it's almost impossible to draw the whole graph in any meaningful sense. You can't just throw the graph at a graph drawing package and expect to get usable output. You really need to spend the time on working out what it is you want to show, whether it's "everything directly relating to this one character", or "the sequence of events in this scene", or "who was with who over the course of the story", and then strip out everything else to show the graph. You're going to be spending much more of your time thinking about *what* to show than how to show it, in my experience. Hugo. > On Tue, 9 Apr 2019 at 11:29, wrote: > > > The Erlang digraph library looks like it may provide an interesting way to > > diagram scenes in a novel. > > > > > > > > 1> Scene10 = digraph:new(). > > > > > > > > Imagine: > > > > > > > > Setting:"park" > > > > Character1:"Franco" > > > > Character2:"Sophia" > > > > > > > > 2> digraph:add_vertex(Scene10, "Park", "Night"). > > > > 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). > > > > 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). > > > > 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). > > > > > > > > OK to here EXCEPT command 5 returns: > > > > > > > > ['$e'|0] > > > > > > > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > > > > > > > OK to here EXCEPT command 5 returns: > > > > > > > > ['$e'|0] > > > > > > > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > > > ['$e'|1] > > > > > > > > Wah! > > > > > > > > Question 1: How do I see labels? > > > > > > > > Question 2: Be cool to add a sequence of actions. I can probably figure > > this out, but is there an elegant solution? > > > > > > > > Question 3: I'd love to visualize the graph. I see it can be done in > > Elixir. But I don't know Elixir. Has anyone programmed a way to visualize > > digraphs in Erlang? > > > > > > > > Comment: Digraph is crying out for a comprehensive tutorial. I'd love to > > do it, but just don't know enough yet. > > > > > > > > Many thanks, > > > > > > > > LRP > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 -- Hugo Mills | Books are superior to radio: the soundtrack is hugo@REDACTED carfax.org.uk | better 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 mfrench@REDACTED Tue Apr 9 11:24:50 2019 From: mfrench@REDACTED (Mike French) Date: Tue, 9 Apr 2019 09:24:50 +0000 Subject: [erlang-questions] digraph questions In-Reply-To: <20190409084306.GG1084@carfax.org.uk> References: <1554766129.61628629@apps.rackspace.com>, <20190409084306.GG1084@carfax.org.uk> Message-ID: <3f4521aea69348f99b2d198772f581ce@tahakom.com> Yes, try Inception, or Memento, which has ~linear narrative of a non-linear character :) The problem with RDF is that everything is a subset of RDF. Just as I gave up formal methods when an expert told me that "floating point... that's still a research topic" (RAL 1990), so I gave up RDF when the philosophers started arguing about a Standard Upper Ontology (SUO), for things like space and time, which looked like it could last for decades. There should be a harder prequel CS deadlock problem called The Arguing Philosophers, about where to have dinner in the first place). For a practical interactive system that uses graph-based spatio-temporal data, see Palantir. In addition to tagged text and table listings, it has 3 connected views of the same data: graph, map and timeline. StoryFlow cites XKCD as a reference: https://xkcd.com/657/ Mike ________________________________ From: erlang-questions-bounces@REDACTED on behalf of Hugo Mills Sent: Tuesday, April 9, 2019 11:43 AM To: lloyd@REDACTED Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] digraph questions On Mon, Apr 08, 2019 at 07:28:49PM -0400, lloyd@REDACTED wrote: > > The Erlang digraph library looks like it may provide an interesting way to diagram scenes in a novel. > > 1> Scene10 = digraph:new(). > > Imagine: > > Setting:"park" > Character1:"Franco" > Character2:"Sophia" > > 2> digraph:add_vertex(Scene10, "Park", "Night"). > 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). > 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). > 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). Congratulations, you just invented a subset of RDF. :) Also, I fear that contextus.net has now vanished, but there were a bunch of people at Southampton University about 10 years ago (including me) who were working on narrative descriptions in RDF. It gets more complicated when you have to deal with temporal descriptions (X loved Y until X discovered that Y was having an affair with Z), and different narrative timelines (the audience's experience of the timeline of Pulp Fiction is very different to that of the characters; CSI usually shows multiple inconsistent views of the crime over the course of an episode). You can also start modelling different characters' beliefs (see, for example, the end of Romeo and Juliet, where the plot hinges critically on what people think they know). I'm not sure if I've got any of the ontologies any more, but I can ask around the group and see if it's on someone's hard disk still... Hugo. > OK to here EXCEPT command 5 returns: > > ['$e'|0] > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > OK to here EXCEPT command 5 returns: > > ['$e'|0] > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > ['$e'|1] > > Wah! > > Question 1: How do I see labels? > > Question 2: Be cool to add a sequence of actions. I can probably figure this out, but is there an elegant solution? > > Question 3: I'd love to visualize the graph. I see it can be done in Elixir. But I don't know Elixir. Has anyone programmed a way to visualize digraphs in Erlang? > > Comment: Digraph is crying out for a comprehensive tutorial. I'd love to do it, but just don't know enough yet. -- Hugo Mills | Books are superior to radio: the soundtrack is hugo@REDACTED carfax.org.uk | better http://carfax.org.uk/ | PGP: E2AB1DE4 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc@REDACTED Tue Apr 9 12:39:12 2019 From: marc@REDACTED (Marc Worrell) Date: Tue, 9 Apr 2019 12:39:12 +0200 Subject: [erlang-questions] [ANN] Zotonic release 0.48.0 Message-ID: <5776286D-441A-4A6C-8BA9-4E3DC3A7F6F8@worrell.nl> Zotonic is the Erlang Content Management System and Framework [1] We have released version 0.48.0. This is a maintenance release which delivers a couple of new features: ? mod_geoip to lookup Geo information for an IP address ? New connect dialog in the admin ? Option to let users agree to changed Terms & Conditions after logon ? Changes to mod_clamav virus scanning to allow uploads of files larger than the maximum file size for clamd. Full release notes are at: http://docs.zotonic.com/en/0.x/developer-guide/releasenotes/rel_0.48.0.html Kind regards from the Zotonic core team Marc Worrell [1] http://zotonic.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugo@REDACTED Tue Apr 9 13:01:00 2019 From: hugo@REDACTED (Hugo Mills) Date: Tue, 9 Apr 2019 11:01:00 +0000 Subject: [erlang-questions] digraph questions In-Reply-To: <3f4521aea69348f99b2d198772f581ce@tahakom.com> References: <1554766129.61628629@apps.rackspace.com> <20190409084306.GG1084@carfax.org.uk> <3f4521aea69348f99b2d198772f581ce@tahakom.com> Message-ID: <20190409110100.GI1084@carfax.org.uk> On Tue, Apr 09, 2019 at 09:24:50AM +0000, Mike French wrote: > Yes, try Inception, or Memento, which has ~linear narrative of a > non-linear character :) It's almost more interesting (and more relatable) to find cases which aren't science fiction, which is why I picked Pulp Fiction and CSI for examples of time travel and alternate universes respectively. There's also fun to be had over characters that appear in different guises: Holmes as played by Rathbone, Brett or Downey, say, or Death as portrayed in Discworld, Sandman, The Seventh Seal, or Bill and Ted... > The problem with RDF is that everything is a subset of RDF. Just as > I gave up formal methods when an expert told me that "floating > point... that's still a research topic" (RAL 1990), so I gave up RDF > when the philosophers started arguing about a Standard Upper > Ontology (SUO), for things like space and time, which looked like it > could last for decades. There should be a harder prequel CS deadlock > problem called The Arguing Philosophers, about where to have dinner > in the first place). Practical RDF, lesson 1: You can pretty much ignore anything that calls itself an upper ontology, because it's mostly going to be "here's all these obvious things, and we'll leave all the hard details for you to sort out". There is, for example, a perfectly good time ontology (OWL Time, from the W3C) which covers both topological and measured times, the latter being open to multiple calendar representations (although they concentrate on the proleptic Gregorian calendar in the spec). For spatial, there's a whole load of Geo-* stuff that works in two dimensions, and mostly falls back on WKT. I've certainly seen a good topological spatial representation, but that was nearly two decades ago, and I think it's probably been lost since. The practical approach to RDF: pick what's already out there, and what's practical to use now. Fill in the bits that aren't available off the shelf yourself. Prov-O for processes, OWL Time for time, WKT for spatial, QUDT for units, Data Cube for tablular structure, ... > For a practical interactive system that uses graph-based spatio-temporal data, see Palantir. In addition to tagged text and table listings, it has 3 connected views of the same data: graph, map and timeline. > > > StoryFlow cites XKCD as a reference: > > > https://xkcd.com/657/ > > ________________________________ > From: erlang-questions-bounces@REDACTED on behalf of Hugo Mills > Sent: Tuesday, April 9, 2019 11:43 AM > To: lloyd@REDACTED > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] digraph questions > > On Mon, Apr 08, 2019 at 07:28:49PM -0400, lloyd@REDACTED wrote: > > > > The Erlang digraph library looks like it may provide an interesting way to diagram scenes in a novel. > > > > 1> Scene10 = digraph:new(). > > > > Imagine: > > > > Setting:"park" > > Character1:"Franco" > > Character2:"Sophia" > > > > 2> digraph:add_vertex(Scene10, "Park", "Night"). > > 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). > > 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). > > 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). > > Congratulations, you just invented a subset of RDF. :) > > Also, I fear that contextus.net has now vanished, but there were a > bunch of people at Southampton University about 10 years ago > (including me) who were working on narrative descriptions in RDF. > > It gets more complicated when you have to deal with temporal > descriptions (X loved Y until X discovered that Y was having an affair > with Z), and different narrative timelines (the audience's experience > of the timeline of Pulp Fiction is very different to that of the > characters; CSI usually shows multiple inconsistent views of the crime > over the course of an episode). You can also start modelling different > characters' beliefs (see, for example, the end of Romeo and Juliet, > where the plot hinges critically on what people think they know). > > I'm not sure if I've got any of the ontologies any more, but I can > ask around the group and see if it's on someone's hard disk still... > > Hugo. > > > OK to here EXCEPT command 5 returns: > > > > ['$e'|0] > > > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > > > OK to here EXCEPT command 5 returns: > > > > ['$e'|0] > > > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > ['$e'|1] > > > > Wah! > > > > Question 1: How do I see labels? > > > > Question 2: Be cool to add a sequence of actions. I can probably figure this out, but is there an elegant solution? > > > > Question 3: I'd love to visualize the graph. I see it can be done in Elixir. But I don't know Elixir. Has anyone programmed a way to visualize digraphs in Erlang? > > > > Comment: Digraph is crying out for a comprehensive tutorial. I'd love to do it, but just don't know enough yet. > -- Hugo Mills | Great oxymorons of the world, no. 3: hugo@REDACTED carfax.org.uk | Military Intelligence 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 seriy.pr@REDACTED Tue Apr 9 13:03:19 2019 From: seriy.pr@REDACTED (=?UTF-8?B?0KHQtdGA0LPQtdC5INCf0YDQvtGF0L7RgNC+0LI=?=) Date: Tue, 9 Apr 2019 13:03:19 +0200 Subject: [erlang-questions] rust c-node ? Message-ID: You might be interested in my implementation of external term format in Rust https://github.com/seriyps/rust-erl-ext But it was my first Rust project and was never used in production as far as I know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Tue Apr 9 16:04:56 2019 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 9 Apr 2019 16:04:56 +0200 Subject: [erlang-questions] [erlang-announce] Erlang OTP 22.0-rc2 is available for testing! In-Reply-To: <70c49875-a44e-304c-e752-d403101b2d93@gmail.com> References: <70c49875-a44e-304c-e752-d403101b2d93@gmail.com> Message-ID: <1554818696.4855.36.camel@erlang.org> On m?n, 2019-04-08 at 12:54 -0700, Michael Truog wrote: > On 3/26/19 8:47 AM, Kenneth Lundin wrote: > > 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! > > > > > > _______________________________________________ > > erlang-announce mailing list > > erlang-announce@REDACTED > > http://erlang.org/mailman/listinfo/erlang-announce> > id="-x-evo-selection- > > start-marker"> > ?Hi Kenneth, > It looks like the Erlang Binary Term Format change previously added in 19.0rc- > 1 was never documented (to cause the creation integer to be 32bits for pids, > ports and refs) though the new format is being forced with a recent commit for > 22.0rc-2 (https://github.com/erlang/otp/commit/78ea501bcc84bd8bd49da97e514c1c3 > b20682d86).? The change wasn't announced in your email, nor the necessity of > the switch to NEW_PID_EXT/NEW_PORT_EXT/NEWER_REFERENCE_EXT for all future > Erlang integration. > The missing documentation was clearly a mistake. Thanks for pointing that out, Michael. The revised plan now is to 1. Revert the removal of encoding the old pid/port/ref tags for OTP 22. 2. Document NEW_PID_EXT/NEW_PORT_EXT/NEWER_REFERENCE_EXT which have existed since OTP 19. 3. Mark the old as deprecated and announce for upcoming removal of old encoding in OTP 23. ? /Sverker -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Tue Apr 9 17:19:19 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 9 Apr 2019 11:19:19 -0400 Subject: [erlang-questions] digraph questions In-Reply-To: <20190409110100.GI1084@carfax.org.uk> References: <1554766129.61628629@apps.rackspace.com> <20190409084306.GG1084@carfax.org.uk> <3f4521aea69348f99b2d198772f581ce@tahakom.com> <20190409110100.GI1084@carfax.org.uk> Message-ID: <87F8024E-FA09-4AAB-84BB-65ED0817DB39@writersglen.com> Much appreciate the many inspiring responses. Bob, I must have experienced a touch of brain lapse. Turns out I did execute vertex/2. Just failed to notice that it returned the label. Apologies to all. Hugo, et. al., I?m very interested in your experience graphing narrative structures. I can understand how attempts to graph the narrative flow of a serious work of fiction after the fact can result in dense graphs with many ontological issues. I?m playing around with a kind writer?s sketch pad? a tool with which a writer can quickly visualize and construct a scene involving several characters and interactively play around with different sequences of motivation, action, and consequence. In my experience as a novelist, I often don?t know what?s going to happen to my characters when I throw them together in a setting to construct a scene. I can write it out as a creative act of discovery, but then the temptation is to get stuck on that one of many possible solutions. So I?ve been thinking about a mind-map kind of application with quick turn-around to imagine and visualize different possible scenarios. The graph structure definitely has limitations. Joe hits Bob is easy to graph. But why, what alternatives did Bob consider before responding, how is the dispute resolved, etc., is more challenging. I welcome any and all ideas. Thanks again to all. Best, Lloyd Sent from my iPad > On Apr 9, 2019, at 7:01 AM, Hugo Mills wrote: > >> On Tue, Apr 09, 2019 at 09:24:50AM +0000, Mike French wrote: >> Yes, try Inception, or Memento, which has ~linear narrative of a >> non-linear character :) > > It's almost more interesting (and more relatable) to find cases > which aren't science fiction, which is why I picked Pulp Fiction and > CSI for examples of time travel and alternate universes respectively. > > There's also fun to be had over characters that appear in different > guises: Holmes as played by Rathbone, Brett or Downey, say, or Death > as portrayed in Discworld, Sandman, The Seventh Seal, or Bill and > Ted... > >> The problem with RDF is that everything is a subset of RDF. Just as >> I gave up formal methods when an expert told me that "floating >> point... that's still a research topic" (RAL 1990), so I gave up RDF >> when the philosophers started arguing about a Standard Upper >> Ontology (SUO), for things like space and time, which looked like it >> could last for decades. There should be a harder prequel CS deadlock >> problem called The Arguing Philosophers, about where to have dinner >> in the first place). > > Practical RDF, lesson 1: You can pretty much ignore anything that > calls itself an upper ontology, because it's mostly going to be > "here's all these obvious things, and we'll leave all the hard details > for you to sort out". > > There is, for example, a perfectly good time ontology (OWL Time, > from the W3C) which covers both topological and measured times, the > latter being open to multiple calendar representations (although they > concentrate on the proleptic Gregorian calendar in the spec). > > For spatial, there's a whole load of Geo-* stuff that works in two > dimensions, and mostly falls back on WKT. I've certainly seen a good > topological spatial representation, but that was nearly two decades > ago, and I think it's probably been lost since. > > The practical approach to RDF: pick what's already out there, and > what's practical to use now. Fill in the bits that aren't available > off the shelf yourself. Prov-O for processes, OWL Time for time, WKT > for spatial, QUDT for units, Data Cube for tablular structure, ... > >> For a practical interactive system that uses graph-based spatio-temporal data, see Palantir. In addition to tagged text and table listings, it has 3 connected views of the same data: graph, map and timeline. >> >> >> StoryFlow cites XKCD as a reference: >> >> >> https://xkcd.com/657/ >> >> ________________________________ >> From: erlang-questions-bounces@REDACTED on behalf of Hugo Mills >> Sent: Tuesday, April 9, 2019 11:43 AM >> To: lloyd@REDACTED >> Cc: erlang-questions@REDACTED >> Subject: Re: [erlang-questions] digraph questions >> >>> On Mon, Apr 08, 2019 at 07:28:49PM -0400, lloyd@REDACTED wrote: >>> >>> The Erlang digraph library looks like it may provide an interesting way to diagram scenes in a novel. >>> >>> 1> Scene10 = digraph:new(). >>> >>> Imagine: >>> >>> Setting:"park" >>> Character1:"Franco" >>> Character2:"Sophia" >>> >>> 2> digraph:add_vertex(Scene10, "Park", "Night"). >>> 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). >>> 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). >>> 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). >> >> Congratulations, you just invented a subset of RDF. :) >> >> Also, I fear that contextus.net has now vanished, but there were a >> bunch of people at Southampton University about 10 years ago >> (including me) who were working on narrative descriptions in RDF. >> >> It gets more complicated when you have to deal with temporal >> descriptions (X loved Y until X discovered that Y was having an affair >> with Z), and different narrative timelines (the audience's experience >> of the timeline of Pulp Fiction is very different to that of the >> characters; CSI usually shows multiple inconsistent views of the crime >> over the course of an episode). You can also start modelling different >> characters' beliefs (see, for example, the end of Romeo and Juliet, >> where the plot hinges critically on what people think they know). >> >> I'm not sure if I've got any of the ontologies any more, but I can >> ask around the group and see if it's on someone's hard disk still... >> >> Hugo. >> >>> OK to here EXCEPT command 5 returns: >>> >>> ['$e'|0] >>> >>> 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). >>> >>> OK to here EXCEPT command 5 returns: >>> >>> ['$e'|0] >>> >>> 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). >>> ['$e'|1] >>> >>> Wah! >>> >>> Question 1: How do I see labels? >>> >>> Question 2: Be cool to add a sequence of actions. I can probably figure this out, but is there an elegant solution? >>> >>> Question 3: I'd love to visualize the graph. I see it can be done in Elixir. But I don't know Elixir. Has anyone programmed a way to visualize digraphs in Erlang? >>> >>> Comment: Digraph is crying out for a comprehensive tutorial. I'd love to do it, but just don't know enough yet. >> > > -- > Hugo Mills | Great oxymorons of the world, no. 3: > hugo@REDACTED carfax.org.uk | Military Intelligence > http://carfax.org.uk/ | > PGP: E2AB1DE4 | From lloyd@REDACTED Tue Apr 9 18:53:43 2019 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 9 Apr 2019 12:53:43 -0400 (EDT) Subject: [erlang-questions] digraph questions In-Reply-To: References: <1554766129.61628629@apps.rackspace.com> Message-ID: <1554828823.57348297@apps.rackspace.com> Way cool, John! Thanks. I'll play. Best, Lloyd -----Original Message----- From: "John Krukoff" Sent: Tuesday, April 9, 2019 11:35am To: "lloyd@REDACTED" , "erlang-questions@REDACTED" Subject: RE: [erlang-questions] digraph questions ? Question 3: I'd love to visualize the graph. I see it can be done in Elixir. But I don't know Elixir. Has anyone programmed a way to visualize digraphs in Erlang? I had the same problem, here was my solution: https://github.com/jkrukoff/digraph_export If you?re working with non-trivial data sets, you?d likely need to invest some time in how the filtering and display options work in your viewer of choice if you?d like to make use my library. -- John Krukoff john@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrukoff@REDACTED Tue Apr 9 17:35:47 2019 From: jkrukoff@REDACTED (John Krukoff) Date: Tue, 9 Apr 2019 15:35:47 +0000 Subject: [erlang-questions] digraph questions In-Reply-To: <1554766129.61628629@apps.rackspace.com> References: <1554766129.61628629@apps.rackspace.com> Message-ID: ? Question 3: I'd love to visualize the graph. I see it can be done in Elixir. But I don't know Elixir. Has anyone programmed a way to visualize digraphs in Erlang? I had the same problem, here was my solution: https://github.com/jkrukoff/digraph_export If you?re working with non-trivial data sets, you?d likely need to invest some time in how the filtering and display options work in your viewer of choice if you?d like to make use my library. -- John Krukoff john@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6290 bytes Desc: not available URL: From raoknz@REDACTED Wed Apr 10 02:05:16 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Wed, 10 Apr 2019 12:05:16 +1200 Subject: [erlang-questions] digraph questions In-Reply-To: <20190409085202.GH1084@carfax.org.uk> References: <1554766129.61628629@apps.rackspace.com> <20190409085202.GH1084@carfax.org.uk> Message-ID: I appreciate that these graphs get dense. That is precisely why I mentioned Gephi and UbiGraph: three dimensional layout. Ubigraph in particular is good at making dynamic 3D layouts; if anyone knows a more actively maintained equivalent I would love to hear of it. There's a fair bit of work going on in systems biology. The C. elegans connectome (wormwiring.org), for example, has many thousands of edges. So visualising rather large networks is a hot topic. On Tue, 9 Apr 2019 at 20:52, Hugo Mills wrote: > On Tue, Apr 09, 2019 at 12:46:21PM +1200, Richard O'Keefe wrote: > > The obvious way to visualise a graph would be to drive > > something like GraphViz or Gephi or, ideally, UbiGraph > > (https://github.com/alan86alves/ubigraph_server has a > > copy of the Linux x86-64 version; the official source > > is currently unreachable). There is an erlubi. But > > perhaps the thing you might want to look at first is > > https://github.com/aol/erlgraph > > It will take a bit of patching to get up to date with > > current versions of Erlang and Cowboy. > > These kinds of graphs get *very* dense, and it's almost impossible > to draw the whole graph in any meaningful sense. You can't just throw > the graph at a graph drawing package and expect to get usable output. > > You really need to spend the time on working out what it is you > want to show, whether it's "everything directly relating to this one > character", or "the sequence of events in this scene", or "who was > with who over the course of the story", and then strip out everything > else to show the graph. You're going to be spending much more of your > time thinking about *what* to show than how to show it, in my > experience. > > Hugo. > > > On Tue, 9 Apr 2019 at 11:29, wrote: > > > > > The Erlang digraph library looks like it may provide an interesting > way to > > > diagram scenes in a novel. > > > > > > > > > > > > 1> Scene10 = digraph:new(). > > > > > > > > > > > > Imagine: > > > > > > > > > > > > Setting:"park" > > > > > > Character1:"Franco" > > > > > > Character2:"Sophia" > > > > > > > > > > > > 2> digraph:add_vertex(Scene10, "Park", "Night"). > > > > > > 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). > > > > > > 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). > > > > > > 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). > > > > > > > > > > > > OK to here EXCEPT command 5 returns: > > > > > > > > > > > > ['$e'|0] > > > > > > > > > > > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > > > > > > > > > > > OK to here EXCEPT command 5 returns: > > > > > > > > > > > > ['$e'|0] > > > > > > > > > > > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). > > > > > > ['$e'|1] > > > > > > > > > > > > Wah! > > > > > > > > > > > > Question 1: How do I see labels? > > > > > > > > > > > > Question 2: Be cool to add a sequence of actions. I can probably figure > > > this out, but is there an elegant solution? > > > > > > > > > > > > Question 3: I'd love to visualize the graph. I see it can be done in > > > Elixir. But I don't know Elixir. Has anyone programmed a way to > visualize > > > digraphs in Erlang? > > > > > > > > > > > > Comment: Digraph is crying out for a comprehensive tutorial. I'd love > to > > > do it, but just don't know enough yet. > > > > > > > > > > > > Many thanks, > > > > > > > > > > > > LRP > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > -- > Hugo Mills | Books are superior to radio: the soundtrack is > hugo@REDACTED carfax.org.uk | better > http://carfax.org.uk/ | > PGP: E2AB1DE4 | > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Wed Apr 10 05:13:30 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 9 Apr 2019 23:13:30 -0400 Subject: [erlang-questions] digraph questions In-Reply-To: References: <1554766129.61628629@apps.rackspace.com> <20190409085202.GH1084@carfax.org.uk> Message-ID: Hi Richard, I?ve found a few interesting JavaScript libraries for visualizing graphs, vis.js among others. I don?t know if they?re sufficient to deal with highly dense graphs or if they provide 3D rendering. Vis.js also has nice features for rendering time lines. Vis.js looks sufficiently feature rich for my purposes. So I?m looking into creating a set if custom Nitrogen elements based on vis.js. I?m both skill-set and time constrained so it will be awhile before I can show results. Ideally, I?d like to see a Nitrogen plug-in that?s highly interactive. But I?ve got to polish off erlPress first and much else to do. Best wishes, Lloyd Sent from my iPad > On Apr 9, 2019, at 8:05 PM, Richard O'Keefe wrote: > > I appreciate that these graphs get dense. > That is precisely why I mentioned Gephi and UbiGraph: three dimensional layout. > Ubigraph in particular is good at making dynamic 3D layouts; > if anyone knows a more actively maintained equivalent I would love to hear of it. > > There's a fair bit of work going on in systems biology. > The C. elegans connectome (wormwiring.org), for example, > has many thousands of edges. So visualising rather large > networks is a hot topic. > > >> On Tue, 9 Apr 2019 at 20:52, Hugo Mills wrote: >> On Tue, Apr 09, 2019 at 12:46:21PM +1200, Richard O'Keefe wrote: >> > The obvious way to visualise a graph would be to drive >> > something like GraphViz or Gephi or, ideally, UbiGraph >> > (https://github.com/alan86alves/ubigraph_server has a >> > copy of the Linux x86-64 version; the official source >> > is currently unreachable). There is an erlubi. But >> > perhaps the thing you might want to look at first is >> > https://github.com/aol/erlgraph >> > It will take a bit of patching to get up to date with >> > current versions of Erlang and Cowboy. >> >> These kinds of graphs get *very* dense, and it's almost impossible >> to draw the whole graph in any meaningful sense. You can't just throw >> the graph at a graph drawing package and expect to get usable output. >> >> You really need to spend the time on working out what it is you >> want to show, whether it's "everything directly relating to this one >> character", or "the sequence of events in this scene", or "who was >> with who over the course of the story", and then strip out everything >> else to show the graph. You're going to be spending much more of your >> time thinking about *what* to show than how to show it, in my >> experience. >> >> Hugo. >> >> > On Tue, 9 Apr 2019 at 11:29, wrote: >> > >> > > The Erlang digraph library looks like it may provide an interesting way to >> > > diagram scenes in a novel. >> > > >> > > >> > > >> > > 1> Scene10 = digraph:new(). >> > > >> > > >> > > >> > > Imagine: >> > > >> > > >> > > >> > > Setting:"park" >> > > >> > > Character1:"Franco" >> > > >> > > Character2:"Sophia" >> > > >> > > >> > > >> > > 2> digraph:add_vertex(Scene10, "Park", "Night"). >> > > >> > > 3> digraph:add_vertex(Scene10, "Franco", "Old and fat"). >> > > >> > > 4> digraph:add_vertex(Scene10, "Sophia", "Young and beautiful"). >> > > >> > > 5> digraph:add_edge(Scene10, "Franco", "Sophia", "loves"). >> > > >> > > >> > > >> > > OK to here EXCEPT command 5 returns: >> > > >> > > >> > > >> > > ['$e'|0] >> > > >> > > >> > > >> > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). >> > > >> > > >> > > >> > > OK to here EXCEPT command 5 returns: >> > > >> > > >> > > >> > > ['$e'|0] >> > > >> > > >> > > >> > > 6> digraph:add_edge(Scene10, "Sophia", "Franco", "hates"). >> > > >> > > ['$e'|1] >> > > >> > > >> > > >> > > Wah! >> > > >> > > >> > > >> > > Question 1: How do I see labels? >> > > >> > > >> > > >> > > Question 2: Be cool to add a sequence of actions. I can probably figure >> > > this out, but is there an elegant solution? >> > > >> > > >> > > >> > > Question 3: I'd love to visualize the graph. I see it can be done in >> > > Elixir. But I don't know Elixir. Has anyone programmed a way to visualize >> > > digraphs in Erlang? >> > > >> > > >> > > >> > > Comment: Digraph is crying out for a comprehensive tutorial. I'd love to >> > > do it, but just don't know enough yet. >> > > >> > > >> > > >> > > Many thanks, >> > > >> > > >> > > >> > > LRP >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> >> >> -- >> Hugo Mills | Books are superior to radio: the soundtrack is >> hugo@REDACTED carfax.org.uk | better >> http://carfax.org.uk/ | >> PGP: E2AB1DE4 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Wed Apr 10 08:03:22 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 10 Apr 2019 09:03:22 +0300 Subject: [erlang-questions] WebRTC and DTLS and use_srtp In-Reply-To: References: Message-ID: Nif is a thing that one should avoid if possible. We use this one https://github.com/flussonic/dtls/blob/master/src/dtls4srtp.erl It is working and giving us webrtc in Flussonic On Mon, Apr 8, 2019 at 4:52 PM Albin Stig? wrote: > Hi, > > For anyone interested in WebRTC... After thinking more about this I > decided to write a GnuTLS DTLS NIF that allows me to multiplex STUN, > TURN and DTLS on one UDP socket (as required by WebRTC) and supports > use_srtp. > > It's in it's very early stages but it's working and I feel it's on the > right track. Suggestions are welcome! > > https://github.com/ast/webrtc > > > --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 Apr 10 08:12:54 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Wed, 10 Apr 2019 08:12:54 +0200 Subject: [erlang-questions] WebRTC and DTLS and use_srtp In-Reply-To: References: Message-ID: Thanks Max! Fantastic, I wasn't aware of your implementation. Agree completely about nifs... Was thinking about it more like a spring board because a pure Erlang implementation felt like too big an undertaking. What are you using for ICE? Can't seem to find an implementation in the linked repo? --Albin On Wed, Apr 10, 2019, 08:03 Max Lapshin wrote: > Nif is a thing that one should avoid if possible. > > We use this one > https://github.com/flussonic/dtls/blob/master/src/dtls4srtp.erl > > It is working and giving us webrtc in Flussonic > > On Mon, Apr 8, 2019 at 4:52 PM Albin Stig? wrote: > >> Hi, >> >> For anyone interested in WebRTC... After thinking more about this I >> decided to write a GnuTLS DTLS NIF that allows me to multiplex STUN, >> TURN and DTLS on one UDP socket (as required by WebRTC) and supports >> use_srtp. >> >> It's in it's very early stages but it's working and I feel it's on the >> right track. Suggestions are welcome! >> >> https://github.com/ast/webrtc >> >> >> --Albin >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy.mattsson@REDACTED Wed Apr 10 10:30:05 2019 From: tommy.mattsson@REDACTED (Mattsson, Tommy) Date: Wed, 10 Apr 2019 08:30:05 +0000 Subject: [erlang-questions] rebar3 release add extra directories In-Reply-To: <2c00735b-29f7-4413-95a0-c30372900340@www.fastmail.com> References: , <2c00735b-29f7-4413-95a0-c30372900340@www.fastmail.com> Message-ID: Hello Tristan, Thanks for the reply! I looked into overlays but it seemed to be quite tedious to do what I wanted to do. It seems that I managed to modify the third party stuff to ensure that the directories are using the priv directory instead. I can understand the perspective of forcing a specific structure, but maybe it isn't flexible enough for "the real world".. The project I am working on uses the correct structure, but not all projects do, so trouble arises forcing either modification of those third party projects or to not be able to use them. Thanks for your input and pointers! Much appreciated! ?? /Tommy ________________________________ From: erlang-questions-bounces@REDACTED on behalf of Tristan Sloughter Sent: Monday, April 8, 2019 5:13:17 PM To: Erlang Questions Subject: Re: [erlang-questions] rebar3 release add extra directories Hi Tommy, there is not support for include filters per application in relx. I don't have a good answer for how to make this work at this time besides a hack overlay that involves hard coding versions like: {copy, "_build/default/simple_bridge/etc", "lib/simple_bridge-X.Y.Z/etc"} We want to have feature parity with reltool but have never prioritized it as a whole, instead only adding such features as they are requested. But I also find this to be a questionable feature since it means application authors can expect the user to have to use this feature to properly use their app in a release when they should just put the additional files in the priv directory. Though I suppose it is possible that you'd have multiple directories under priv and want to exclude specific ones in a release, so I take it back on being questionable, but it might be best as a way to only limit what in priv is kept. I also just took a look at what is in simple_bridge/etc and it is a .config file. Is the application loading this file at run time? How is the user expected to modify the values if that is the case? Defaults should be kept in simple_bridge.app's env list and the user building the release can override them with their own sys.config. Tristan On Mon, Apr 8, 2019, at 08:56, Mattsson, Tommy wrote: Hello. I am trying to build a release using rebar3. The release is supposed to include nitrogen which has some extra directories that needs to be included. For example the dependency simple_bridge has a directory named "etc" that needs to end up in the release. When using reltool for creatiing the release it is possible to to add this in the a config file {app, simple_bridge, [{incl_cond, include}, {mod, yaws_simple_bridge_sup, [{incl_cond, exclude}]}, {incl_app_filters, ["^include", "^priv", "^ebin", "^etc"]}, But when using rebar3 and relx I can't find any options for relx that acts in a similar way as the incl_app_filters option does for reltool. Am I missing something or does the functionality just not exist for relx? If it doesn't exist, does anyone have an idea of if and/or when it will be added? Best regards, Tommy _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From v@REDACTED Wed Apr 10 13:08:32 2019 From: v@REDACTED (Valentin Micic) Date: Wed, 10 Apr 2019 13:08:32 +0200 Subject: [erlang-questions] hash_state() and Segmentation Fault Message-ID: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> Hi, I've been investigating a feasibility of saving of hash_state() -- used as a part of erlang:md5_init/md5_update/md5_final and/or their functional equivalents in crypto library; so it could be used later to implicitly reinitialize hash calculations. Well, (duh!) of course it is feasible; however, my concern was that the structure of this opaque value may change between different versions of Erlang run-time, and I was interested to see how these functions would behave when fake values for hash_state() are given. The results are interesting. A call to, say, erlang:md5_final( <<0:88/unsigned_integer-unit:8>> ) (*), or erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) will all produce: <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> Presumably this may be due to some default value that has been used for all invalid values for hash_sate(). However, a call using a fake (yet "non-zero") value in crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) results in run-time crashing and reporting segmentation fault (and this cannot be a good thing, right?). As it appears that some internal tests are performed in order to verify the hash_state() value, would it possible to extend these test to cover other values without imposing unnecessary performance penalty? Or, alternatively, is there any way that this test could be performed externally (e.g. when in doubt and before calling a function that may crash the run-time)? in other words, is it possible to publish descriptions (e.g. structure) of various hash_state() values? Kind regards V/ (*) 88 corresponds to a size (in octets) of the erlang:md5_xxx hash_state() value, and conversely, 92 is a number of octets in md5 hash_state() equivalent used by crypto library. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.james.morgan@REDACTED Wed Apr 10 14:41:06 2019 From: peter.james.morgan@REDACTED (Peter Morgan) Date: Wed, 10 Apr 2019 13:41:06 +0100 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} Message-ID: Hello - We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. The crash looks like: =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 ** State machine {kafire_fetcher,<>,<>,0} terminating ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: message_queue_len: 279 messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? Thanks Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Wed Apr 10 21:30:14 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 10 Apr 2019 22:30:14 +0300 Subject: [erlang-questions] WebRTC and DTLS and use_srtp In-Reply-To: References: Message-ID: ICE and the rest is inside our code that is not published. srtp implementation by Lemenkov is working without any issues -------------- next part -------------- An HTML attachment was scrubbed... URL: From albin.stigo@REDACTED Thu Apr 11 09:47:43 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Thu, 11 Apr 2019 09:47:43 +0200 Subject: [erlang-questions] WebRTC and DTLS and use_srtp In-Reply-To: References: Message-ID: Ok, thanks anyway! Trying to write an ICE implementation, it's a good exercise, quite complicated RFC. But Erlang is the perfect language for it... --Albin On Wed, Apr 10, 2019 at 9:30 PM Max Lapshin wrote: > > ICE and the rest is inside our code that is not published. > > srtp implementation by Lemenkov is working without any issues From kaiduanx@REDACTED Thu Apr 11 15:29:39 2019 From: kaiduanx@REDACTED (Kaiduan Xie) Date: Thu, 11 Apr 2019 09:29:39 -0400 Subject: [erlang-questions] WebRTC and DTLS and use_srtp In-Reply-To: References: Message-ID: Max, The dtls/srtp is a fantastic module, how about the SCTP for webrtc? Best regards, /Kaiduan On Thu, Apr 11, 2019 at 3:48 AM Albin Stig? wrote: > Ok, thanks anyway! Trying to write an ICE implementation, it's a good > exercise, quite complicated RFC. But Erlang is the perfect language > for it... > > --Albin > > On Wed, Apr 10, 2019 at 9:30 PM Max Lapshin wrote: > > > > ICE and the rest is inside our code that is not published. > > > > srtp implementation by Lemenkov is working without any issues > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Founder of Goodstartsoft https://www.goodstartsoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantinos.kallas@REDACTED Thu Apr 11 20:37:44 2019 From: konstantinos.kallas@REDACTED (Konstantinos Kallas) Date: Thu, 11 Apr 2019 18:37:44 +0000 Subject: [erlang-questions] High latency when exchanging small messages between different Erlang nodes Message-ID: Hello, I have an Erlang application where latency is crucial and a lot of small messages (tuples with an atom and integer) are exchanged between processes in different nodes. The main procedure is that a main process sends a small message to 4 worker processes in other Erlang nodes, the worker processes do some negligible processing, and then they reply back to the main node with a small message. Each separate Erlang node is on a different docker container (generated from the erlang:21 docker image), and all the containers are connected using a standard docker bridge network. I have noticed that latency (the time from when the first message is sent, and its replies arrive) linearly increases with time. It starts at 1 second and after 30 seconds of execution latency has become 10 seconds. I have tried running all processes on the same erlang node, and then latency is (as expected) a couple milliseconds, so my assumption is that the problem could be caused by one (or more) of the following: - Some misconfiguration of the Erlang nodes - Some misconfiguration of the docker network/containers - Some penalty imposed by the operating system/docker because a lot of small messages are exchanged Has anyone encountered this issue, or does anyone know how to configure Erlang nodes (and the operating system) to reduce message latency? Thanks in advance. Best, Konstantinos -------------- next part -------------- An HTML attachment was scrubbed... URL: From ledest@REDACTED Thu Apr 11 21:16:09 2019 From: ledest@REDACTED (Led) Date: Thu, 11 Apr 2019 22:16:09 +0300 Subject: [erlang-questions] High latency when exchanging small messages between different Erlang nodes In-Reply-To: References: Message-ID: In decent societies kicked for the expression "docker in production". ??, 11 ????. 2019 ? 22:07 Konstantinos Kallas < konstantinos.kallas@REDACTED> ????: > Hello, > > I have an Erlang application where latency is crucial and a lot of small > messages (tuples with an atom and integer) are exchanged between processes > in different nodes. > > The main procedure is that a main process sends a small message to 4 > worker processes in other Erlang nodes, the worker processes do some > negligible processing, and then they reply back to the main node with a > small message. > > Each separate Erlang node is on a different docker container (generated > from the erlang:21 docker image), and all the containers are connected > using a standard docker bridge network. > > I have noticed that latency (the time from when the first message is sent, > and its replies arrive) linearly increases with time. It starts at 1 second > and after 30 seconds of execution latency has become 10 seconds. > > I have tried running all processes on the same erlang node, and then > latency is (as expected) a couple milliseconds, so my assumption is that > the problem could be caused by one (or more) of the following: > > - Some misconfiguration of the Erlang nodes > > - Some misconfiguration of the docker network/containers > > - Some penalty imposed by the operating system/docker because a lot of > small messages are exchanged > > Has anyone encountered this issue, or does anyone know how to configure > Erlang nodes (and the operating system) to reduce message latency? > > Thanks in advance. > > Best, > > Konstantinos > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Led. -------------- next part -------------- An HTML attachment was scrubbed... URL: From soverdor@REDACTED Fri Apr 12 01:28:02 2019 From: soverdor@REDACTED (Sam Overdorf) Date: Thu, 11 Apr 2019 16:28:02 -0700 Subject: [erlang-questions] .erlangrc Message-ID: I'm back and still upset with the inconsistent use of the ".erlang" file. It sould be supported by the "erl" program and the "escript" program or not at all. being inconsistent is very bad. You guys need to make up your mind and on one way or the other and not half and half. From zxq9@REDACTED Fri Apr 12 01:48:12 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Fri, 12 Apr 2019 08:48:12 +0900 Subject: [erlang-questions] High latency when exchanging small messages between different Erlang nodes In-Reply-To: References: Message-ID: <6946294.CL1nSPn9rp@takoyaki> On 2019?4?11???? 22?16?09? JST Led wrote: > In decent societies kicked for the expression "docker in production". Process in a runtime in a docker in a VM in a host in a cloud platform in a... We need to go deeper. -- Leonardo DiCaprio: System Engineer -Craig From t@REDACTED Fri Apr 12 02:31:06 2019 From: t@REDACTED (Tristan Sloughter) Date: Thu, 11 Apr 2019 20:31:06 -0400 Subject: [erlang-questions] =?utf-8?q?High_latency_when_exchanging_small_m?= =?utf-8?q?essages_between_different_Erlang_nodes?= In-Reply-To: References: Message-ID: What is the frequency of initial messages sent? Are the worker processes mailboxes increasing over time as well? Tristan On Thu, Apr 11, 2019, at 13:07, Konstantinos Kallas wrote: > Hello, > I have an Erlang application where latency is crucial and a lot of small messages (tuples with an atom and integer) are exchanged between processes in different nodes. > The main procedure is that a main process sends a small message to 4 worker processes in other Erlang nodes, the worker processes do some negligible processing, and then they reply back to the main node with a small message. > Each separate Erlang node is on a different docker container (generated from the erlang:21 docker image), and all the containers are connected using a standard docker bridge network. > I have noticed that latency (the time from when the first message is sent, and its replies arrive) linearly increases with time. It starts at 1 second and after 30 seconds of execution latency has become 10 seconds. > I have tried running all processes on the same erlang node, and then latency is (as expected) a couple milliseconds, so my assumption is that the problem could be caused by one (or more) of the following: > - Some misconfiguration of the Erlang nodes > - Some misconfiguration of the docker network/containers > - Some penalty imposed by the operating system/docker because a lot of small messages are exchanged > Has anyone encountered this issue, or does anyone know how to configure Erlang nodes (and the operating system) to reduce message latency? > Thanks in advance. > Best, > Konstantinos > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Fri Apr 12 10:38:42 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Fri, 12 Apr 2019 10:38:42 +0200 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} In-Reply-To: References: Message-ID: <20190412083842.GA84954@erix.ericsson.se> On Wed, Apr 10, 2019 at 01:41:06PM +0100, Peter Morgan wrote: > Hello - > > We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. > > The crash looks like: > > =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 > ** State machine {kafire_fetcher,<>,<>,0} terminating > ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} > > We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: > > > message_queue_len: 279 > messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, Is that from a process_info() call? > > Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? It is not supposed to happen. This must be a bug. The gen_statem engine keeps track of the running state_timeout timer and should never present it as an info event. When a timer is stopped (or restarted) it is done with an asynchronous cancel (in OTP 21) so the cancel_timer messages comes from that. They should be matched against map entries in the internal gen_statem engine state when they arrive so them being in the inbox may be ok. However, how come you have so many? Are you restarting the state_timeout in a very tight loop of repeat_state:s? Can you show the essential parts of the code that causes state_timeout:s? Also - OTP-21.2; is that your exact OTP version? What is your stdlib version? I will look at the relevant parts of the code with the new knowledge that a state_timeout timer can be lost, probably in combination with repeat_state and state_timeout restart! On master since Jan 21 so in OTP-22.0-rc1 among other changes the timer handling has been rewritten to use a synchronous cancel, which simplified the code significantly. I do not know if that would be worth trying? / Raimo Niskanen > > Thanks > Peter. > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From jesper.louis.andersen@REDACTED Fri Apr 12 11:53:09 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 12 Apr 2019 11:53:09 +0200 Subject: [erlang-questions] High latency when exchanging small messages between different Erlang nodes In-Reply-To: References: Message-ID: My first recommendation is to add instrumentation to the system, so you can see what is going on: * Tristan already suggested looking at mailbox sizes * Network blocking is worth investigating as well. Many small messages can lead to network overload situations * Docker/Kubernetes environments tend to be noisy if a lot of work is running in them. In particular, if you have high-throughput systems banded with low latency systems, you are going to run into trouble. * Enable the Erlang system monitor. Get it to report on blocked ports and processes. * Add VM metrics: prometheus for instance. The problem can be everywhere: Inside your code, the VM, docker, kernel, hardware, ... Your first goal is to narrow down that. Verify things are looking correct in each layer before moving to the next. The fact latency starts out at 1 second where we are at millisecond level locally, would suggest something has to do with the distribution. Either in your own code, or in the underlying setup. On Thu, Apr 11, 2019 at 9:07 PM Konstantinos Kallas < konstantinos.kallas@REDACTED> wrote: > Hello, > > I have an Erlang application where latency is crucial and a lot of small > messages (tuples with an atom and integer) are exchanged between processes > in different nodes. > > The main procedure is that a main process sends a small message to 4 > worker processes in other Erlang nodes, the worker processes do some > negligible processing, and then they reply back to the main node with a > small message. > > Each separate Erlang node is on a different docker container (generated > from the erlang:21 docker image), and all the containers are connected > using a standard docker bridge network. > > I have noticed that latency (the time from when the first message is sent, > and its replies arrive) linearly increases with time. It starts at 1 second > and after 30 seconds of execution latency has become 10 seconds. > > I have tried running all processes on the same erlang node, and then > latency is (as expected) a couple milliseconds, so my assumption is that > the problem could be caused by one (or more) of the following: > > - Some misconfiguration of the Erlang nodes > > - Some misconfiguration of the docker network/containers > > - Some penalty imposed by the operating system/docker because a lot of > small messages are exchanged > > Has anyone encountered this issue, or does anyone know how to configure > Erlang nodes (and the operating system) to reduce message latency? > > Thanks in advance. > > Best, > > Konstantinos > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Fri Apr 12 14:38:35 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Fri, 12 Apr 2019 14:38:35 +0200 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} In-Reply-To: <20190412083842.GA84954@erix.ericsson.se> References: <20190412083842.GA84954@erix.ericsson.se> Message-ID: <20190412123835.GA486@erix.ericsson.se> On Fri, Apr 12, 2019 at 10:38:42AM +0200, Raimo Niskanen wrote: > On Wed, Apr 10, 2019 at 01:41:06PM +0100, Peter Morgan wrote: > > Hello - > > > > We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. > > > > The crash looks like: > > > > =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 > > ** State machine {kafire_fetcher,<>,<>,0} terminating > > ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} > > > > We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: > > > > > > message_queue_len: 279 > > messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > > {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > > {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, > > Is that from a process_info() call? > > > > > Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? > > It is not supposed to happen. This must be a bug. > > The gen_statem engine keeps track of the running state_timeout timer > and should never present it as an info event. > > When a timer is stopped (or restarted) it is done with an asynchronous > cancel (in OTP 21) so the cancel_timer messages comes from that. > They should be matched against map entries in the internal gen_statem > engine state when they arrive so them being in the inbox may be ok. > > However, how come you have so many? Are you restarting the state_timeout > in a very tight loop of repeat_state:s? Can you show the essential parts > of the code that causes state_timeout:s? > > Also - OTP-21.2; is that your exact OTP version? What is your stdlib version? > > I will look at the relevant parts of the code with the new knowledge that > a state_timeout timer can be lost, probably in combination with > repeat_state and state_timeout restart! Sorry, the knowledge did not help; I did not find anything suspicous. More information will be needed... > > On master since Jan 21 so in OTP-22.0-rc1 among other changes the timer handling > has been rewritten to use a synchronous cancel, which simplified the code > significantly. I do not know if that would be worth trying? > > / Raimo Niskanen > > > > > > Thanks > > Peter. > > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From otp@REDACTED Fri Apr 12 15:09:36 2019 From: otp@REDACTED (Erlang/OTP) Date: Fri, 12 Apr 2019 15:09:36 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.4 Released Message-ID: <20190412130936.GA42001@erix.ericsson.se> Patch Package: OTP 21.3.4 Git Tag: OTP-21.3.4 Date: 2019-04-12 Trouble Report Id: OTP-15716, OTP-15750, OTP-15753, OTP-15757, OTP-15762, OTP-15763 Seq num: ERL-900, ERL-905 System: OTP Release: 21 Application: common_test-1.17.1, crypto-4.4.2, erl_interface-3.11.2, erts-10.3.3, ssh-4.7.5 Predecessor: OTP 21.3.3 Check out the git tag OTP-21.3.4, 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. --------------------------------------------------------------------- --- common_test-1.17.1 ---------------------------------------------- --------------------------------------------------------------------- The common_test-1.17.1 application can be applied independently of other applications on a full OTP 21 installation. --- Improvements and New Features --- OTP-15716 Application(s): common_test OTP internal test improvements. Full runtime dependencies of common_test-1.17.1: compiler-6.0, crypto-3.6, debugger-4.1, erts-7.0, ftp-1.0.0, inets-6.0, kernel-4.0, observer-2.1, runtime_tools-1.8.16, sasl-2.4.2, snmp-5.1.2, ssh-4.0, stdlib-3.5, syntax_tools-1.7, tools-2.8, xmerl-1.3.8 --------------------------------------------------------------------- --- crypto-4.4.2 ---------------------------------------------------- --------------------------------------------------------------------- The crypto-4.4.2 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15750 Application(s): crypto Related Id(s): ERL-905 Fixed build link error on Windows. Unresolved symbol 'bcmp'. Full runtime dependencies of crypto-4.4.2: erts-9.0, kernel-5.3, stdlib-3.4 --------------------------------------------------------------------- --- erl_interface-3.11.2 -------------------------------------------- --------------------------------------------------------------------- The erl_interface-3.11.2 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15757 Application(s): erl_interface Fix handling of Makefile dependencies so that parallel make works properly. --------------------------------------------------------------------- --- erts-10.3.3 ----------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.3.3 application *cannot* 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-15753 Application(s): erts Related Id(s): ERL-900 Fix erlang:open_port/2 with the fd option to correctly cleanup the pollset when the port is closed. Before this fix there would be error printouts sent to logger when the same fd was reused in a new port. Full runtime dependencies of erts-10.3.3: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- ssh-4.7.5 ------------------------------------------------------- --------------------------------------------------------------------- The ssh-4.7.5 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15762 Application(s): ssh The callback ssh_channel:init/1 was missing in OTP-21 OTP-15763 Application(s): ssh If a client was connected to an server on an already open socket, the callback fun(PeerName,FingerPrint) in the accept_callback option passed the local name in the argument PeerName instead of the remote name. Full runtime dependencies of ssh-4.7.5: crypto-4.2, erts-6.0, kernel-3.0, public_key-1.5.2, stdlib-3.3 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From t@REDACTED Fri Apr 12 15:34:28 2019 From: t@REDACTED (Tristan Sloughter) Date: Fri, 12 Apr 2019 09:34:28 -0400 Subject: [erlang-questions] =?utf-8?q?High_latency_when_exchanging_small_m?= =?utf-8?q?essages_between_different_Erlang_nodes?= In-Reply-To: References: Message-ID: Yea, instrumentation from the beginning is a good bet. Shameless plug https://opencensus.io/quickstart/erlang/ :) -- and prometheus.erl for vm metrics like Jesper suggests. Tristan On Fri, Apr 12, 2019, at 03:53, Jesper Louis Andersen wrote: > My first recommendation is to add instrumentation to the system, so you can see what is going on: > > * Tristan already suggested looking at mailbox sizes > * Network blocking is worth investigating as well. Many small messages can lead to network overload situations > * Docker/Kubernetes environments tend to be noisy if a lot of work is running in them. In particular, if you have high-throughput systems banded with low latency systems, you are going to run into trouble. > * Enable the Erlang system monitor. Get it to report on blocked ports and processes. > * Add VM metrics: prometheus for instance. > > The problem can be everywhere: Inside your code, the VM, docker, kernel, hardware, ... Your first goal is to narrow down that. Verify things are looking correct in each layer before moving to the next. > > The fact latency starts out at 1 second where we are at millisecond level locally, would suggest something has to do with the distribution. Either in your own code, or in the underlying setup. > > On Thu, Apr 11, 2019 at 9:07 PM Konstantinos Kallas wrote: >> Hello, >> I have an Erlang application where latency is crucial and a lot of small messages (tuples with an atom and integer) are exchanged between processes in different nodes. >> The main procedure is that a main process sends a small message to 4 worker processes in other Erlang nodes, the worker processes do some negligible processing, and then they reply back to the main node with a small message. >> Each separate Erlang node is on a different docker container (generated from the erlang:21 docker image), and all the containers are connected using a standard docker bridge network. >> I have noticed that latency (the time from when the first message is sent, and its replies arrive) linearly increases with time. It starts at 1 second and after 30 seconds of execution latency has become 10 seconds. >> I have tried running all processes on the same erlang node, and then latency is (as expected) a couple milliseconds, so my assumption is that the problem could be caused by one (or more) of the following: >> - Some misconfiguration of the Erlang nodes >> - Some misconfiguration of the docker network/containers >> - Some penalty imposed by the operating system/docker because a lot of small messages are exchanged >> Has anyone encountered this issue, or does anyone know how to configure Erlang nodes (and the operating system) to reduce message latency? >> Thanks in advance. >> Best, >> Konstantinos >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > J. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.james.morgan@REDACTED Fri Apr 12 17:13:27 2019 From: peter.james.morgan@REDACTED (Peter Morgan) Date: Fri, 12 Apr 2019 16:13:27 +0100 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} In-Reply-To: <20190412123835.GA486@erix.ericsson.se> References: <20190412083842.GA84954@erix.ericsson.se> <20190412123835.GA486@erix.ericsson.se> Message-ID: <119A945C-06F6-4E64-893E-9E6108D655F7@gmail.com> Hi Raimo, Thanks for looking at this, and the background on the implementation which is very useful. I am in the process of putting together a simple test case, but having trouble reproducing it. It appears to happen very infrequently - possibly something that is load related? The original output was from the Crash Report which I?ve attached - where you can see the info timeout was received by our gen_statem behaviour callback. Our OTP is 21.2 (without any 21.2.X patches): {stdlib,"ERTS CXC 138 10","3.7?} {kernel,"ERTS CXC 138 10","6.2?} Your question - ?why so many?? - it could be a failure of a downstream service that is ultimately causing this, and we?re not backing off in this case - something that I?m checking too. However, I still thought it was interesting that the info timeout reaches the behaviour module. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: info.timeout.txt URL: -------------- next part -------------- I?ll try and get a simple test case for you. Regards, Peter. > On 12 Apr 2019, at 13:38, Raimo Niskanen wrote: > > On Fri, Apr 12, 2019 at 10:38:42AM +0200, Raimo Niskanen wrote: >> On Wed, Apr 10, 2019 at 01:41:06PM +0100, Peter Morgan wrote: >>> Hello - >>> >>> We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. >>> >>> The crash looks like: >>> >>> =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 >>> ** State machine {kafire_fetcher,<>,<>,0} terminating >>> ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} >>> >>> We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: >>> >>> >>> message_queue_len: 279 >>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, >>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, >>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, >>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, >> >> Is that from a process_info() call? >> >>> >>> Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? >> >> It is not supposed to happen. This must be a bug. >> >> The gen_statem engine keeps track of the running state_timeout timer >> and should never present it as an info event. >> >> When a timer is stopped (or restarted) it is done with an asynchronous >> cancel (in OTP 21) so the cancel_timer messages comes from that. >> They should be matched against map entries in the internal gen_statem >> engine state when they arrive so them being in the inbox may be ok. >> >> However, how come you have so many? Are you restarting the state_timeout >> in a very tight loop of repeat_state:s? Can you show the essential parts >> of the code that causes state_timeout:s? >> >> Also - OTP-21.2; is that your exact OTP version? What is your stdlib version? >> >> I will look at the relevant parts of the code with the new knowledge that >> a state_timeout timer can be lost, probably in combination with >> repeat_state and state_timeout restart! > > > Sorry, the knowledge did not help; I did not find anything suspicous. > > More information will be needed... > >> >> On master since Jan 21 so in OTP-22.0-rc1 among other changes the timer handling >> has been rewritten to use a synchronous cancel, which simplified the code >> significantly. I do not know if that would be worth trying? >> >> / Raimo Niskanen >> >> >>> >>> Thanks >>> Peter. >>> > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mark.geib.44@REDACTED Fri Apr 12 17:30:10 2019 From: mark.geib.44@REDACTED (Mark Geib) Date: Fri, 12 Apr 2019 09:30:10 -0600 Subject: [erlang-questions] new logger advice requested Message-ID: Sorry for the long email, but I am looking for suggestions related to dynamically adding handlers, and/or filters, to the new erlang logger. Some background may help. I am writing an erlang application to mirror log files from production applications to a central location. These log files are produced by C#, Java, python, etc. Currently I am using td-agent on each host to tail the log files and write a message to a rabbitmq broker where the message includes the log file line, and the full path of the tailed log file. My erlang application receives all these amqp messages and writes the log lines to a location derived from the full path of the original file. I simply keep track of the file paths, and when I see a new one create a new gen_server to handle the lines for that file. Thereby I need no configuration, except the broker connection info of course. Currently I am simply appending to the file as each line is forwarded to the gen_server. Works great, but not file rotation, etc. I need advice as to how I may dynamically add, and configure, a new handler as each gen_server is created and configure it to write to the correct derived file path, and only write log messages from the gen_server adding the handler. So in each worker gen_server handling a log file I want to be able to simple call logger:info() and have the log messages from that one gen_server written to the configured file, same for all the other gen_servers of course. This allows me to use the built-in file rotation, etc. all for free.. Thanks for any suggestions, Mark. From bchesneau@REDACTED Fri Apr 12 17:49:01 2019 From: bchesneau@REDACTED (Benoit Chesneau) Date: Fri, 12 Apr 2019 17:49:01 +0200 Subject: [erlang-questions] rust c-node ? In-Reply-To: References: Message-ID: thanks! i will look at it. beno?t On Tue 9 Apr 2019 at 13:03, ?????? ???????? wrote: > You might be interested in my implementation of external term format in > Rust > > https://github.com/seriyps/rust-erl-ext > > But it was my first Rust project and was never used in production as far > as I know. > -- Sent from my Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantinos.kallas@REDACTED Fri Apr 12 15:42:36 2019 From: konstantinos.kallas@REDACTED (Konstantinos Kallas) Date: Fri, 12 Apr 2019 13:42:36 +0000 Subject: [erlang-questions] High latency when exchanging small messages between different Erlang nodes In-Reply-To: References: Message-ID: Thanks for the constructive feedback :) On 12/4/19 9:34 ?.?., Tristan Sloughter wrote: Yea, instrumentation from the beginning is a good bet. Shameless plug https://opencensus.io/quickstart/erlang/ :) -- and prometheus.erl for vm metrics like Jesper suggests. Tristan On Fri, Apr 12, 2019, at 03:53, Jesper Louis Andersen wrote: My first recommendation is to add instrumentation to the system, so you can see what is going on: * Tristan already suggested looking at mailbox sizes * Network blocking is worth investigating as well. Many small messages can lead to network overload situations * Docker/Kubernetes environments tend to be noisy if a lot of work is running in them. In particular, if you have high-throughput systems banded with low latency systems, you are going to run into trouble. * Enable the Erlang system monitor. Get it to report on blocked ports and processes. * Add VM metrics: prometheus for instance. The problem can be everywhere: Inside your code, the VM, docker, kernel, hardware, ... Your first goal is to narrow down that. Verify things are looking correct in each layer before moving to the next. The fact latency starts out at 1 second where we are at millisecond level locally, would suggest something has to do with the distribution. Either in your own code, or in the underlying setup. On Thu, Apr 11, 2019 at 9:07 PM Konstantinos Kallas > wrote: Hello, I have an Erlang application where latency is crucial and a lot of small messages (tuples with an atom and integer) are exchanged between processes in different nodes. The main procedure is that a main process sends a small message to 4 worker processes in other Erlang nodes, the worker processes do some negligible processing, and then they reply back to the main node with a small message. Each separate Erlang node is on a different docker container (generated from the erlang:21 docker image), and all the containers are connected using a standard docker bridge network. I have noticed that latency (the time from when the first message is sent, and its replies arrive) linearly increases with time. It starts at 1 second and after 30 seconds of execution latency has become 10 seconds. I have tried running all processes on the same erlang node, and then latency is (as expected) a couple milliseconds, so my assumption is that the problem could be caused by one (or more) of the following: - Some misconfiguration of the Erlang nodes - Some misconfiguration of the docker network/containers - Some penalty imposed by the operating system/docker because a lot of small messages are exchanged Has anyone encountered this issue, or does anyone know how to configure Erlang nodes (and the operating system) to reduce message latency? Thanks in advance. Best, Konstantinos _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- J. _______________________________________________ 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 Apr 13 08:41:13 2019 From: cean.ebengt@REDACTED (bengt) Date: Sat, 13 Apr 2019 08:41:13 +0200 Subject: [erlang-questions] .erlangrc In-Reply-To: References: Message-ID: <9CF2CF83-433D-474A-8D09-E895F40C0E01@gmail.com> Greetings, If there is no .erlang file it will not be used. That way it is possible to enforce consistency. Best Wishes, bengt > On 12 Apr 2019, at 01:28, Sam Overdorf wrote: > > I'm back and still upset with the inconsistent use of the ".erlang" file. > > It sould be supported by the "erl" program and the "escript" program > or not at all. being inconsistent is very bad. > > You guys need to make up your mind and on one way or the other and not > half and half. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From albin.stigo@REDACTED Sat Apr 13 12:59:23 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Sat, 13 Apr 2019 12:59:23 +0200 Subject: [erlang-questions] Release c_src dependencies Message-ID: Hi, I have an application with a bundled fairly complex cnode linked against GNURadio (that in itself has a lot of dependencies libboost among others). I'm now in the process of creating a release and thinking about ways to satisfy dependencies with minimal fuss. I can think about a few ways but am unsure about the best option. 1. Is there some kind of tool to also bundle c libraries into a release? 2. Should I statically link the c node? 3. Should I use something like docker..? Any suggestions? --Albin From roger@REDACTED Sat Apr 13 13:08:08 2019 From: roger@REDACTED (Roger Lipscombe) Date: Sat, 13 Apr 2019 12:08:08 +0100 Subject: [erlang-questions] Release c_src dependencies In-Reply-To: References: Message-ID: On Sat, 13 Apr 2019 at 11:59, Albin Stig? wrote: > I have an application with a bundled fairly complex cnode linked > against GNURadio (that in itself has a lot of dependencies libboost > among others). I'm now in the process of creating a release and > thinking about ways to satisfy dependencies with minimal fuss. I can > think about a few ways but am unsure about the best option. What's your target OS (and distribution)? Since we target Ubuntu, we just package our Erlang releases as deb files and make sure the deb's dependencies are set correctly. This includes packaging various other components (the cnode in your example, I guess) as separate debs. For packaging the deb, you could use the Debian packaging scripts, which are kinda awkward to use, or you could just use the fpm gem. From albin.stigo@REDACTED Sat Apr 13 13:19:30 2019 From: albin.stigo@REDACTED (=?UTF-8?B?QWxiaW4gU3RpZ8O2?=) Date: Sat, 13 Apr 2019 13:19:30 +0200 Subject: [erlang-questions] Release c_src dependencies In-Reply-To: References: Message-ID: We are targeting the Raspberry Pi (raspbian), if you are curious you can check out the project here, http://tujasdr.com. I was thinking about creating deb(s) but then I would have to also create a custom GNURadio deb as well (and probably others) because raspbian is behind and you never know when it will get updated. It's quite a large undertaking. I'm currently thinking it would be easier to distribute everything as a big blob. Actually when I think about it maybe I could put everything in one deb... --Albin On Sat, Apr 13, 2019 at 1:08 PM Roger Lipscombe wrote: > > On Sat, 13 Apr 2019 at 11:59, Albin Stig? wrote: > > I have an application with a bundled fairly complex cnode linked > > against GNURadio (that in itself has a lot of dependencies libboost > > among others). I'm now in the process of creating a release and > > thinking about ways to satisfy dependencies with minimal fuss. I can > > think about a few ways but am unsure about the best option. > > What's your target OS (and distribution)? Since we target Ubuntu, we > just package our Erlang releases as deb files and make sure the deb's > dependencies are set correctly. This includes packaging various other > components (the cnode in your example, I guess) as separate debs. > > For packaging the deb, you could use the Debian packaging scripts, > which are kinda awkward to use, or you could just use the fpm gem. From vances@REDACTED Sat Apr 13 16:52:23 2019 From: vances@REDACTED (Vance Shipley) Date: Sat, 13 Apr 2019 20:22:23 +0530 Subject: [erlang-questions] Release c_src dependencies In-Reply-To: References: Message-ID: We use GNU autotools to create and package portable code. We use libtool for our linked in drivers and NIFs. In the past I've used this approach to build drivers for 32 & 64 bit, little and big endian platforms. We currently build Debian packages. Check out GitHub.com:sigscale/ocs for an example. On Sat, Apr 13, 2019, 4:29 PM Albin Stig? wrote: > Hi, > > I have an application with a bundled fairly complex cnode linked > against GNURadio (that in itself has a lot of dependencies libboost > among others). I'm now in the process of creating a release and > thinking about ways to satisfy dependencies with minimal fuss. I can > think about a few ways but am unsure about the best option. > > 1. Is there some kind of tool to also bundle c libraries into a release? > 2. Should I statically link the c node? > 3. Should I use something like docker..? > > Any suggestions? > > > --Albin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From soverdor@REDACTED Sun Apr 14 02:16:48 2019 From: soverdor@REDACTED (Sam Overdorf) Date: Sat, 13 Apr 2019 17:16:48 -0700 Subject: [erlang-questions] .erlangrc In-Reply-To: <9CF2CF83-433D-474A-8D09-E895F40C0E01@gmail.com> References: <9CF2CF83-433D-474A-8D09-E895F40C0E01@gmail.com> Message-ID: That's just the point. I want to use it for specific configuration for individual nodes and not have to include the code "c:erlangrc" in each of my programs (set it and forget it configurations stuff). Having different behavior for "erl" and "escript" is just a stupid idea. Sam On Fri, Apr 12, 2019 at 11:41 PM bengt wrote: > > Greetings, > > If there is no .erlang file it will not be used. That way it is possible to enforce consistency. > > Best Wishes, > bengt > > > On 12 Apr 2019, at 01:28, Sam Overdorf wrote: > > > > I'm back and still upset with the inconsistent use of the ".erlang" file. > > > > It sould be supported by the "erl" program and the "escript" program > > or not at all. being inconsistent is very bad. > > > > You guys need to make up your mind and on one way or the other and not > > half and half. > > _______________________________________________ > > 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 max.lapshin@REDACTED Sun Apr 14 03:15:26 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 14 Apr 2019 04:15:26 +0300 Subject: [erlang-questions] Release c_src dependencies In-Reply-To: References: Message-ID: Or https://gist.github.com/maxlapshin/6251523 On Sat, Apr 13, 2019 at 2:08 PM Roger Lipscombe wrote: > On Sat, 13 Apr 2019 at 11:59, Albin Stig? wrote: > > I have an application with a bundled fairly complex cnode linked > > against GNURadio (that in itself has a lot of dependencies libboost > > among others). I'm now in the process of creating a release and > > thinking about ways to satisfy dependencies with minimal fuss. I can > > think about a few ways but am unsure about the best option. > > What's your target OS (and distribution)? Since we target Ubuntu, we > just package our Erlang releases as deb files and make sure the deb's > dependencies are set correctly. This includes packaging various other > components (the cnode in your example, I guess) as separate debs. > > For packaging the deb, you could use the Debian packaging scripts, > which are kinda awkward to use, or you could just use the fpm gem. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthonym@REDACTED Sun Apr 14 03:19:43 2019 From: anthonym@REDACTED (Molinaro, Anthony) Date: Sun, 14 Apr 2019 01:19:43 +0000 Subject: [erlang-questions] Release c_src dependencies In-Reply-To: References: Message-ID: <8C729D71-D2B9-4086-9534-89A2D04E8853@alumni.caltech.edu> Also I embed that (with many rpm packaging fixes) in https://github.com/openx/rebar3_build_rpm And gave a talk about packaging erlang projects at Beam.SF in 2018 https://youtu.be/AXY0d0YXQSU Even though it says rpm it should be able to build a deb as well. HTH, -Anthony On Apr 13, 2019, at 6:15 PM, Max Lapshin > wrote: Or https://gist.github.com/maxlapshin/6251523 On Sat, Apr 13, 2019 at 2:08 PM Roger Lipscombe > wrote: On Sat, 13 Apr 2019 at 11:59, Albin Stig? > wrote: > I have an application with a bundled fairly complex cnode linked > against GNURadio (that in itself has a lot of dependencies libboost > among others). I'm now in the process of creating a release and > thinking about ways to satisfy dependencies with minimal fuss. I can > think about a few ways but am unsure about the best option. What's your target OS (and distribution)? Since we target Ubuntu, we just package our Erlang releases as deb files and make sure the deb's dependencies are set correctly. This includes packaging various other components (the cnode in your example, I guess) as separate debs. For packaging the deb, you could use the Debian packaging scripts, which are kinda awkward to use, or you could just use the fpm gem. _______________________________________________ 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 roger@REDACTED Sun Apr 14 09:45:35 2019 From: roger@REDACTED (Roger Lipscombe) Date: Sun, 14 Apr 2019 08:45:35 +0100 Subject: [erlang-questions] .erlangrc In-Reply-To: References: <9CF2CF83-433D-474A-8D09-E895F40C0E01@gmail.com> Message-ID: escript scripts are meant to be standalone. If they have a dependency on the user's ambient .erlangrc, you're doing it wrong. If you want node-specific configuration, use file:consult to load it from a better-named configuration file. erl, on the other hand, is meant to be an interactive REPL (when run in that mode), so it's fine for it to vary between users. On Sun, 14 Apr 2019 at 01:07, Sam Overdorf wrote: > > That's just the point. I want to use it for specific configuration for > individual nodes and not have to include the code "c:erlangrc" in each > of my programs (set it and forget it configurations stuff). > > Having different behavior for "erl" and "escript" is just a stupid idea. > > Sam > > > > > > On Fri, Apr 12, 2019 at 11:41 PM bengt wrote: > > > > Greetings, > > > > If there is no .erlang file it will not be used. That way it is possible to enforce consistency. > > > > Best Wishes, > > bengt > > > > > On 12 Apr 2019, at 01:28, Sam Overdorf wrote: > > > > > > I'm back and still upset with the inconsistent use of the ".erlang" file. > > > > > > It sould be supported by the "erl" program and the "escript" program > > > or not at all. being inconsistent is very bad. > > > > > > You guys need to make up your mind and on one way or the other and not > > > half and half. > > > _______________________________________________ > > > 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 max.lapshin@REDACTED Sun Apr 14 11:19:46 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 14 Apr 2019 12:19:46 +0300 Subject: [erlang-questions] How do you go to production? Message-ID: Hi. I'm developing Flussonic for almost 10 years and we have some practices for packaging, deploying, running, maintainig that are not well known, however they are rather good for us. It is interesting how do other people solve this. At first, we do not use releases. It is because when we have started our long path, using of releases was not very easy. Couple of days ago I've tested it with rebar3 and it is really easier to use. Perhaps we would use releases today. Next: we use our own fpm script replacement for packaging. I can boast that it seems to be the only existing implementation of rpm outside of original library, however I'd better never pass this path again. I've written it in pre-docker era and frankly speaking it is a traumatic experience. However, we are using it for debian and it is really convenient: https://github.com/flussonic/epm Some time ago we have switched to systemd. I personally consider systemd a very badly designed thing that was created without any discussions with existing system adminstrators. For example, systemd doesn't offer config validation before launch. Another brilliant idea is to offer libsystemd for linking into application. Unknown library with unknown quality. What can go wrong if you link it into your erlang or java application? Sorry, but no. We have systemd.erl: https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb Use Type=notify in youdaemon.service After you manage to launch your erlang daemon, you need to collect statistics. We had to add some more linux-related tools to fetch: cpu usage, disk I/O usage, system ram usage (swap, etc), per-interface network statistics, udp errors count, nvidia card usage, etc. If this is worthy outsource, I think we can extract it. Our os_stat library is linked with our in-erlang pulsedb library. We try to maintain as less dependencies as possible, so we collect all ticks from monitoring tools inside erlang library pulsedb: https://github.com/pulsedb/pulsedb (maybe should update public branch) It can save several thousands metrics with one tick per 1-3 seconds. Support is an important part of our business, because customers cannot just launch software, they often need help. We have many people in support staff and I do not want to manage their own public ssh keys on customer's servers. So we have written an ssh proxy: system that login to customer server with one private key and allow support guy to use his own key: https://github.com/flussonic/ssh-proxy All these things are rather useless for development and many of them are not required for in-house development, however it is hard to live without them when you sell software. What is your experience with such things that standard erlang lacks? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Sun Apr 14 12:20:16 2019 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 14 Apr 2019 12:20:16 +0200 Subject: [erlang-questions] Release c_src dependencies In-Reply-To: References: Message-ID: Hi, You may create source debian package for c_src dependencies depending another debian package for your release. You can use my project which is full Erlang and no need of tar, ar and even fakeroot. Your can set root or another UID in tar with non root rights while using debbie. https://github.com/crownedgrouse/debbie Regards Le 13/04/2019 ? 12:59, Albin Stig? a ?crit?: > Hi, > > I have an application with a bundled fairly complex cnode linked > against GNURadio (that in itself has a lot of dependencies libboost > among others). I'm now in the process of creating a release and > thinking about ways to satisfy dependencies with minimal fuss. I can > think about a few ways but am unsure about the best option. > > 1. Is there some kind of tool to also bundle c libraries into a release? > 2. Should I statically link the c node? > 3. Should I use something like docker..? > > Any suggestions? > > > --Albin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From lloyd@REDACTED Sun Apr 14 19:58:36 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 14 Apr 2019 13:58:36 -0400 Subject: [erlang-questions] How do you go to production? In-Reply-To: References: Message-ID: Thanks, Max, for sharing your experience. Looking forward to the day, would love to see a series of Erlang deployment/support case studies/tutorials ranging from simple release through distributed clusters. All the best, LRP Sent from my iPad > On Apr 14, 2019, at 5:19 AM, Max Lapshin wrote: > > Hi. > > I'm developing Flussonic for almost 10 years and we have some practices for packaging, deploying, running, maintainig that are not well known, however they are rather good for us. > > It is interesting how do other people solve this. > > At first, we do not use releases. It is because when we have started our long path, using of releases was not very easy. Couple of days ago I've tested it with rebar3 and it is really easier to use. Perhaps we would use releases today. > > > > > Next: we use our own fpm script replacement for packaging. I can boast that it seems to be the only existing implementation of rpm outside of original library, however I'd better never pass this path again. I've written it in pre-docker era and frankly speaking it is a traumatic experience. However, we are using it for debian and it is really convenient: > https://github.com/flussonic/epm > > > Some time ago we have switched to systemd. I personally consider systemd a very badly designed thing that was created without any discussions with existing system adminstrators. For example, systemd doesn't offer config validation before launch. Another brilliant idea is to offer libsystemd for linking into application. Unknown library with unknown quality. What can go wrong if you link it into your erlang or java application? > > Sorry, but no. We have systemd.erl: https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb > > Use Type=notify in youdaemon.service > > > > > After you manage to launch your erlang daemon, you need to collect statistics. We had to add some more linux-related tools to fetch: cpu usage, disk I/O usage, system ram usage (swap, etc), per-interface network statistics, udp errors count, nvidia card usage, etc. > If this is worthy outsource, I think we can extract it. > > > > > > Our os_stat library is linked with our in-erlang pulsedb library. We try to maintain as less dependencies as possible, so we collect all ticks from monitoring tools inside erlang library pulsedb: https://github.com/pulsedb/pulsedb (maybe should update public branch) > > It can save several thousands metrics with one tick per 1-3 seconds. > > > > > > Support is an important part of our business, because customers cannot just launch software, they often need help. We have many people in support staff and I do not want to manage their own public ssh keys on customer's servers. So we have written an ssh proxy: system that login to customer server with one private key and allow support guy to use his own key: https://github.com/flussonic/ssh-proxy > > > > All these things are rather useless for development and many of them are not required for in-house development, however it is hard to live without them when you sell software. > What is your experience with such things that standard erlang lacks? > _______________________________________________ > 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 Mon Apr 15 11:41:16 2019 From: otp@REDACTED (Erlang/OTP) Date: Mon, 15 Apr 2019 11:41:16 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.5 Released Message-ID: <20190415094116.GA3894@erix.ericsson.se> Patch Package: OTP 21.3.5 Git Tag: OTP-21.3.5 Date: 2019-04-15 Trouble Report Id: OTP-15766, OTP-15768, OTP-15769 Seq num: ERIERL-345 System: OTP Release: 21 Application: diameter-2.2.1, erts-10.3.4, inets-7.0.7 Predecessor: OTP 21.3.4 Check out the git tag OTP-21.3.5, 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. --------------------------------------------------------------------- --- diameter-2.2.1 -------------------------------------------------- --------------------------------------------------------------------- The diameter-2.2.1 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15768 Application(s): diameter Fix inadvertently broad monitor that resulted in gen_server cast messages to hidden nodes from module diameter_dist. Full runtime dependencies of diameter-2.2.1: erts-10.0, kernel-3.2, ssl-9.0, stdlib-2.4 --------------------------------------------------------------------- --- erts-10.3.4 ----------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.3.4 application *cannot* 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-15766 Application(s): erts Add missing documentation of new external tags NEW_PID, NEW_PORT and NEWER_REFERENCE introduced in OTP 19. These new tags are planned to be "activated" in OTP 23 when distribution capability flag DFLAG_BIG_CREATION becomes mandatory. Older nodes (>= 19) are able to decode these new tags and send them back to the new node. Nodes older than OTP 23 will however never encode their own local pids, ports and references using the new tags. Full runtime dependencies of erts-10.3.4: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- inets-7.0.7 ----------------------------------------------------- --------------------------------------------------------------------- The inets-7.0.7 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15769 Application(s): inets Related Id(s): ERIERL-345 Fix the internal handling of the option erl_script_timeout in httpd. If explicit erl_script_timeout value was supplied in seconds it was not correctly converted to millisecond units for internal usage. This change fixes the handling of erl_script_timeout in all possible configuration scenarios. Full runtime dependencies of inets-7.0.7: erts-6.0, kernel-3.0, mnesia-4.12, runtime_tools-1.8.14, ssl-5.3.4, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From v@REDACTED Mon Apr 15 12:03:38 2019 From: v@REDACTED (Valentin Micic) Date: Mon, 15 Apr 2019 12:03:38 +0200 Subject: [erlang-questions] hash_state() and Segmentation Fault In-Reply-To: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> References: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> Message-ID: Hmmm? I may need to restate the question: Does anyone know where can one find a description of the hash_state() structure, as used by crypto:hash_xxx functions? Thanks in advance. V/ On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote: > Hi, > > I've been investigating a feasibility of saving of hash_state() -- used as a part of erlang:md5_init/md5_update/md5_final and/or their functional equivalents in crypto library; so it could be used later to implicitly reinitialize hash calculations. > Well, (duh!) of course it is feasible; however, my concern was that the structure of this opaque value may change between different versions of Erlang run-time, and I was interested to see how these functions would behave when fake values for hash_state() are given. > > The results are interesting. > > A call to, say, erlang:md5_final( <<0:88/unsigned_integer-unit:8>> ) (*), or > erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed > crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) > > will all produce: > > <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> > > Presumably this may be due to some default value that has been used for all invalid values for hash_sate(). > > However, a call using a fake (yet "non-zero") value in crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) results in run-time crashing and reporting segmentation fault (and this cannot be a good thing, right?). > > As it appears that some internal tests are performed in order to verify the hash_state() value, would it possible to extend these test to cover other values without imposing unnecessary performance penalty? > > Or, alternatively, is there any way that this test could be performed externally (e.g. when in doubt and before calling a function that may crash the run-time)? in other words, is it possible to publish descriptions (e.g. structure) of various hash_state() values? > > Kind regards > > V/ > > (*) 88 corresponds to a size (in octets) of the erlang:md5_xxx hash_state() value, and conversely, 92 is a number of octets in md5 hash_state() equivalent used by crypto library. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.r.nilsson@REDACTED Mon Apr 15 14:54:44 2019 From: hans.r.nilsson@REDACTED (Hans Nilsson R) Date: Mon, 15 Apr 2019 12:54:44 +0000 Subject: [erlang-questions] hash_state() and Segmentation Fault In-Reply-To: References: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> Message-ID: <4a1c6667-7c5e-2d26-534f-e8415de029cd@ericsson.com> The hash_state() is just an Erlang reference. It is created in the C-function hash_init_nif. It references an area with a C-struct evp_md_ctx containing the EVP_MD_CTX* returned from OpenSSL cryptolib. The area is allocated by enif_alloc_resource (see http://erlang.org/doc/man/erl_nif.html#enif_alloc_resource ) and the Erlang reference is created by enif_make_resource (same refman page) Read about the nif resource mechanism in http://erlang.org/doc/man/erl_nif.html section "Resource objects". /Hans On 4/15/19 12:03 PM, Valentin Micic wrote: > Hmmm? I may need to restate the question: > > Does anyone know where can one find a description of the hash_state() structure, as used by crypto:hash_xxx functions? > > Thanks in advance. > > V/ > > On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote: > >> Hi, >> >> I've been investigating a feasibility of saving of hash_state() -- used as a part of erlang:md5_init/md5_update/md5_final and/or their functional equivalents in crypto library; so it could be used later to implicitly reinitialize hash calculations. >> Well, (duh!) of course it is feasible; however, my concern was that the structure of this opaque value may change between different versions of Erlang run-time, and I was interested to see how these functions would behave when fake values for hash_state() are given. >> >> The results are interesting. >> >> A call to, say, erlang:md5_final( <<0:88/unsigned_integer-unit:8>> ) (*), or >> erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed >> crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) >> >> will all produce: >> >> <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> >> >> Presumably this may be due to some default value that has been used for all invalid values for hash_sate(). >> >> However, a call using a fake (yet "non-zero") value in crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) results in run-time crashing and reporting segmentation fault (and this cannot be a good thing, right?). >> >> As it appears that some internal tests are performed in order to verify the hash_state() value, would it possible to extend these test to cover other values without imposing unnecessary performance penalty? >> >> Or, alternatively, is there any way that this test could be performed externally (e.g. when in doubt and before calling a function that may crash the run-time)? in other words, is it possible to publish descriptions (e.g. structure) of various hash_state() values? >> >> Kind regards >> >> V/ >> >> (*) 88 corresponds to a size (in octets) of the erlang:md5_xxx hash_state() value, and conversely, 92 is a number of octets in md5 hash_state() equivalent used by crypto library. >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4161 bytes Desc: S/MIME Cryptographic Signature URL: From sverker@REDACTED Mon Apr 15 15:45:25 2019 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 15 Apr 2019 15:45:25 +0200 Subject: [erlang-questions] hash_state() and Segmentation Fault In-Reply-To: References: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> Message-ID: <1555335925.7075.8.camel@erlang.org> The crypto:hash_* functions have been type safe since OTP 19 (2016), you can no longer crash the Erlang VM ?by passing a fake hash_state argument. They are also pure functional. You can save a hash_state and use it as many times you want to fork off different hash caclulations. The only limitation is a hash_state only work in the VM instance that created it. /Sverker, Erlang/OTP On m?n, 2019-04-15 at 12:03 +0200, Valentin Micic wrote: > Hmmm? I may need to restate the question: > > Does anyone know where can one find a description of the hash_state() > structure, as used by crypto:hash_xxx functions? > > Thanks in advance. > > V/ > > On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote: > > > Hi,? > > > > I've been investigating a feasibility of saving of?hash_state() --?used as a > > part of erlang:md5_init/md5_update/md5_final and/or their functional > > equivalents in crypto library; so it could be used later to implicitly > > reinitialize hash calculations. > > Well, (duh!) of course it is feasible; however, my concern was that the > > structure of this opaque value may change between different versions of > > Erlang run-time, and I was interested to see how these functions would > > behave when fake values for?hash_state()??are given. > > > > The results are interesting. > > > > A call to, ?say,?erlang:md5_final( <<0:88/unsigned_integer-unit:8>> )?(*), > > or? > > ?erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed > > crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) > > > > will all produce: > > > > <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> > > > > Presumably this may be due to some default value that has been used for all > > invalid values for?hash_sate(). > > > > However, a call using a fake (yet "non-zero") value in ?crypto:hash_final( > > {md5, <<1:92/unsigned-integer-unit:8>>} )? results in run-time crashing and > > reporting segmentation fault (and this cannot be a good thing, right?). > > > > As it appears that some internal tests are performed in order to verify > > the?hash_state()?value, would ?it possible to extend these test to cover > > other values without imposing unnecessary performance penalty? > > > > Or, alternatively, is there any way that this test could be performed > > externally (e.g. when in doubt and before calling a function that may crash > > the run-time)? in other words, is it possible to publish descriptions (e.g. > > structure) of various hash_state() values? > > > > Kind regards > > > > V/ > > > > (*)?88?corresponds to a size (in octets) of the erlang:md5_xxx hash_state() > > value, and conversely,?92?is a number of octets in md5 hash_state() > > equivalent used by crypto library. > > > > _______________________________________________ > > 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 sverker@REDACTED Mon Apr 15 16:09:05 2019 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 15 Apr 2019 16:09:05 +0200 Subject: [erlang-questions] hash_state() and Segmentation Fault In-Reply-To: <1555335925.7075.8.camel@erlang.org> References: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> <1555335925.7075.8.camel@erlang.org> Message-ID: <1555337345.7075.12.camel@erlang.org> I amend: OTP 19 (or greater) + OpenSSL 1.0 (or greater) will give you type safe crypto:hash_* functions. On m?n, 2019-04-15 at 15:45 +0200, Sverker Eriksson wrote: > The crypto:hash_* functions have been type safe since OTP 19 (2016), you can > no longer crash the Erlang VM ?by passing a fake hash_state argument. > > They are also pure functional. You can save a hash_state and use it as many > times you want to fork off different hash caclulations. The only limitation is > a hash_state only work in the VM instance that created it. > > /Sverker, Erlang/OTP > > On m?n, 2019-04-15 at 12:03 +0200, Valentin Micic wrote: > > Hmmm? I may need to restate the question: > > > > Does anyone know where can one find a description of the hash_state() > > structure, as used by crypto:hash_xxx functions? > > > > Thanks in advance. > > > > V/ > > > > On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote: > > > > > Hi,? > > > > > > I've been investigating a feasibility of saving of?hash_state() --?used as > > > a part of erlang:md5_init/md5_update/md5_final and/or their functional > > > equivalents in crypto library; so it could be used later to implicitly > > > reinitialize hash calculations. > > > Well, (duh!) of course it is feasible; however, my concern was that the > > > structure of this opaque value may change between different versions of > > > Erlang run-time, and I was interested to see how these functions would > > > behave when fake values for?hash_state()??are given. > > > > > > The results are interesting. > > > > > > A call to, ?say,?erlang:md5_final( <<0:88/unsigned_integer-unit:8>> )?(*), > > > or? > > > ?erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed > > > crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) > > > > > > will all produce: > > > > > > <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> > > > > > > Presumably this may be due to some default value that has been used for > > > all invalid values for?hash_sate(). > > > > > > However, a call using a fake (yet "non-zero") value in ?crypto:hash_final( > > > {md5, <<1:92/unsigned-integer-unit:8>>} )? results in run-time crashing > > > and reporting segmentation fault (and this cannot be a good thing, > > > right?). > > > > > > As it appears that some internal tests are performed in order to verify > > > the?hash_state()?value, would ?it possible to extend these test to cover > > > other values without imposing unnecessary performance penalty? > > > > > > Or, alternatively, is there any way that this test could be performed > > > externally (e.g. when in doubt and before calling a function that may > > > crash the run-time)? in other words, is it possible to publish > > > descriptions (e.g. structure) of various hash_state() values? > > > > > > Kind regards > > > > > > V/ > > > > > > (*)?88?corresponds to a size (in octets) of the erlang:md5_xxx > > > hash_state() value, and conversely,?92?is a number of octets in md5 > > > hash_state() equivalent used by crypto library. > > > > > > _______________________________________________ > > > 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 v@REDACTED Mon Apr 15 16:51:39 2019 From: v@REDACTED (Valentin Micic) Date: Mon, 15 Apr 2019 16:51:39 +0200 Subject: [erlang-questions] hash_state() and Segmentation Fault In-Reply-To: <1555337345.7075.12.camel@erlang.org> References: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> <1555335925.7075.8.camel@erlang.org> <1555337345.7075.12.camel@erlang.org> Message-ID: On 15 Apr 2019, at 4:09 PM, Sverker Eriksson wrote: > I amend: > > OTP 19 (or greater) + OpenSSL 1.0 (or greater) will give you type safe crypto:hash_* functions. > Thanks Sverker, I like what you're saying, however that does not correspond to my experience. I've been performing my tests using Erlang/OTP 21.1, but when I called >>>> crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) therefore, using a fake hash_state() value which tend to cause VM to bail out reporting a segmentation fault. Could you please run the line above on one of your run-times (VM) and confirm your assertion. BTW: Thanks for the info about limiting usage of a hash_state() variable to the VM that created it -- that answered my (somewhat) silly question. Kind regards V/ > On m?n, 2019-04-15 at 15:45 +0200, Sverker Eriksson wrote: >> The crypto:hash_* functions have been type safe since OTP 19 (2016), you can no longer crash the Erlang VM by passing a fake hash_state argument. >> >> They are also pure functional. You can save a hash_state and use it as many times you want to fork off different hash caclulations. The only limitation is a hash_state only work in the VM instance that created it. >> >> /Sverker, Erlang/OTP >> >> On m?n, 2019-04-15 at 12:03 +0200, Valentin Micic wrote: >>> Hmmm? I may need to restate the question: >>> >>> Does anyone know where can one find a description of the hash_state() structure, as used by crypto:hash_xxx functions? >>> >>> Thanks in advance. >>> >>> V/ >>> >>> On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote: >>> >>>> Hi, >>>> >>>> I've been investigating a feasibility of saving of hash_state() -- used as a part of erlang:md5_init/md5_update/md5_final and/or their functional equivalents in crypto library; so it could be used later to implicitly reinitialize hash calculations. >>>> Well, (duh!) of course it is feasible; however, my concern was that the structure of this opaque value may change between different versions of Erlang run-time, and I was interested to see how these functions would behave when fake values for hash_state() are given. >>>> >>>> The results are interesting. >>>> >>>> A call to, say, erlang:md5_final( <<0:88/unsigned_integer-unit:8>> ) (*), or >>>> erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed >>>> crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) >>>> >>>> will all produce: >>>> >>>> <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> >>>> >>>> Presumably this may be due to some default value that has been used for all invalid values for hash_sate(). >>>> >>>> However, a call using a fake (yet "non-zero") value in crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) results in run-time crashing and reporting segmentation fault (and this cannot be a good thing, right?). >>>> >>>> As it appears that some internal tests are performed in order to verify the hash_state() value, would it possible to extend these test to cover other values without imposing unnecessary performance penalty? >>>> >>>> Or, alternatively, is there any way that this test could be performed externally (e.g. when in doubt and before calling a function that may crash the run-time)? in other words, is it possible to publish descriptions (e.g. structure) of various hash_state() values? >>>> >>>> Kind regards >>>> >>>> V/ >>>> >>>> (*) 88 corresponds to a size (in octets) of the erlang:md5_xxx hash_state() value, and conversely, 92 is a number of octets in md5 hash_state() equivalent used by crypto library. >>>> >>>> _______________________________________________ >>>> 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 v@REDACTED Mon Apr 15 16:56:24 2019 From: v@REDACTED (Valentin Micic) Date: Mon, 15 Apr 2019 16:56:24 +0200 Subject: [erlang-questions] hash_state() and Segmentation Fault In-Reply-To: <4a1c6667-7c5e-2d26-534f-e8415de029cd@ericsson.com> References: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> <4a1c6667-7c5e-2d26-534f-e8415de029cd@ericsson.com> Message-ID: Thanks Hans, For some reason, I've been under impression that newer versions of Erlang/OTP (19.x and higher) no longer have a dependency on (third party) OpenSSL library. Was I wrong to think that? Kind regards V/ On 15 Apr 2019, at 2:54 PM, Hans Nilsson R wrote: > The hash_state() is just an Erlang reference. It is created in the C-function hash_init_nif. It references an area with a C-struct evp_md_ctx containing the EVP_MD_CTX* returned from OpenSSL cryptolib. > > The area is allocated by enif_alloc_resource (see http://erlang.org/doc/man/erl_nif.html#enif_alloc_resource ) and the Erlang reference is created by enif_make_resource (same refman page) > > Read about the nif resource mechanism in http://erlang.org/doc/man/erl_nif.html section "Resource objects". > > /Hans > > On 4/15/19 12:03 PM, Valentin Micic wrote: >> Hmmm? I may need to restate the question: >> >> Does anyone know where can one find a description of the hash_state() structure, as used by crypto:hash_xxx functions? >> >> Thanks in advance. >> >> V/ >> >> On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote: >> >>> Hi, >>> >>> I've been investigating a feasibility of saving of hash_state() -- used as a part of erlang:md5_init/md5_update/md5_final and/or their functional equivalents in crypto library; so it could be used later to implicitly reinitialize hash calculations. >>> Well, (duh!) of course it is feasible; however, my concern was that the structure of this opaque value may change between different versions of Erlang run-time, and I was interested to see how these functions would behave when fake values for hash_state() are given. >>> >>> The results are interesting. >>> >>> A call to, say, erlang:md5_final( <<0:88/unsigned_integer-unit:8>> ) (*), or >>> erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed >>> crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) >>> >>> will all produce: >>> >>> <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> >>> >>> Presumably this may be due to some default value that has been used for all invalid values for hash_sate(). >>> >>> However, a call using a fake (yet "non-zero") value in crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) results in run-time crashing and reporting segmentation fault (and this cannot be a good thing, right?). >>> >>> As it appears that some internal tests are performed in order to verify the hash_state() value, would it possible to extend these test to cover other values without imposing unnecessary performance penalty? >>> >>> Or, alternatively, is there any way that this test could be performed externally (e.g. when in doubt and before calling a function that may crash the run-time)? in other words, is it possible to publish descriptions (e.g. structure) of various hash_state() values? >>> >>> Kind regards >>> >>> V/ >>> >>> (*) 88 corresponds to a size (in octets) of the erlang:md5_xxx hash_state() value, and conversely, 92 is a number of octets in md5 hash_state() equivalent used by crypto library. >>> >>> _______________________________________________ >>> 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 sverker@REDACTED Mon Apr 15 17:20:17 2019 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 15 Apr 2019 17:20:17 +0200 Subject: [erlang-questions] hash_state() and Segmentation Fault In-Reply-To: References: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> <1555335925.7075.8.camel@erlang.org> <1555337345.7075.12.camel@erlang.org> Message-ID: <1555341617.7075.16.camel@erlang.org> In OTP-21.2.7: 1> crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ). ** exception error: bad argument ?????in function??crypto:hash_final_nif/1 ????????called as crypto:hash_final_nif({md5,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, ???????????????????????????????????????????????0,0,...>>}) ?????in call from crypto:hash_final/1 (crypto.erl, line 395) 2> crypto:info_lib(). [{<<"OpenSSL">>,268443775,<<"OpenSSL 1.0.2g??1 Mar 2016">>}] and what does crypto:info_lib() tell you? /Sverker On m?n, 2019-04-15 at 16:51 +0200, Valentin Micic wrote: > > On 15 Apr 2019, at 4:09 PM, Sverker Eriksson wrote: > > > I amend: > > > > OTP 19 (or greater) + OpenSSL 1.0 (or greater) will give you type safe > > crypto:hash_* functions. > > > Thanks Sverker, > > I like what you're saying, however that does not correspond to my experience.? > I've been performing my tests using Erlang/OTP 21.1, but when I called > > > > > > crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) > therefore, using a fake hash_state() value which tend to cause VM ?to bail out > reporting a segmentation fault. > > Could you please run the line above on one of your run-times (VM) and confirm > your assertion. > > BTW: Thanks for the info about limiting usage of a hash_state() variable to > the VM that created it -- that answered my (somewhat) silly question. > > Kind regards > > V/ > > > > > On m?n, 2019-04-15 at 15:45 +0200, Sverker Eriksson wrote: > > > The crypto:hash_* functions have been type safe since OTP 19 (2016), you > > > can no longer crash the Erlang VM ?by passing a fake hash_state argument. > > > > > > They are also pure functional. You can save a hash_state and use it as > > > many times you want to fork off different hash caclulations. The only > > > limitation is a hash_state only work in the VM instance that created it. > > > > > > /Sverker, Erlang/OTP > > > > > > On m?n, 2019-04-15 at 12:03 +0200, Valentin Micic wrote: > > > > Hmmm? I may need to restate the question: > > > > > > > > Does anyone know where can one find a description of the hash_state() > > > > structure, as used by crypto:hash_xxx functions? > > > > > > > > Thanks in advance. > > > > > > > > V/ > > > > > > > > On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote: > > > > > > > > > Hi,? > > > > > > > > > > I've been investigating a feasibility of saving of?hash_state() > > > > > --?used as a part of erlang:md5_init/md5_update/md5_final and/or their > > > > > functional equivalents in crypto library; so it could be used later to > > > > > implicitly reinitialize hash calculations. > > > > > Well, (duh!) of course it is feasible; however, my concern was that > > > > > the structure of this opaque value may change between different > > > > > versions of Erlang run-time, and I was interested to see how these > > > > > functions would behave when fake values for?hash_state()??are given. > > > > > > > > > > The results are interesting. > > > > > > > > > > A call to, ?say,?erlang:md5_final( <<0:88/unsigned_integer-unit:8>> > > > > > )?(*), or? > > > > > ?erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, > > > > > indeed > > > > > crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) > > > > > > > > > > will all produce: > > > > > > > > > > <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> > > > > > > > > > > Presumably this may be due to some default value that has been used > > > > > for all invalid values for?hash_sate(). > > > > > > > > > > However, a call using a fake (yet "non-zero") value in > > > > > ?crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} )? results > > > > > in run-time crashing and reporting segmentation fault (and this cannot > > > > > be a good thing, right?). > > > > > > > > > > As it appears that some internal tests are performed in order to > > > > > verify the?hash_state()?value, would ?it possible to extend these test > > > > > to cover other values without imposing unnecessary performance > > > > > penalty? > > > > > > > > > > Or, alternatively, is there any way that this test could be performed > > > > > externally (e.g. when in doubt and before calling a function that may > > > > > crash the run-time)? in other words, is it possible to publish > > > > > descriptions (e.g. structure) of various hash_state() values? > > > > > > > > > > Kind regards > > > > > > > > > > V/ > > > > > > > > > > (*)?88?corresponds to a size (in octets) of the erlang:md5_xxx > > > > > hash_state() value, and conversely,?92?is a number of octets in md5 > > > > > hash_state() equivalent used by crypto library. > > > > > > > > > > _______________________________________________ > > > > > 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 v@REDACTED Mon Apr 15 18:14:06 2019 From: v@REDACTED (Valentin Micic) Date: Mon, 15 Apr 2019 18:14:06 +0200 Subject: [erlang-questions] hash_state() and Segmentation Fault In-Reply-To: <1555341617.7075.16.camel@erlang.org> References: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> <1555335925.7075.8.camel@erlang.org> <1555337345.7075.12.camel@erlang.org> <1555341617.7075.16.camel@erlang.org> Message-ID: <0BA5681A-B5B1-4B4C-8C54-C310BB733D79@micic.co.za> Good point. Embarrassingly, the version I am running is: [{<<"OpenSSL">>,9470255,<<"OpenSSL 0.9.8za 5 Jun 2014">>}] So, there's a culprit. Thanks! Universe make sense again. V/ On 15 Apr 2019, at 5:20 PM, Sverker Eriksson wrote: > In OTP-21.2.7: > > 1> crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ). > ** exception error: bad argument > in function crypto:hash_final_nif/1 > called as crypto:hash_final_nif({md5,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, > 0,0,...>>}) > in call from crypto:hash_final/1 (crypto.erl, line 395) > 2> crypto:info_lib(). > [{<<"OpenSSL">>,268443775,<<"OpenSSL 1.0.2g 1 Mar 2016">>}] > > > and what does crypto:info_lib() tell you? > > /Sverker > > On m?n, 2019-04-15 at 16:51 +0200, Valentin Micic wrote: >> >> On 15 Apr 2019, at 4:09 PM, Sverker Eriksson wrote: >> >>> I amend: >>> >>> OTP 19 (or greater) + OpenSSL 1.0 (or greater) will give you type safe crypto:hash_* functions. >>> >> >> Thanks Sverker, >> >> I like what you're saying, however that does not correspond to my experience. >> I've been performing my tests using Erlang/OTP 21.1, but when I called >> >>>>>> crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) >> >> therefore, using a fake hash_state() value which tend to cause VM to bail out reporting a segmentation fault. >> >> Could you please run the line above on one of your run-times (VM) and confirm your assertion. >> >> BTW: Thanks for the info about limiting usage of a hash_state() variable to the VM that created it -- that answered my (somewhat) silly question. >> >> Kind regards >> >> V/ >> >> >> >>> On m?n, 2019-04-15 at 15:45 +0200, Sverker Eriksson wrote: >>>> The crypto:hash_* functions have been type safe since OTP 19 (2016), you can no longer crash the Erlang VM by passing a fake hash_state argument. >>>> >>>> They are also pure functional. You can save a hash_state and use it as many times you want to fork off different hash caclulations. The only limitation is a hash_state only work in the VM instance that created it. >>>> >>>> /Sverker, Erlang/OTP >>>> >>>> On m?n, 2019-04-15 at 12:03 +0200, Valentin Micic wrote: >>>>> Hmmm? I may need to restate the question: >>>>> >>>>> Does anyone know where can one find a description of the hash_state() structure, as used by crypto:hash_xxx functions? >>>>> >>>>> Thanks in advance. >>>>> >>>>> V/ >>>>> >>>>> On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've been investigating a feasibility of saving of hash_state() -- used as a part of erlang:md5_init/md5_update/md5_final and/or their functional equivalents in crypto library; so it could be used later to implicitly reinitialize hash calculations. >>>>>> Well, (duh!) of course it is feasible; however, my concern was that the structure of this opaque value may change between different versions of Erlang run-time, and I was interested to see how these functions would behave when fake values for hash_state() are given. >>>>>> >>>>>> The results are interesting. >>>>>> >>>>>> A call to, say, erlang:md5_final( <<0:88/unsigned_integer-unit:8>> ) (*), or >>>>>> erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed >>>>>> crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) >>>>>> >>>>>> will all produce: >>>>>> >>>>>> <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> >>>>>> >>>>>> Presumably this may be due to some default value that has been used for all invalid values for hash_sate(). >>>>>> >>>>>> However, a call using a fake (yet "non-zero") value in crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) results in run-time crashing and reporting segmentation fault (and this cannot be a good thing, right?). >>>>>> >>>>>> As it appears that some internal tests are performed in order to verify the hash_state() value, would it possible to extend these test to cover other values without imposing unnecessary performance penalty? >>>>>> >>>>>> Or, alternatively, is there any way that this test could be performed externally (e.g. when in doubt and before calling a function that may crash the run-time)? in other words, is it possible to publish descriptions (e.g. structure) of various hash_state() values? >>>>>> >>>>>> Kind regards >>>>>> >>>>>> V/ >>>>>> >>>>>> (*) 88 corresponds to a size (in octets) of the erlang:md5_xxx hash_state() value, and conversely, 92 is a number of octets in md5 hash_state() equivalent used by crypto library. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 hans.r.nilsson@REDACTED Mon Apr 15 18:24:34 2019 From: hans.r.nilsson@REDACTED (Hans Nilsson R) Date: Mon, 15 Apr 2019 16:24:34 +0000 Subject: [erlang-questions] hash_state() and Segmentation Fault In-Reply-To: References: <1E81586C-F7B0-44AB-9323-F0808862CE7B@micic.co.za> <4a1c6667-7c5e-2d26-534f-e8415de029cd@ericsson.com> Message-ID: OTP still depends on a third-party cryptolib, OpenSSL or LibreSSL. We have no plans on including a cryptolib into OTP. /Hans On 4/15/19 4:56 PM, Valentin Micic wrote: > Thanks Hans, > > For some reason, I've been under impression that newer versions of Erlang/OTP (19.x and higher) no longer have a dependency on (third party) OpenSSL library. > Was I wrong to think that? > > Kind regards > > V/ > > On 15 Apr 2019, at 2:54 PM, Hans Nilsson R wrote: > >> The hash_state() is just an Erlang reference. It is created in the C-function hash_init_nif. It references an area with a C-struct evp_md_ctx containing the EVP_MD_CTX* returned from OpenSSL cryptolib. >> >> The area is allocated by enif_alloc_resource (see http://erlang.org/doc/man/erl_nif.html#enif_alloc_resource ) and the Erlang reference is created by enif_make_resource (same refman page) >> >> Read about the nif resource mechanism in http://erlang.org/doc/man/erl_nif.html section "Resource objects". >> >> /Hans >> >> On 4/15/19 12:03 PM, Valentin Micic wrote: >>> Hmmm? I may need to restate the question: >>> >>> Does anyone know where can one find a description of the hash_state() structure, as used by crypto:hash_xxx functions? >>> >>> Thanks in advance. >>> >>> V/ >>> >>> On 10 Apr 2019, at 1:08 PM, Valentin Micic wrote: >>> >>>> Hi, >>>> >>>> I've been investigating a feasibility of saving of hash_state() -- used as a part of erlang:md5_init/md5_update/md5_final and/or their functional equivalents in crypto library; so it could be used later to implicitly reinitialize hash calculations. >>>> Well, (duh!) of course it is feasible; however, my concern was that the structure of this opaque value may change between different versions of Erlang run-time, and I was interested to see how these functions would behave when fake values for hash_state() are given. >>>> >>>> The results are interesting. >>>> >>>> A call to, say, erlang:md5_final( <<0:88/unsigned_integer-unit:8>> ) (*), or >>>> erlang:md5_final( <<1212312312:88/unsigned_integer-unit:8>> ), or, indeed >>>> crypto:hash_final( {md5, <<0:92/unsigned-integer-unit:8>>} ) >>>> >>>> will all produce: >>>> >>>> <<176,230,65,201,152,204,62,174,111,162,248,114,109,152,205,221>> >>>> >>>> Presumably this may be due to some default value that has been used for all invalid values for hash_sate(). >>>> >>>> However, a call using a fake (yet "non-zero") value in crypto:hash_final( {md5, <<1:92/unsigned-integer-unit:8>>} ) results in run-time crashing and reporting segmentation fault (and this cannot be a good thing, right?). >>>> >>>> As it appears that some internal tests are performed in order to verify the hash_state() value, would it possible to extend these test to cover other values without imposing unnecessary performance penalty? >>>> >>>> Or, alternatively, is there any way that this test could be performed externally (e.g. when in doubt and before calling a function that may crash the run-time)? in other words, is it possible to publish descriptions (e.g. structure) of various hash_state() values? >>>> >>>> Kind regards >>>> >>>> V/ >>>> >>>> (*) 88 corresponds to a size (in octets) of the erlang:md5_xxx hash_state() value, and conversely, 92 is a number of octets in md5 hash_state() equivalent used by crypto library. >>>> >>>> _______________________________________________ >>>> 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4161 bytes Desc: S/MIME Cryptographic Signature URL: From paul@REDACTED Tue Apr 16 09:05:12 2019 From: paul@REDACTED (Paul Meinhardt) Date: Tue, 16 Apr 2019 09:05:12 +0200 Subject: [erlang-questions] Adding ssh-agent support to :ssh Message-ID: <60EB353F-5945-4D72-ADF9-04942947F3D4@bitcrowd.net> Hi there, I am planning to work on adding ssh-agent support to :ssh. In case anyone has already started working on this, please let get in touch. Otherwise I hope to share my first results in a PR on the official repository and will be happy about feedback and testers. Kind regards Paul From akorosmezey@REDACTED Tue Apr 16 13:27:16 2019 From: akorosmezey@REDACTED (Akos Korosmezey) Date: Tue, 16 Apr 2019 13:27:16 +0200 Subject: [erlang-questions] driver_create_port/4 and binary mode Message-ID: Hi all, I have problems setting binary mode in a port driver. I am trying to use the RDMA driver https://github.com/iamjamestl/rdma_dist Just like with TCP, the server side creates a new port (calling erl_driver:driver_create_port/4) upon accept. I cannot persuade this port to return binaries instead of lists. The client side does not create a new port and works without problem. I tried to include the binary option in various places or passing it with setopts, or calling set_port_control_flags(new_port, PORT_CONTROL_FLAG_BINARY) at C level without luck. Debugging into the emulator I saw that I was able to influence the 'control_flags' field of the Port struct but that was apparently not enough. Perhaps its 'state' field is influential, at least, that is read by get_port_flags. Am I making some trivial error here? Thanks, best regards Akos -------------- next part -------------- An HTML attachment was scrubbed... URL: From t6sn7gt@REDACTED Tue Apr 16 19:13:24 2019 From: t6sn7gt@REDACTED (Donald Steven) Date: Tue, 16 Apr 2019 13:13:24 -0400 Subject: [erlang-questions] Erlang app / GUI Message-ID: I'd sure appreciate recommendations for the best way to integrate GUI elements with an Erlang app.? (Some of the discussion out there seems a bit dated.)? What's the current view? Thanks, Don From russell@REDACTED Tue Apr 16 21:26:38 2019 From: russell@REDACTED (Russell Brown) Date: Tue, 16 Apr 2019 20:26:38 +0100 Subject: [erlang-questions] Erlang app / GUI In-Reply-To: References: Message-ID: I tried hard to use wxErlang, and never really got anywhere. Ended up going down the web tech route. On 16/04/2019 18:13, Donald Steven wrote: > I'd sure appreciate recommendations for the best way to integrate GUI > elements with an Erlang app.? (Some of the discussion out there seems > a bit dated.)? What's the current view? > > Thanks, > > Don > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dieter@REDACTED Tue Apr 16 21:46:20 2019 From: dieter@REDACTED (=?UTF-8?Q?Dieter_Sch=c3=b6n?=) Date: Tue, 16 Apr 2019 21:46:20 +0200 Subject: [erlang-questions] How do you go to production? In-Reply-To: References: Message-ID: <2402f96a-4a81-0f2f-282f-1a20b9b5888e@schoen.or.at> Hi, here is a case from the other end of the spectrum. I developed a protocol converter for a satellite test system, it is installed on 2 (in words: two)? PCs. For development, I used one application and rebar3. Production is just "rebar3 as prod tar" (From a labelled git commit). Testing was done on the two PCs, where I used one as the system under test and the other as test harness/data generator. I was also using wireshark and other third party tools, to prevent incestuous behaviour. To test the installation procedure I used docker, which was really nice. I had a blank machine in two seconds, where I could load and execute the installation script from the host. I had turnaround cycles from several seconds. What else.. the application is quite small. It fits into one erlang application. Apart from it, the release only contains the observer and sasl. Unit testing was done in EUnit. This was my first project where I used erlang, and the learning curve was quite gentle. Kind regards, Dieter Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin : Hi. I'm developing Flussonic for almost 10 years and we have some practices for packaging, deploying, running, maintainig that are not well known, however they are rather good for us. It is interesting how do other people solve this. At first, we do not use releases. It is because when we have started our long path, using of releases was not very easy.? Couple of days ago I've tested it with rebar3 and it is really easier to use. Perhaps we would use releases today. Next: we use our own fpm script replacement for packaging. I can boast that it seems to be the only existing implementation of rpm outside of original library, however I'd better never pass this path again. I've written it in pre-docker era and frankly speaking it is a traumatic experience. However, we are using it for debian and it is really convenient: https://github.com/flussonic/epm Some time ago we have switched to systemd. I personally consider systemd a very badly designed thing that was created without any discussions with existing system adminstrators. For example, systemd doesn't offer config validation before launch. Another brilliant idea is to offer libsystemd for linking into application. Unknown library with unknown quality. What can go wrong if you link it into your erlang or java application? Sorry, but no. We have systemd.erl: https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb Use Type=notify in? youdaemon.service After you manage to launch your erlang daemon, you need to collect statistics. We had to add some more linux-related tools to fetch: cpu usage, disk I/O usage, system ram usage (swap, etc), per-interface network statistics, udp errors count, nvidia card usage, etc. If this is worthy outsource, I think we can extract it. Our os_stat library is linked with our in-erlang pulsedb library. We try to maintain as less dependencies as possible, so we collect all ticks from monitoring tools inside erlang library pulsedb: https://github.com/pulsedb/pulsedb ?(maybe should update public branch) It can save several thousands metrics with one tick per 1-3 seconds. Support is an important part of our business, because customers cannot just launch software, they often need help.? We have many people in support staff and I do not want to manage their own public ssh keys on customer's servers. So we have written an ssh proxy: system that login to customer server with one private key and allow support guy to use his own key: https://github.com/flussonic/ssh-proxy All these things are rather useless for development and many of them are not required for in-house development, however it is hard to live without them when you sell software. What is your experience with such things that standard erlang lacks? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Tue Apr 16 21:54:03 2019 From: lloyd@REDACTED (lloyd@REDACTED) Date: Tue, 16 Apr 2019 15:54:03 -0400 (EDT) Subject: [erlang-questions] =?utf-8?q?How_do_you_go_to_production=3F?= In-Reply-To: <2402f96a-4a81-0f2f-282f-1a20b9b5888e@schoen.or.at> References: <2402f96a-4a81-0f2f-282f-1a20b9b5888e@schoen.or.at> Message-ID: <1555444443.677822950@apps.rackspace.com> Hi Dieter, Many thanks for sharing your experience. Could you please outline your installation procedure? Also, the size of your Docker application image (RAM footprint) ? I've been considering LXC containers, but I'd like to test with Docker. All the best, Lloyd -----Original Message----- From: "Dieter Sch?n" Sent: Tuesday, April 16, 2019 3:46pm To: "Erlang-Questions Questions" Subject: Re: [erlang-questions] How do you go to production? Hi, here is a case from the other end of the spectrum. I developed a protocol converter for a satellite test system, it is installed on 2 (in words: two) PCs. For development, I used one application and rebar3. Production is just "rebar3 as prod tar" (From a labelled git commit). Testing was done on the two PCs, where I used one as the system under test and the other as test harness/data generator. I was also using wireshark and other third party tools, to prevent incestuous behaviour. To test the installation procedure I used docker, which was really nice. I had a blank machine in two seconds, where I could load and execute the installation script from the host. I had turnaround cycles from several seconds. What else.. the application is quite small. It fits into one erlang application. Apart from it, the release only contains the observer and sasl. Unit testing was done in EUnit. This was my first project where I used erlang, and the learning curve was quite gentle. Kind regards, Dieter Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin [ ]( mailto:max.lapshin@REDACTED ): Hi. I'm developing Flussonic for almost 10 years and we have some practices for packaging, deploying, running, maintainig that are not well known, however they are rather good for us. It is interesting how do other people solve this. At first, we do not use releases. It is because when we have started our long path, using of releases was not very easy. Couple of days ago I've tested it with rebar3 and it is really easier to use. Perhaps we would use releases today. Next: we use our own fpm script replacement for packaging. I can boast that it seems to be the only existing implementation of rpm outside of original library, however I'd better never pass this path again. I've written it in pre-docker era and frankly speaking it is a traumatic experience. However, we are using it for debian and it is really convenient: [ https://github.com/flussonic/epm ]( https://github.com/flussonic/epm ) Some time ago we have switched to systemd. I personally consider systemd a very badly designed thing that was created without any discussions with existing system adminstrators. For example, systemd doesn't offer config validation before launch. Another brilliant idea is to offer libsystemd for linking into application. Unknown library with unknown quality. What can go wrong if you link it into your erlang or java application? Sorry, but no. We have systemd.erl: [ https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb ]( https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb ) Use Type=notify in youdaemon.service After you manage to launch your erlang daemon, you need to collect statistics. We had to add some more linux-related tools to fetch: cpu usage, disk I/O usage, system ram usage (swap, etc), per-interface network statistics, udp errors count, nvidia card usage, etc. If this is worthy outsource, I think we can extract it. Our os_stat library is linked with our in-erlang pulsedb library. We try to maintain as less dependencies as possible, so we collect all ticks from monitoring tools inside erlang library pulsedb: [ https://github.com/pulsedb/pulsedb ]( https://github.com/pulsedb/pulsedb ) (maybe should update public branch) It can save several thousands metrics with one tick per 1-3 seconds. Support is an important part of our business, because customers cannot just launch software, they often need help. We have many people in support staff and I do not want to manage their own public ssh keys on customer's servers. So we have written an ssh proxy: system that login to customer server with one private key and allow support guy to use his own key: [ https://github.com/flussonic/ssh-proxy ]( https://github.com/flussonic/ssh-proxy ) All these things are rather useless for development and many of them are not required for in-house development, however it is hard to live without them when you sell software. What is your experience with such things that standard erlang lacks? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dieter@REDACTED Tue Apr 16 22:24:46 2019 From: dieter@REDACTED (=?UTF-8?Q?Dieter_Sch=c3=b6n?=) Date: Tue, 16 Apr 2019 22:24:46 +0200 Subject: [erlang-questions] How do you go to production? In-Reply-To: <1555444443.677822950@apps.rackspace.com> References: <2402f96a-4a81-0f2f-282f-1a20b9b5888e@schoen.or.at> <1555444443.677822950@apps.rackspace.com> Message-ID: <84d11040-3ca2-5bef-49f8-4630f1373872@schoen.or.at> Hi Lloyd, this week I am not in the office, so I can just try to do a brain dump. The installation was quite simple, I installed a plain Ubuntu desktop, and then extracted the erlang tar file into /opt. This is done by one or two shell scripts. The erlang app is started on demand by another application, which is launched by the operator. So I do not have to deal with systemd (which I also do not like very much) or the like. My application could run as a server, but in the current use case there is no need for that. For the footprint of the docker container I will have to come back next week. I really have no idea how big it is. In former times I have used VirtualBoxes with snapshots for similar tasks, but if the focus is quite narrow, a docker container is far more easier and quicker than a complete VM. Regards, Dieter On 16.04.19 21:54, lloyd@REDACTED wrote: > > Hi Dieter, > > Many thanks for sharing your experience. > > Could you please outline your installation procedure?? Also, the size > of your Docker application image (RAM footprint) ? I've been > considering LXC containers, but I'd like to test with Docker. > > All the best, > > Lloyd > > -----Original Message----- > From: "Dieter Sch?n" > Sent: Tuesday, April 16, 2019 3:46pm > To: "Erlang-Questions Questions" > Subject: Re: [erlang-questions] How do you go to production? > > > Hi, > here is a case from the other end of the spectrum. > I developed a protocol converter for a satellite test system, it is > installed on 2 (in words: two)? PCs. > For development, I used one application and rebar3. Production is just > "rebar3 as prod tar" (From a labelled git commit). > Testing was done on the two PCs, where I used one as the system under > test and the other as test harness/data generator. > I was also using wireshark and other third party tools, to prevent > incestuous behaviour. > To test the installation procedure I used docker, which was really > nice. I had a blank machine in two seconds, > where I could load and execute the installation script from the host. > I had turnaround cycles from several seconds. > What else.. the application is quite small. It fits into one erlang > application. Apart from it, the release only contains the observer and > sasl. > Unit testing was done in EUnit. > > This was my first project where I used erlang, and the learning curve > was quite gentle. > Kind regards, > Dieter > > Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin : > > Hi. > I'm developing Flussonic for almost 10 years and we have some > practices for packaging, deploying, running, maintainig that are > not well known, however they are rather good for us. > It is interesting how do other people solve this. > At first, we do not use releases. It is because when we have > started our long path, using of releases was not very easy.? > Couple of days ago I've tested it with rebar3 and it is really > easier to use. Perhaps we would use releases today. > Next: we use our own fpm script replacement for packaging. I can > boast that it seems to be the only existing implementation of rpm > outside of original library, however I'd better never pass this > path again. I've written it in pre-docker era and frankly speaking > it is a traumatic experience. However, we are using it for debian > and it is really convenient: > https://github.com/flussonic/epm > Some time ago we have switched to systemd. I personally consider > systemd a very badly designed thing that was created without any > discussions with existing system adminstrators. For example, > systemd doesn't offer config validation before launch. Another > brilliant idea is to offer libsystemd for linking into > application. Unknown library with unknown quality. What can go > wrong if you link it into your erlang or java application? > Sorry, but no. We have systemd.erl: > https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb > Use Type=notify in? youdaemon.service > After you manage to launch your erlang daemon, you need to collect > statistics. We had to add some more linux-related tools to fetch: > cpu usage, disk I/O usage, system ram usage (swap, etc), > per-interface network statistics, udp errors count, nvidia card > usage, etc. > If this is worthy outsource, I think we can extract it. > Our os_stat library is linked with our in-erlang pulsedb library. > We try to maintain as less dependencies as possible, so we collect > all ticks from monitoring tools inside erlang library pulsedb: > https://github.com/pulsedb/pulsedb ?(maybe should update public > branch) > It can save several thousands metrics with one tick per 1-3 seconds. > Support is an important part of our business, because customers > cannot just launch software, they often need help.? We have many > people in support staff and I do not want to manage their own > public ssh keys on customer's servers. So we have written an ssh > proxy: system that login to customer server with one private key > and allow support guy to use his own key: > https://github.com/flussonic/ssh-proxy > All these things are rather useless for development and many of > them are not required for in-house development, however it is hard > to live without them when you sell software. > What is your experience with such things that standard erlang lacks? > > > _______________________________________________ > 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 Wed Apr 17 00:15:26 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Tue, 16 Apr 2019 18:15:26 -0400 Subject: [erlang-questions] How do you go to production? In-Reply-To: <84d11040-3ca2-5bef-49f8-4630f1373872@schoen.or.at> References: <2402f96a-4a81-0f2f-282f-1a20b9b5888e@schoen.or.at> <1555444443.677822950@apps.rackspace.com> <84d11040-3ca2-5bef-49f8-4630f1373872@schoen.or.at> Message-ID: <38AC67FD-30F8-47DC-BB38-32FAE1798B27@writersglen.com> Hi Dieter, Really helpful! From my poking around, Erlang deployment gets too little attention on the web or in the literature? particularly in this age of cloud deployment, containers, and distributed systems. So thanks again for your nuts-and-bolts overview. I?d love to read how others have brought Erlang apps and websites into production and lessons learned. Best wishes, Lloyd Sent from my iPad > On Apr 16, 2019, at 4:24 PM, Dieter Sch?n wrote: > > Hi Lloyd, > > this week I am not in the office, so I can just try to do a brain dump. > > The installation was quite simple, I installed a plain Ubuntu desktop, > > and then extracted the erlang tar file into /opt. This is done by one or two shell scripts. > > > > The erlang app is started on demand by another application, which is launched by the > > operator. > > So I do not have to deal with systemd (which I also do not like very much) or the like. > > My application could run as a server, but in the current use case there is no need for that. > > > > For the footprint of the docker container I will have to come back next week. > > I really have no idea how big it is. In former times I have used VirtualBoxes with snapshots > > for similar tasks, but if the focus is quite narrow, a docker container is far more easier and quicker > > than a complete VM. > > > > Regards, > > Dieter > > > >> On 16.04.19 21:54, lloyd@REDACTED wrote: >> Hi Dieter, >> >> Many thanks for sharing your experience. >> >> Could you please outline your installation procedure? Also, the size of your Docker application image (RAM footprint) ? I've been considering LXC containers, but I'd like to test with Docker. >> >> All the best, >> >> Lloyd >> >> >> >> -----Original Message----- >> From: "Dieter Sch?n" >> Sent: Tuesday, April 16, 2019 3:46pm >> To: "Erlang-Questions Questions" >> Subject: Re: [erlang-questions] How do you go to production? >> >> >> Hi, >> here is a case from the other end of the spectrum. >> I developed a protocol converter for a satellite test system, it is installed on 2 (in words: two) PCs. >> For development, I used one application and rebar3. Production is just "rebar3 as prod tar" (From a labelled git commit). >> Testing was done on the two PCs, where I used one as the system under test and the other as test harness/data generator. >> I was also using wireshark and other third party tools, to prevent incestuous behaviour. >> To test the installation procedure I used docker, which was really nice. I had a blank machine in two seconds, >> where I could load and execute the installation script from the host. I had turnaround cycles from several seconds. >> What else.. the application is quite small. It fits into one erlang application. Apart from it, the release only contains the observer and sasl. >> Unit testing was done in EUnit. >> >> This was my first project where I used erlang, and the learning curve was quite gentle. >> Kind regards, >> Dieter >> >> Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin : >> Hi. >> I'm developing Flussonic for almost 10 years and we have some practices for packaging, deploying, running, maintainig that are not well known, however they are rather good for us. >> It is interesting how do other people solve this. >> At first, we do not use releases. It is because when we have started our long path, using of releases was not very easy. Couple of days ago I've tested it with rebar3 and it is really easier to use. Perhaps we would use releases today. >> Next: we use our own fpm script replacement for packaging. I can boast that it seems to be the only existing implementation of rpm outside of original library, however I'd better never pass this path again. I've written it in pre-docker era and frankly speaking it is a traumatic experience. However, we are using it for debian and it is really convenient: >> https://github.com/flussonic/epm >> Some time ago we have switched to systemd. I personally consider systemd a very badly designed thing that was created without any discussions with existing system adminstrators. For example, systemd doesn't offer config validation before launch. Another brilliant idea is to offer libsystemd for linking into application. Unknown library with unknown quality. What can go wrong if you link it into your erlang or java application? >> Sorry, but no. We have systemd.erl: https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb >> Use Type=notify in youdaemon.service >> After you manage to launch your erlang daemon, you need to collect statistics. We had to add some more linux-related tools to fetch: cpu usage, disk I/O usage, system ram usage (swap, etc), per-interface network statistics, udp errors count, nvidia card usage, etc. >> If this is worthy outsource, I think we can extract it. >> Our os_stat library is linked with our in-erlang pulsedb library. We try to maintain as less dependencies as possible, so we collect all ticks from monitoring tools inside erlang library pulsedb: https://github.com/pulsedb/pulsedb (maybe should update public branch) >> It can save several thousands metrics with one tick per 1-3 seconds. >> Support is an important part of our business, because customers cannot just launch software, they often need help. We have many people in support staff and I do not want to manage their own public ssh keys on customer's servers. So we have written an ssh proxy: system that login to customer server with one private key and allow support guy to use his own key: https://github.com/flussonic/ssh-proxy >> All these things are rather useless for development and many of them are not required for in-house development, however it is hard to live without them when you sell software. >> What is your experience with such things that standard erlang lacks? >> >> >> _______________________________________________ >> 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 raimo+erlang-questions@REDACTED Wed Apr 17 11:54:42 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 17 Apr 2019 11:54:42 +0200 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} In-Reply-To: <119A945C-06F6-4E64-893E-9E6108D655F7@gmail.com> References: <20190412083842.GA84954@erix.ericsson.se> <20190412123835.GA486@erix.ericsson.se> <119A945C-06F6-4E64-893E-9E6108D655F7@gmail.com> Message-ID: <20190417095442.GA62025@erix.ericsson.se> After some discussions with the VM guys this seems to be a bug in gen_statem coming from a misunderstanding of which guarantees that asynchronous timer cancels gives and does not give. The {timeout, Ref, Msg} message may actually come _after_ the {cancel_timer, Ref, false} message. Heavy load seems to increase the probability from almost zero to very small. So the handling of these messages is broken for gen_statem on OTP-21, but this should be fixed on master (soon to be OTP-22) since gen_statem there does not use asynchronous timer cancels. I will look into how big a diff it will be to rewrite gen_statem in OTP-21.latest to use synchronous timer cancel... Thank you for finding a tricky bug! / Raimo On Fri, Apr 12, 2019 at 04:13:27PM +0100, Peter Morgan wrote: > Hi Raimo, > > Thanks for looking at this, and the background on the implementation which is very useful. I am in the process of putting together a simple test case, but having trouble reproducing it. It appears to happen very infrequently - possibly something that is load related? The original output was from the Crash Report which I?ve attached - where you can see the info timeout was received by our gen_statem behaviour callback. Our OTP is 21.2 (without any 21.2.X patches): > > {stdlib,"ERTS CXC 138 10","3.7?} > {kernel,"ERTS CXC 138 10","6.2?} > > > Your question - ?why so many?? - it could be a failure of a downstream service that is ultimately causing this, and we?re not backing off in this case - something that I?m checking too. However, I still thought it was interesting that the info timeout reaches the behaviour module. > > =CRASH REPORT==== 8-Apr-2019::23:37:19.038905 === <0.969.0> proc_lib:crash_report/4:508 > crasher: > initial call: kafire_fetcher:init/1 > pid: <0.969.0> > registered_name: [] > exception error: no function clause matching > kafire_fetcher:handle_event(info, > {timeout, > #Ref<0.2399112782.889192450.118024>, > fetch}, > subsequent_fetches, > our_state) (src/kafire_fetcher.erl, line 445) > in function gen_statem:call_state_function/5 (gen_statem.erl, line 1662) > in call from gen_statem:loop_event_state_function/6 (gen_statem.erl, line 1023) > ancestors: [<0.931.0>,<0.332.0>,kafire_cluster_sup,kafire_sup,<0.227.0>] > message_queue_len: 279 > messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118061>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118062>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118063>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118064>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118068>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118069>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118070>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118071>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118074>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118079>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118081>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118083>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118087>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118088>,0}, > {cancel_timer,#Ref<0.2399112782.889192450.118089>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118093>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118094>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118095>,3}, > {cancel_timer,#Ref<0.2399112782.889192450.118096>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118097>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118098>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118099>,3}, > {cancel_timer,#Ref<0.2399112782.889192450.118103>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118104>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118105>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118106>,3}, > {cancel_timer,#Ref<0.2399112782.889192450.118107>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118108>,1}, > {cancel_timer,#Ref<0.2399112782.889192450.118109>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118113>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118114>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118115>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118116>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118117>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118118>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118119>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118120>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118121>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118122>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118123>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118124>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118125>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118126>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118127>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118128>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118129>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118130>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118131>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118132>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118133>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118134>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118135>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118136>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118137>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118138>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118139>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118140>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118141>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118145>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118146>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118147>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118148>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118149>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118150>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118151>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118152>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118153>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118154>,5}, > {timeout,#Ref<0.2399112782.889192450.118159>,fetch}, > {cancel_timer,#Ref<0.2399112782.889192450.118159>,false}, > {cancel_timer,#Ref<0.2399112782.889192450.118165>,0}, > {cancel_timer,#Ref<0.2399112782.889192450.118169>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118170>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118173>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118174>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118175>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118176>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118177>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118178>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118179>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118180>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118181>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118182>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118183>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118184>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118185>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118189>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118190>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118191>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118192>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118196>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118197>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118198>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118199>,5}, > {timeout,#Ref<0.2399112782.889192450.118203>,fetch}, > {cancel_timer,#Ref<0.2399112782.889192450.118203>,false}, > {cancel_timer,#Ref<0.2399112782.889192450.118206>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118207>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118208>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118212>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118213>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118214>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118215>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118221>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118225>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118226>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118227>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118231>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118235>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118236>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118237>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118238>,2}, > {cancel_timer,#Ref<0.2399112782.889192450.118242>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118243>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118244>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118248>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118249>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118250>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118254>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118255>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118256>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118260>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118264>,0}, > {cancel_timer,#Ref<0.2399112782.889192450.118265>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118266>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118270>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118271>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118272>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118273>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118274>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118278>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118279>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118280>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118281>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118282>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118283>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118287>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118288>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118289>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118290>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118291>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118295>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118296>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118297>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118298>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118299>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118303>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118304>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118305>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118306>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118307>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118308>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118309>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118313>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118314>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118315>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118316>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118317>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118318>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118319>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118323>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118324>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118325>,5}, > {timeout,#Ref<0.2399112782.889192450.118326>,fetch}, > {cancel_timer,#Ref<0.2399112782.889192450.118326>,false}, > {cancel_timer,#Ref<0.2399112782.889192450.118327>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118328>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118329>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118330>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118331>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118332>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118333>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118337>,3}, > {cancel_timer,#Ref<0.2399112782.889192450.118338>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118339>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118340>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118344>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118345>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118346>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118347>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118351>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118352>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118353>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118357>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118358>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118359>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118360>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118364>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118365>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118366>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118367>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118371>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118372>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118373>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118377>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118378>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118379>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118383>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118384>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118385>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118389>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118390>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118391>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118392>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118393>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118394>,0}, > {cancel_timer,#Ref<0.2399112782.889192450.118395>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118399>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118400>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118401>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118402>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118403>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118404>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118405>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118409>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118410>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118411>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118412>,1}, > {cancel_timer,#Ref<0.2399112782.889192450.118413>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118414>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118415>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118419>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118420>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118421>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118422>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118423>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118424>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118425>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118429>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118430>,0}, > {cancel_timer,#Ref<0.2399112782.889192450.118431>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118432>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118433>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118434>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118435>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118439>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118440>,1}, > {cancel_timer,#Ref<0.2399112782.889192450.118441>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118442>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118443>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118444>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118445>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118449>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118450>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118451>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118452>,4}, > {cancel_timer,#Ref<0.2399112782.889192450.118453>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118454>,5}, > {cancel_timer,#Ref<0.2399112782.889192450.118455>,5}, > {timeout,#Ref<0.2399112782.889192450.118456>,fetch}, > {'EXIT',<0.10080.8>,normal}, > {'EXIT',<0.10079.8>,normal}, > {'EXIT',<0.10081.8>,normal}, > {'EXIT',<0.10082.8>,normal}, > {'EXIT',<0.10083.8>,normal}, > {'EXIT',<0.10084.8>,normal}, > {'EXIT',<0.10085.8>,normal}, > {'EXIT',<0.10086.8>,normal}, > {'EXIT',<0.10087.8>,normal}, > {'EXIT',<0.10088.8>,normal}, > {'EXIT',<0.10089.8>,normal}, > {'EXIT',<0.10071.8>,normal}] > links: [<0.931.0>] > dictionary: [] > trap_exit: true > status: running > heap_size: 17731 > stack_size: 27 > reductions: 28849413204 > neighbours: > > > I?ll try and get a simple test case for you. > Regards, > Peter. > > > > > On 12 Apr 2019, at 13:38, Raimo Niskanen wrote: > > > > On Fri, Apr 12, 2019 at 10:38:42AM +0200, Raimo Niskanen wrote: > >> On Wed, Apr 10, 2019 at 01:41:06PM +0100, Peter Morgan wrote: > >>> Hello - > >>> > >>> We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. > >>> > >>> The crash looks like: > >>> > >>> =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 > >>> ** State machine {kafire_fetcher,<>,<>,0} terminating > >>> ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} > >>> > >>> We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: > >>> > >>> > >>> message_queue_len: 279 > >>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > >>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > >>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, > >> > >> Is that from a process_info() call? > >> > >>> > >>> Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? > >> > >> It is not supposed to happen. This must be a bug. > >> > >> The gen_statem engine keeps track of the running state_timeout timer > >> and should never present it as an info event. > >> > >> When a timer is stopped (or restarted) it is done with an asynchronous > >> cancel (in OTP 21) so the cancel_timer messages comes from that. > >> They should be matched against map entries in the internal gen_statem > >> engine state when they arrive so them being in the inbox may be ok. > >> > >> However, how come you have so many? Are you restarting the state_timeout > >> in a very tight loop of repeat_state:s? Can you show the essential parts > >> of the code that causes state_timeout:s? > >> > >> Also - OTP-21.2; is that your exact OTP version? What is your stdlib version? > >> > >> I will look at the relevant parts of the code with the new knowledge that > >> a state_timeout timer can be lost, probably in combination with > >> repeat_state and state_timeout restart! > > > > > > Sorry, the knowledge did not help; I did not find anything suspicous. > > > > More information will be needed... > > > >> > >> On master since Jan 21 so in OTP-22.0-rc1 among other changes the timer handling > >> has been rewritten to use a synchronous cancel, which simplified the code > >> significantly. I do not know if that would be worth trying? > >> > >> / Raimo Niskanen > >> > >> > >>> > >>> Thanks > >>> Peter. > >>> > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From otp@REDACTED Wed Apr 17 12:37:46 2019 From: otp@REDACTED (Erlang/OTP) Date: Wed, 17 Apr 2019 12:37:46 +0200 Subject: [erlang-questions] Patch Package OTP 20.3.8.21 Released Message-ID: <20190417103746.GA48222@erix.ericsson.se> Patch Package: OTP 20.3.8.21 Git Tag: OTP-20.3.8.21 Date: 2019-04-17 Trouble Report Id: OTP-14746, OTP-15551, OTP-15657, OTP-15660, OTP-15690, OTP-15691, OTP-15716, OTP-15717, OTP-15757, OTP-15758, OTP-15763, OTP-15766 Seq num: ERIERL-143, ERIERL-324, ERIERL-334, ERIERL-342, ERL-869 System: OTP Release: 20 Application: common_test-1.15.4.2, erl_interface-3.10.2.2, erts-9.3.3.10, snmp-5.2.11.1, ssh-4.6.9.4, tools-2.11.2.1 Predecessor: OTP 20.3.8.20 Check out the git tag OTP-20.3.8.21, 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. --------------------------------------------------------------------- --- HIGHLIGHTS ------------------------------------------------------ --------------------------------------------------------------------- OTP-15691 Application(s): snmp Related Id(s): ERIERL-324 [snmp|agent] Add a get-mechanism callback module (and a corresponding behaviour). The agent calls this module to handle each get (get, get-next and get-bulk) request. --------------------------------------------------------------------- --- POTENTIAL INCOMPATIBILITIES ------------------------------------- --------------------------------------------------------------------- OTP-15717 Application(s): common_test Related Id(s): ERIERL-334 The test result when a hook function fails is in general the same as if the function that the hook is associated with fails. For example, if post_init_per_testcase fails the result is that the test case is skipped, as is the case when init_per_testcase fails.This, however, was earlier not true for timetrap timeouts or other error situations where the process running the hook function was killed. This is now corrected, so the error handling should be the same no matter how the hook function fails. --------------------------------------------------------------------- --- OTP-20.3.8.21 --------------------------------------------------- --------------------------------------------------------------------- --- 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-15657 Application(s): erts, otp, tools Minor fixes for make clean. --------------------------------------------------------------------- --- common_test-1.15.4.2 -------------------------------------------- --------------------------------------------------------------------- The common_test-1.15.4.2 application can be applied independently of other applications on a full OTP 20 installation. --- Fixed Bugs and Malfunctions --- OTP-15717 Application(s): common_test Related Id(s): ERIERL-334 *** POTENTIAL INCOMPATIBILITY *** The test result when a hook function fails is in general the same as if the function that the hook is associated with fails. For example, if post_init_per_testcase fails the result is that the test case is skipped, as is the case when init_per_testcase fails.This, however, was earlier not true for timetrap timeouts or other error situations where the process running the hook function was killed. This is now corrected, so the error handling should be the same no matter how the hook function fails. OTP-15758 Application(s): common_test Related Id(s): ERIERL-342 In some rare cases, when two common_test nodes used the same log directory, a timing problem could occur which caused common_test to crash because it's log cache file was unexpectedly empty. This is now corrected. --- Improvements and New Features --- OTP-14746 Application(s): common_test Related Id(s): ERIERL-143 Two new common_test hook functions are introduced: post_groups/2, which is called after Suite:groups/0 post_all/3, which is called after Suite:all/0 These functions allow modifying the return values from the groups/0 and all/0 functions, respectively. A new term, {testcase,TestCase,RepeatProperties} is now also allowed in the return from all/0. This can be used for repeating a single test case a specific number of times, or until it fails or succeeds once. OTP-15716 Application(s): common_test OTP internal test improvements. Full runtime dependencies of common_test-1.15.4.2: compiler-6.0, crypto-3.6, debugger-4.1, erts-7.0, inets-6.0, kernel-4.0, observer-2.1, runtime_tools-1.8.16, sasl-2.4.2, snmp-5.1.2, ssh-4.0, stdlib-3.4, syntax_tools-1.7, tools-2.8, xmerl-1.3.8 --------------------------------------------------------------------- --- erl_interface-3.10.2.2 ------------------------------------------ --------------------------------------------------------------------- The erl_interface-3.10.2.2 application can be applied independently of other applications on a full OTP 20 installation. --- Fixed Bugs and Malfunctions --- OTP-15757 Application(s): erl_interface Fix handling of Makefile dependencies so that parallel make works properly. --------------------------------------------------------------------- --- erts-9.3.3.10 --------------------------------------------------- --------------------------------------------------------------------- The erts-9.3.3.10 application can be applied independently of other applications on a full OTP 20 installation. --- 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-15657 Application(s): erts, otp, tools Minor fixes for make clean. OTP-15660 Application(s): erts Related Id(s): ERL-869 Fixed a bug in all ets:select* and ets:match* functions that could in some rare cases lead to very poor performance. 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. OTP-15766 Application(s): erts Add missing documentation of new external tags NEW_PID, NEW_PORT and NEWER_REFERENCE introduced in OTP 19. These new tags are planned to be "activated" in OTP 23 when distribution capability flag DFLAG_BIG_CREATION becomes mandatory. Older nodes (>= 19) are able to decode these new tags and send them back to the new node. Nodes older than OTP 23 will however never encode their own local pids, ports and references using the new tags. Full runtime dependencies of erts-9.3.3.10: kernel-5.0, sasl-3.0.1, stdlib-3.0 --------------------------------------------------------------------- --- snmp-5.2.11.1 --------------------------------------------------- --------------------------------------------------------------------- The snmp-5.2.11.1 application can be applied independently of other applications on a full OTP 20 installation. --- Improvements and New Features --- OTP-15691 Application(s): snmp Related Id(s): ERIERL-324 *** HIGHLIGHT *** [snmp|agent] Add a get-mechanism callback module (and a corresponding behaviour). The agent calls this module to handle each get (get, get-next and get-bulk) request. Full runtime dependencies of snmp-5.2.11.1: crypto-3.3, erts-6.0, kernel-3.0, mnesia-4.12, runtime_tools-1.8.14, stdlib-2.5 --------------------------------------------------------------------- --- ssh-4.6.9.4 ----------------------------------------------------- --------------------------------------------------------------------- Note! The ssh-4.6.9.4 application *cannot* be applied independently of other applications on an arbitrary OTP 20 installation. On a full OTP 20 installation, also the following runtime dependencies have to be satisfied: -- crypto-4.2 (first satisfied in OTP 20.2) -- public_key-1.5.2 (first satisfied in OTP 20.2) --- Fixed Bugs and Malfunctions --- OTP-15763 Application(s): ssh If a client was connected to an server on an already open socket, the callback fun(PeerName,FingerPrint) in the accept_callback option passed the local name in the argument PeerName instead of the remote name. Full runtime dependencies of ssh-4.6.9.4: crypto-4.2, erts-6.0, kernel-3.0, public_key-1.5.2, stdlib-3.3 --------------------------------------------------------------------- --- tools-2.11.2.1 -------------------------------------------------- --------------------------------------------------------------------- Note! The tools-2.11.2.1 application *cannot* be applied independently of other applications on an arbitrary OTP 20 installation. On a full OTP 20 installation, also the following runtime dependencies have to be satisfied: -- erts-9.1 (first satisfied in OTP 20.1) -- kernel-5.4 (first satisfied in OTP 20.1) --- Fixed Bugs and Malfunctions --- OTP-15657 Application(s): erts, otp, tools Minor fixes for make clean. Full runtime dependencies of tools-2.11.2.1: compiler-5.0, erts-9.1, kernel-5.4, runtime_tools-1.8.14, stdlib-3.4 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From raimo+erlang-questions@REDACTED Wed Apr 17 16:36:03 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 17 Apr 2019 16:36:03 +0200 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} In-Reply-To: <20190417095442.GA62025@erix.ericsson.se> References: <20190412083842.GA84954@erix.ericsson.se> <20190412123835.GA486@erix.ericsson.se> <119A945C-06F6-4E64-893E-9E6108D655F7@gmail.com> <20190417095442.GA62025@erix.ericsson.se> Message-ID: <20190417143603.GA85420@erix.ericsson.se> On Wed, Apr 17, 2019 at 11:54:42AM +0200, Raimo Niskanen wrote: > After some discussions with the VM guys this seems to be a bug in > gen_statem coming from a misunderstanding of which guarantees that > asynchronous timer cancels gives and does not give. > > The {timeout, Ref, Msg} message may actually come _after_ the > {cancel_timer, Ref, false} message. Heavy load seems to increase the > probability from almost zero to very small. > > So the handling of these messages is broken for gen_statem on OTP-21, but > this should be fixed on master (soon to be OTP-22) since gen_statem there > does not use asynchronous timer cancels. > > I will look into how big a diff it will be to rewrite gen_statem in OTP-21.latest > to use synchronous timer cancel... The diff became a fat one, so I created a pull request: https://github.com/erlang/otp/pull/2211 If you can try it out, that would be awsome! Best Regards / Raimo > > Thank you for finding a tricky bug! > / Raimo > > > > On Fri, Apr 12, 2019 at 04:13:27PM +0100, Peter Morgan wrote: > > Hi Raimo, > > > > Thanks for looking at this, and the background on the implementation which is very useful. I am in the process of putting together a simple test case, but having trouble reproducing it. It appears to happen very infrequently - possibly something that is load related? The original output was from the Crash Report which I?ve attached - where you can see the info timeout was received by our gen_statem behaviour callback. Our OTP is 21.2 (without any 21.2.X patches): > > > > {stdlib,"ERTS CXC 138 10","3.7?} > > {kernel,"ERTS CXC 138 10","6.2?} > > > > > > Your question - ?why so many?? - it could be a failure of a downstream service that is ultimately causing this, and we?re not backing off in this case - something that I?m checking too. However, I still thought it was interesting that the info timeout reaches the behaviour module. > > > > > =CRASH REPORT==== 8-Apr-2019::23:37:19.038905 === <0.969.0> proc_lib:crash_report/4:508 > > crasher: > > initial call: kafire_fetcher:init/1 > > pid: <0.969.0> > > registered_name: [] > > exception error: no function clause matching > > kafire_fetcher:handle_event(info, > > {timeout, > > #Ref<0.2399112782.889192450.118024>, > > fetch}, > > subsequent_fetches, > > our_state) (src/kafire_fetcher.erl, line 445) > > in function gen_statem:call_state_function/5 (gen_statem.erl, line 1662) > > in call from gen_statem:loop_event_state_function/6 (gen_statem.erl, line 1023) > > ancestors: [<0.931.0>,<0.332.0>,kafire_cluster_sup,kafire_sup,<0.227.0>] > > message_queue_len: 279 > > messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > > {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > > {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118061>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118062>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118063>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118064>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118068>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118069>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118070>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118071>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118074>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118079>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118081>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118083>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118087>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118088>,0}, > > {cancel_timer,#Ref<0.2399112782.889192450.118089>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118093>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118094>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118095>,3}, > > {cancel_timer,#Ref<0.2399112782.889192450.118096>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118097>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118098>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118099>,3}, > > {cancel_timer,#Ref<0.2399112782.889192450.118103>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118104>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118105>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118106>,3}, > > {cancel_timer,#Ref<0.2399112782.889192450.118107>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118108>,1}, > > {cancel_timer,#Ref<0.2399112782.889192450.118109>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118113>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118114>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118115>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118116>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118117>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118118>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118119>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118120>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118121>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118122>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118123>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118124>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118125>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118126>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118127>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118128>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118129>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118130>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118131>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118132>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118133>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118134>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118135>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118136>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118137>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118138>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118139>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118140>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118141>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118145>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118146>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118147>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118148>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118149>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118150>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118151>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118152>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118153>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118154>,5}, > > {timeout,#Ref<0.2399112782.889192450.118159>,fetch}, > > {cancel_timer,#Ref<0.2399112782.889192450.118159>,false}, > > {cancel_timer,#Ref<0.2399112782.889192450.118165>,0}, > > {cancel_timer,#Ref<0.2399112782.889192450.118169>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118170>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118173>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118174>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118175>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118176>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118177>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118178>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118179>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118180>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118181>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118182>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118183>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118184>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118185>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118189>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118190>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118191>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118192>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118196>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118197>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118198>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118199>,5}, > > {timeout,#Ref<0.2399112782.889192450.118203>,fetch}, > > {cancel_timer,#Ref<0.2399112782.889192450.118203>,false}, > > {cancel_timer,#Ref<0.2399112782.889192450.118206>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118207>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118208>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118212>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118213>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118214>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118215>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118221>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118225>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118226>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118227>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118231>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118235>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118236>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118237>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118238>,2}, > > {cancel_timer,#Ref<0.2399112782.889192450.118242>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118243>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118244>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118248>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118249>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118250>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118254>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118255>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118256>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118260>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118264>,0}, > > {cancel_timer,#Ref<0.2399112782.889192450.118265>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118266>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118270>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118271>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118272>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118273>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118274>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118278>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118279>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118280>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118281>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118282>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118283>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118287>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118288>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118289>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118290>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118291>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118295>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118296>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118297>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118298>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118299>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118303>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118304>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118305>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118306>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118307>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118308>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118309>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118313>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118314>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118315>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118316>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118317>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118318>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118319>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118323>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118324>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118325>,5}, > > {timeout,#Ref<0.2399112782.889192450.118326>,fetch}, > > {cancel_timer,#Ref<0.2399112782.889192450.118326>,false}, > > {cancel_timer,#Ref<0.2399112782.889192450.118327>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118328>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118329>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118330>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118331>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118332>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118333>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118337>,3}, > > {cancel_timer,#Ref<0.2399112782.889192450.118338>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118339>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118340>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118344>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118345>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118346>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118347>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118351>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118352>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118353>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118357>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118358>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118359>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118360>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118364>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118365>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118366>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118367>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118371>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118372>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118373>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118377>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118378>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118379>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118383>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118384>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118385>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118389>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118390>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118391>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118392>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118393>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118394>,0}, > > {cancel_timer,#Ref<0.2399112782.889192450.118395>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118399>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118400>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118401>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118402>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118403>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118404>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118405>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118409>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118410>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118411>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118412>,1}, > > {cancel_timer,#Ref<0.2399112782.889192450.118413>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118414>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118415>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118419>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118420>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118421>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118422>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118423>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118424>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118425>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118429>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118430>,0}, > > {cancel_timer,#Ref<0.2399112782.889192450.118431>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118432>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118433>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118434>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118435>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118439>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118440>,1}, > > {cancel_timer,#Ref<0.2399112782.889192450.118441>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118442>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118443>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118444>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118445>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118449>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118450>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118451>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118452>,4}, > > {cancel_timer,#Ref<0.2399112782.889192450.118453>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118454>,5}, > > {cancel_timer,#Ref<0.2399112782.889192450.118455>,5}, > > {timeout,#Ref<0.2399112782.889192450.118456>,fetch}, > > {'EXIT',<0.10080.8>,normal}, > > {'EXIT',<0.10079.8>,normal}, > > {'EXIT',<0.10081.8>,normal}, > > {'EXIT',<0.10082.8>,normal}, > > {'EXIT',<0.10083.8>,normal}, > > {'EXIT',<0.10084.8>,normal}, > > {'EXIT',<0.10085.8>,normal}, > > {'EXIT',<0.10086.8>,normal}, > > {'EXIT',<0.10087.8>,normal}, > > {'EXIT',<0.10088.8>,normal}, > > {'EXIT',<0.10089.8>,normal}, > > {'EXIT',<0.10071.8>,normal}] > > links: [<0.931.0>] > > dictionary: [] > > trap_exit: true > > status: running > > heap_size: 17731 > > stack_size: 27 > > reductions: 28849413204 > > neighbours: > > > > > > > I?ll try and get a simple test case for you. > > Regards, > > Peter. > > > > > > > > > On 12 Apr 2019, at 13:38, Raimo Niskanen wrote: > > > > > > On Fri, Apr 12, 2019 at 10:38:42AM +0200, Raimo Niskanen wrote: > > >> On Wed, Apr 10, 2019 at 01:41:06PM +0100, Peter Morgan wrote: > > >>> Hello - > > >>> > > >>> We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. > > >>> > > >>> The crash looks like: > > >>> > > >>> =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 > > >>> ** State machine {kafire_fetcher,<>,<>,0} terminating > > >>> ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} > > >>> > > >>> We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: > > >>> > > >>> > > >>> message_queue_len: 279 > > >>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > > >>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > > >>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > > >>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, > > >> > > >> Is that from a process_info() call? > > >> > > >>> > > >>> Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? > > >> > > >> It is not supposed to happen. This must be a bug. > > >> > > >> The gen_statem engine keeps track of the running state_timeout timer > > >> and should never present it as an info event. > > >> > > >> When a timer is stopped (or restarted) it is done with an asynchronous > > >> cancel (in OTP 21) so the cancel_timer messages comes from that. > > >> They should be matched against map entries in the internal gen_statem > > >> engine state when they arrive so them being in the inbox may be ok. > > >> > > >> However, how come you have so many? Are you restarting the state_timeout > > >> in a very tight loop of repeat_state:s? Can you show the essential parts > > >> of the code that causes state_timeout:s? > > >> > > >> Also - OTP-21.2; is that your exact OTP version? What is your stdlib version? > > >> > > >> I will look at the relevant parts of the code with the new knowledge that > > >> a state_timeout timer can be lost, probably in combination with > > >> repeat_state and state_timeout restart! > > > > > > > > > Sorry, the knowledge did not help; I did not find anything suspicous. > > > > > > More information will be needed... > > > > > >> > > >> On master since Jan 21 so in OTP-22.0-rc1 among other changes the timer handling > > >> has been rewritten to use a synchronous cancel, which simplified the code > > >> significantly. I do not know if that would be worth trying? > > >> > > >> / Raimo Niskanen > > >> > > >> > > >>> > > >>> Thanks > > >>> Peter. > > >>> > > > > > > -- > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From roger@REDACTED Wed Apr 17 21:34:19 2019 From: roger@REDACTED (Roger Lipscombe) Date: Wed, 17 Apr 2019 20:34:19 +0100 Subject: [erlang-questions] Cover compiling a release? Message-ID: We deploy a multi-node Erlang release to our staging environment, where we run a bunch of Python-driven end-to-end tests. I'd like to extract code coverage metrics, so we can figure out (a) whether we're missing any test scenarios, and (b) whether we can just delete a bunch of unused code. So: is there a way to compile an Erlang release (we use relx via erlang.mk) with coverage enabled, such that I can (e.g.) rpc into the node and gather coverage data for later analysis? From solvip@REDACTED Wed Apr 17 22:41:40 2019 From: solvip@REDACTED (=?utf-8?Q?S=C3=B6lvi_P=C3=A1ll_=C3=81sgeirsson?=) Date: Wed, 17 Apr 2019 22:41:40 +0200 Subject: [erlang-questions] How do you go to production? In-Reply-To: <38AC67FD-30F8-47DC-BB38-32FAE1798B27@writersglen.com> References: <2402f96a-4a81-0f2f-282f-1a20b9b5888e@schoen.or.at> <1555444443.677822950@apps.rackspace.com> <84d11040-3ca2-5bef-49f8-4630f1373872@schoen.or.at> <38AC67FD-30F8-47DC-BB38-32FAE1798B27@writersglen.com> Message-ID: <920D662D-B2A0-4931-B422-B2321891158E@gmail.com> We do a couple of things: - package some apps as RPMs for running as metal - package things as docker containers to be scheduled by ECS Generally, we just use ?rebar3 as prod release? and copy the resulting release into the package. For RPMs, we use fpm. I suspect it gets little attention because it?s extremely simple to make a prod ready release Sent from my iPhone > On 17 Apr 2019, at 00:15, Lloyd R. Prentice wrote: > > Hi Dieter, > > Really helpful! > > From my poking around, Erlang deployment gets too little attention on the web or in the literature? particularly in this age of cloud deployment, containers, and distributed systems. So thanks again for your nuts-and-bolts overview. > > I?d love to read how others have brought Erlang apps and websites into production and lessons learned. > > Best wishes, > > Lloyd > > > Sent from my iPad > >> On Apr 16, 2019, at 4:24 PM, Dieter Sch?n wrote: >> >> Hi Lloyd, >> >> this week I am not in the office, so I can just try to do a brain dump. >> >> The installation was quite simple, I installed a plain Ubuntu desktop, >> >> and then extracted the erlang tar file into /opt. This is done by one or two shell scripts. >> >> >> >> The erlang app is started on demand by another application, which is launched by the >> >> operator. >> >> So I do not have to deal with systemd (which I also do not like very much) or the like. >> >> My application could run as a server, but in the current use case there is no need for that. >> >> >> >> For the footprint of the docker container I will have to come back next week. >> >> I really have no idea how big it is. In former times I have used VirtualBoxes with snapshots >> >> for similar tasks, but if the focus is quite narrow, a docker container is far more easier and quicker >> >> than a complete VM. >> >> >> >> Regards, >> >> Dieter >> >> >> >>> On 16.04.19 21:54, lloyd@REDACTED wrote: >>> Hi Dieter, >>> >>> Many thanks for sharing your experience. >>> >>> Could you please outline your installation procedure? Also, the size of your Docker application image (RAM footprint) ? I've been considering LXC containers, but I'd like to test with Docker. >>> >>> All the best, >>> >>> Lloyd >>> >>> >>> >>> -----Original Message----- >>> From: "Dieter Sch?n" >>> Sent: Tuesday, April 16, 2019 3:46pm >>> To: "Erlang-Questions Questions" >>> Subject: Re: [erlang-questions] How do you go to production? >>> >>> >>> Hi, >>> here is a case from the other end of the spectrum. >>> I developed a protocol converter for a satellite test system, it is installed on 2 (in words: two) PCs. >>> For development, I used one application and rebar3. Production is just "rebar3 as prod tar" (From a labelled git commit). >>> Testing was done on the two PCs, where I used one as the system under test and the other as test harness/data generator. >>> I was also using wireshark and other third party tools, to prevent incestuous behaviour. >>> To test the installation procedure I used docker, which was really nice. I had a blank machine in two seconds, >>> where I could load and execute the installation script from the host. I had turnaround cycles from several seconds. >>> What else.. the application is quite small. It fits into one erlang application. Apart from it, the release only contains the observer and sasl. >>> Unit testing was done in EUnit. >>> >>> This was my first project where I used erlang, and the learning curve was quite gentle. >>> Kind regards, >>> Dieter >>> >>> Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin : >>> Hi. >>> I'm developing Flussonic for almost 10 years and we have some practices for packaging, deploying, running, maintainig that are not well known, however they are rather good for us. >>> It is interesting how do other people solve this. >>> At first, we do not use releases. It is because when we have started our long path, using of releases was not very easy. Couple of days ago I've tested it with rebar3 and it is really easier to use. Perhaps we would use releases today. >>> Next: we use our own fpm script replacement for packaging. I can boast that it seems to be the only existing implementation of rpm outside of original library, however I'd better never pass this path again. I've written it in pre-docker era and frankly speaking it is a traumatic experience. However, we are using it for debian and it is really convenient: >>> https://github.com/flussonic/epm >>> Some time ago we have switched to systemd. I personally consider systemd a very badly designed thing that was created without any discussions with existing system adminstrators. For example, systemd doesn't offer config validation before launch. Another brilliant idea is to offer libsystemd for linking into application. Unknown library with unknown quality. What can go wrong if you link it into your erlang or java application? >>> Sorry, but no. We have systemd.erl: https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb >>> Use Type=notify in youdaemon.service >>> After you manage to launch your erlang daemon, you need to collect statistics. We had to add some more linux-related tools to fetch: cpu usage, disk I/O usage, system ram usage (swap, etc), per-interface network statistics, udp errors count, nvidia card usage, etc. >>> If this is worthy outsource, I think we can extract it. >>> Our os_stat library is linked with our in-erlang pulsedb library. We try to maintain as less dependencies as possible, so we collect all ticks from monitoring tools inside erlang library pulsedb: https://github.com/pulsedb/pulsedb (maybe should update public branch) >>> It can save several thousands metrics with one tick per 1-3 seconds. >>> Support is an important part of our business, because customers cannot just launch software, they often need help. We have many people in support staff and I do not want to manage their own public ssh keys on customer's servers. So we have written an ssh proxy: system that login to customer server with one private key and allow support guy to use his own key: https://github.com/flussonic/ssh-proxy >>> All these things are rather useless for development and many of them are not required for in-house development, however it is hard to live without them when you sell software. >>> What is your experience with such things that standard erlang lacks? >>> >>> >>> _______________________________________________ >>> 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 lloyd@REDACTED Wed Apr 17 23:19:12 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Wed, 17 Apr 2019 17:19:12 -0400 Subject: [erlang-questions] How do you go to production? In-Reply-To: References: <2402f96a-4a81-0f2f-282f-1a20b9b5888e@schoen.or.at> <1555444443.677822950@apps.rackspace.com> <84d11040-3ca2-5bef-49f8-4630f1373872@schoen.or.at> <38AC67FD-30F8-47DC-BB38-32FAE1798B27@writersglen.com> Message-ID: <5F44B21C-5C31-4909-B2D1-1F57DEC15D8F@writersglen.com> Thanks Gerhard, > Anyone on the team can have a local setup as close to production as possible with a single command: make deploy-docker-stack-local . Yes, that's right: make is the secret sauce that holds everything together. Music to my ears! Since my work is self-funded, minimizing overhead through testing, beta, and start-up phases is very high on my list of essential goals. This detailed overview gives me greater insight and confidence into what?s possible. All the best, Lloyd Sent from my iPad > On Apr 17, 2019, at 5:11 AM, Gerhard Lazu wrote: > > We have been running Phoenix in production since 2016. The app serves a few TBs of traffic every month. > > We used to manage the entire infrastructure using Ansible, including app deploys as Docker containers. We used Concourse for the CI, this is what the entire infrastructure pipeline looked like: http://pipeline.gerhard.io/#/57 . The next couple of slides capture some of the tasks that used to run in various CI jobs. A peek into what used to happen on a new git commit to the app repository: http://pipeline.gerhard.io/#/60 . The entire infrastructure codebase is public: thechangelog/infrastructure > > We have learned so much from this initial way of doing things that we revamped the entire setup earlier this year. The new setup is captured in The new changelog.com setup for 2019. This is what the current development workflow looks like: > > > > My favourite part from the new setup is how the core config is captured in a Docker stack. This includes monitoring, logging, backups & app updater, as well as the regular 3-tier suspects: proxy, app & db. Because of this approach, the core setup can be reproduced locally, since all IaaS-specific gubbins are isolated in a separate layer. Anyone on the team can have a local setup as close to production as possible with a single command: make deploy-docker-stack-local . Yes, that's right: make is the secret sauce that holds everything together. It's always the simple things that have the potential of making the biggest difference (pun intended): > > > > This is what production looks like right now - make ctop > > > > Cheers, Gerhard. > >> On Tue, Apr 16, 2019 at 11:15 PM Lloyd R. Prentice wrote: >> Hi Dieter, >> >> Really helpful! >> >> From my poking around, Erlang deployment gets too little attention on the web or in the literature? particularly in this age of cloud deployment, containers, and distributed systems. So thanks again for your nuts-and-bolts overview. >> >> I?d love to read how others have brought Erlang apps and websites into production and lessons learned. >> >> Best wishes, >> >> Lloyd >> >> >> Sent from my iPad >> >>> On Apr 16, 2019, at 4:24 PM, Dieter Sch?n wrote: >>> >>> Hi Lloyd, >>> >>> this week I am not in the office, so I can just try to do a brain dump. >>> >>> The installation was quite simple, I installed a plain Ubuntu desktop, >>> >>> and then extracted the erlang tar file into /opt. This is done by one or two shell scripts. >>> >>> >>> >>> The erlang app is started on demand by another application, which is launched by the >>> >>> operator. >>> >>> So I do not have to deal with systemd (which I also do not like very much) or the like. >>> >>> My application could run as a server, but in the current use case there is no need for that. >>> >>> >>> >>> For the footprint of the docker container I will have to come back next week. >>> >>> I really have no idea how big it is. In former times I have used VirtualBoxes with snapshots >>> >>> for similar tasks, but if the focus is quite narrow, a docker container is far more easier and quicker >>> >>> than a complete VM. >>> >>> >>> >>> Regards, >>> >>> Dieter >>> >>> >>> >>>> On 16.04.19 21:54, lloyd@REDACTED wrote: >>>> Hi Dieter, >>>> >>>> Many thanks for sharing your experience. >>>> >>>> Could you please outline your installation procedure? Also, the size of your Docker application image (RAM footprint) ? I've been considering LXC containers, but I'd like to test with Docker. >>>> >>>> All the best, >>>> >>>> Lloyd >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: "Dieter Sch?n" >>>> Sent: Tuesday, April 16, 2019 3:46pm >>>> To: "Erlang-Questions Questions" >>>> Subject: Re: [erlang-questions] How do you go to production? >>>> >>>> >>>> Hi, >>>> here is a case from the other end of the spectrum. >>>> I developed a protocol converter for a satellite test system, it is installed on 2 (in words: two) PCs. >>>> For development, I used one application and rebar3. Production is just "rebar3 as prod tar" (From a labelled git commit). >>>> Testing was done on the two PCs, where I used one as the system under test and the other as test harness/data generator. >>>> I was also using wireshark and other third party tools, to prevent incestuous behaviour. >>>> To test the installation procedure I used docker, which was really nice. I had a blank machine in two seconds, >>>> where I could load and execute the installation script from the host. I had turnaround cycles from several seconds. >>>> What else.. the application is quite small. It fits into one erlang application. Apart from it, the release only contains the observer and sasl. >>>> Unit testing was done in EUnit. >>>> >>>> This was my first project where I used erlang, and the learning curve was quite gentle. >>>> Kind regards, >>>> Dieter >>>> >>>> Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin : >>>> Hi. >>>> I'm developing Flussonic for almost 10 years and we have some practices for packaging, deploying, running, maintainig that are not well known, however they are rather good for us. >>>> It is interesting how do other people solve this. >>>> At first, we do not use releases. It is because when we have started our long path, using of releases was not very easy. Couple of days ago I've tested it with rebar3 and it is really easier to use. Perhaps we would use releases today. >>>> Next: we use our own fpm script replacement for packaging. I can boast that it seems to be the only existing implementation of rpm outside of original library, however I'd better never pass this path again. I've written it in pre-docker era and frankly speaking it is a traumatic experience. However, we are using it for debian and it is really convenient: >>>> https://github.com/flussonic/epm >>>> Some time ago we have switched to systemd. I personally consider systemd a very badly designed thing that was created without any discussions with existing system adminstrators. For example, systemd doesn't offer config validation before launch. Another brilliant idea is to offer libsystemd for linking into application. Unknown library with unknown quality. What can go wrong if you link it into your erlang or java application? >>>> Sorry, but no. We have systemd.erl: https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb >>>> Use Type=notify in youdaemon.service >>>> After you manage to launch your erlang daemon, you need to collect statistics. We had to add some more linux-related tools to fetch: cpu usage, disk I/O usage, system ram usage (swap, etc), per-interface network statistics, udp errors count, nvidia card usage, etc. >>>> If this is worthy outsource, I think we can extract it. >>>> Our os_stat library is linked with our in-erlang pulsedb library. We try to maintain as less dependencies as possible, so we collect all ticks from monitoring tools inside erlang library pulsedb: https://github.com/pulsedb/pulsedb (maybe should update public branch) >>>> It can save several thousands metrics with one tick per 1-3 seconds. >>>> Support is an important part of our business, because customers cannot just launch software, they often need help. We have many people in support staff and I do not want to manage their own public ssh keys on customer's servers. So we have written an ssh proxy: system that login to customer server with one private key and allow support guy to use his own key: https://github.com/flussonic/ssh-proxy >>>> All these things are rather useless for development and many of them are not required for in-house development, however it is hard to live without them when you sell software. >>>> What is your experience with such things that standard erlang lacks? >>>> >>>> >>>> _______________________________________________ >>>> 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 pierrefenoll@REDACTED Wed Apr 17 23:31:26 2019 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Wed, 17 Apr 2019 23:31:26 +0200 Subject: [erlang-questions] How do you go to production? In-Reply-To: <920D662D-B2A0-4931-B422-B2321891158E@gmail.com> References: <2402f96a-4a81-0f2f-282f-1a20b9b5888e@schoen.or.at> <1555444443.677822950@apps.rackspace.com> <84d11040-3ca2-5bef-49f8-4630f1373872@schoen.or.at> <38AC67FD-30F8-47DC-BB38-32FAE1798B27@writersglen.com> <920D662D-B2A0-4931-B422-B2321891158E@gmail.com> Message-ID: Piping in since I'm not seeing our deployment procedure mentioned here (I may have missed emails cause Gmail seems to dislike this ML server). We push a git tag following semver (a plug-in that'd do something like Helm does: automatic decision on which part of major minor patch to bump would be interesting). This triggers GitlabCI jobs that runs tests and builds docker images at the same time (so QA/hitfixes don't have to wait for tests, cause skipping tests isn't easy). Docker images are built in stages. The release tarball is unpacked into the base OTP image and weights ~40MB compressed. It's nice to keep this size small so kubernetes can pull it quick. We always keep at least two instances running in prod behind the load balancer so we can deploy progressively. This only handles 20 requests second though. Tagging is a manual action. We don't use relups and in fact I've never worked at a company that did. It seems canary deployments are enough most of the time. Easier than thinking of the state changes a relup involves. In this perspective I think that the "embedded mode" should be the default mode of development. It'd help catch things earlier and maybe allow for more aggressive optimisations. Also we're running elixir. On Wed 17 Apr 2019 at 22:42, S?lvi P?ll ?sgeirsson wrote: > We do a couple of things: > - package some apps as RPMs for running as metal > - package things as docker containers to be scheduled by ECS > > Generally, we just use ?rebar3 as prod release? and copy the resulting > release into the package. For RPMs, we use fpm. > > I suspect it gets little attention because it?s extremely simple to make a > prod ready release > > Sent from my iPhone > > On 17 Apr 2019, at 00:15, Lloyd R. Prentice wrote: > > Hi Dieter, > > Really helpful! > > From my poking around, Erlang deployment gets too little attention on the > web or in the literature? particularly in this age of cloud deployment, > containers, and distributed systems. So thanks again for your > nuts-and-bolts overview. > > I?d love to read how others have brought Erlang apps and websites into > production and lessons learned. > > Best wishes, > > Lloyd > > > Sent from my iPad > > On Apr 16, 2019, at 4:24 PM, Dieter Sch?n wrote: > > Hi Lloyd, > > this week I am not in the office, so I can just try to do a brain dump. > > The installation was quite simple, I installed a plain Ubuntu desktop, > > and then extracted the erlang tar file into /opt. This is done by one or > two shell scripts. > > > The erlang app is started on demand by another application, which is > launched by the > > operator. > > So I do not have to deal with systemd (which I also do not like very much) > or the like. > > My application could run as a server, but in the current use case there is > no need for that. > > > For the footprint of the docker container I will have to come back next > week. > > I really have no idea how big it is. In former times I have used > VirtualBoxes with snapshots > > for similar tasks, but if the focus is quite narrow, a docker container is > far more easier and quicker > > than a complete VM. > > > Regards, > > Dieter > > > On 16.04.19 21:54, lloyd@REDACTED wrote: > > Hi Dieter, > > > > Many thanks for sharing your experience. > > > > Could you please outline your installation procedure? Also, the size of > your Docker application image (RAM footprint) ? I've been considering LXC > containers, but I'd like to test with Docker. > > > > All the best, > > > > Lloyd > > > > > > > > -----Original Message----- > From: "Dieter Sch?n" > Sent: Tuesday, April 16, 2019 3:46pm > To: "Erlang-Questions Questions" > > Subject: Re: [erlang-questions] How do you go to production? > > > Hi, > here is a case from the other end of the spectrum. > I developed a protocol converter for a satellite test system, it is > installed on 2 (in words: two) PCs. > For development, I used one application and rebar3. Production is just > "rebar3 as prod tar" (From a labelled git commit). > Testing was done on the two PCs, where I used one as the system under test > and the other as test harness/data generator. > I was also using wireshark and other third party tools, to prevent > incestuous behaviour. > To test the installation procedure I used docker, which was really nice. I > had a blank machine in two seconds, > where I could load and execute the installation script from the host. I > had turnaround cycles from several seconds. > What else.. the application is quite small. It fits into one erlang > application. Apart from it, the release only contains the observer and sasl. > Unit testing was done in EUnit. > > This was my first project where I used erlang, and the learning curve was > quite gentle. > Kind regards, > Dieter > > Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin > : > > Hi. > I'm developing Flussonic for almost 10 years and we have some practices > for packaging, deploying, running, maintainig that are not well known, > however they are rather good for us. > It is interesting how do other people solve this. > At first, we do not use releases. It is because when we have started our > long path, using of releases was not very easy. Couple of days ago I've > tested it with rebar3 and it is really easier to use. Perhaps we would use > releases today. > Next: we use our own fpm script replacement for packaging. I can boast > that it seems to be the only existing implementation of rpm outside of > original library, however I'd better never pass this path again. I've > written it in pre-docker era and frankly speaking it is a traumatic > experience. However, we are using it for debian and it is really convenient: > https://github.com/flussonic/epm > Some time ago we have switched to systemd. I personally consider systemd a > very badly designed thing that was created without any discussions with > existing system adminstrators. For example, systemd doesn't offer config > validation before launch. Another brilliant idea is to offer libsystemd for > linking into application. Unknown library with unknown quality. What can go > wrong if you link it into your erlang or java application? > Sorry, but no. We have systemd.erl: > https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb > Use Type=notify in youdaemon.service > After you manage to launch your erlang daemon, you need to collect > statistics. We had to add some more linux-related tools to fetch: cpu > usage, disk I/O usage, system ram usage (swap, etc), per-interface network > statistics, udp errors count, nvidia card usage, etc. > If this is worthy outsource, I think we can extract it. > Our os_stat library is linked with our in-erlang pulsedb library. We try > to maintain as less dependencies as possible, so we collect all ticks from > monitoring tools inside erlang library pulsedb: > https://github.com/pulsedb/pulsedb (maybe should update public branch) > It can save several thousands metrics with one tick per 1-3 seconds. > Support is an important part of our business, because customers cannot > just launch software, they often need help. We have many people in support > staff and I do not want to manage their own public ssh keys on customer's > servers. So we have written an ssh proxy: system that login to customer > server with one private key and allow support guy to use his own key: > https://github.com/flussonic/ssh-proxy > All these things are rather useless for development and many of them are > not required for in-house development, however it is hard to live without > them when you sell software. > What is your experience with such things that standard erlang lacks? > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://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 > -- Cheers, -- Pierre Fenoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloyd@REDACTED Thu Apr 18 00:10:25 2019 From: lloyd@REDACTED (lloyd@REDACTED) Date: Wed, 17 Apr 2019 18:10:25 -0400 (EDT) Subject: [erlang-questions] =?utf-8?q?How_do_you_go_to_production=3F?= In-Reply-To: References: <2402f96a-4a81-0f2f-282f-1a20b9b5888e@schoen.or.at> <1555444443.677822950@apps.rackspace.com> <84d11040-3ca2-5bef-49f8-4630f1373872@schoen.or.at> <38AC67FD-30F8-47DC-BB38-32FAE1798B27@writersglen.com> <920D662D-B2A0-4931-B422-B2321891158E@gmail.com> Message-ID: <1555539025.752229589@apps.rackspace.com> Hi Pierre, It's early days yet, so I'm still shopping for ideas and am much inspired to explore some presented so far on this thread. My system has some 25 services bundled into one big Erlang Nitgrogen app with at least one, if not more, connected through WAN (out-sourced Discourse). Some of the services are public with high read/low write; others are low read/low write controlled access but require maximum possible data availability and integrity. I'm exploring and intend to test various ways of factoring these services into containers. I'd love to hear more about your experience with Kubernetes. Scares me a bit since my devops skills are so deficient. Many thanks, Lloyd -----Original Message----- From: "Pierre Fenoll" Sent: Wednesday, April 17, 2019 5:31pm To: "S?lvi P?ll ?sgeirsson" Cc: "Dieter Sch?n" , "Lloyd R. Prentice" , erlang-questions@REDACTED Subject: Re: [erlang-questions] How do you go to production? Piping in since I'm not seeing our deployment procedure mentioned here (I may have missed emails cause Gmail seems to dislike this ML server). We push a git tag following semver (a plug-in that'd do something like Helm does: automatic decision on which part of major minor patch to bump would be interesting). This triggers GitlabCI jobs that runs tests and builds docker images at the same time (so QA/hitfixes don't have to wait for tests, cause skipping tests isn't easy). Docker images are built in stages. The release tarball is unpacked into the base OTP image and weights ~40MB compressed. It's nice to keep this size small so kubernetes can pull it quick. We always keep at least two instances running in prod behind the load balancer so we can deploy progressively. This only handles 20 requests second though. Tagging is a manual action. We don't use relups and in fact I've never worked at a company that did. It seems canary deployments are enough most of the time. Easier than thinking of the state changes a relup involves. In this perspective I think that the "embedded mode" should be the default mode of development. It'd help catch things earlier and maybe allow for more aggressive optimisations. Also we're running elixir. On Wed 17 Apr 2019 at 22:42, S?lvi P?ll ?sgeirsson <[ solvip@REDACTED ]( mailto:solvip@REDACTED )> wrote: We do a couple of things: - package some apps as RPMs for running as metal - package things as docker containers to be scheduled by ECS Generally, we just use ?rebar3 as prod release? and copy the resulting release into the package. For RPMs, we use fpm. I suspect it gets little attention because it?s extremely simple to make a prod ready release Sent from my iPhone On 17 Apr 2019, at 00:15, Lloyd R. Prentice <[ lloyd@REDACTED ]( mailto:lloyd@REDACTED )> wrote: Hi Dieter, Really helpful! From my poking around, Erlang deployment gets too little attention on the web or in the literature? particularly in this age of cloud deployment, containers, and distributed systems. So thanks again for your nuts-and-bolts overview. I?d love to read how others have brought Erlang apps and websites into production and lessons learned. Best wishes, Lloyd Sent from my iPad On Apr 16, 2019, at 4:24 PM, Dieter Sch?n <[ dieter@REDACTED ]( mailto:dieter@REDACTED )> wrote: Hi Lloyd, this week I am not in the office, so I can just try to do a brain dump. The installation was quite simple, I installed a plain Ubuntu desktop, and then extracted the erlang tar file into /opt. This is done by one or two shell scripts. The erlang app is started on demand by another application, which is launched by the operator. So I do not have to deal with systemd (which I also do not like very much) or the like. My application could run as a server, but in the current use case there is no need for that. For the footprint of the docker container I will have to come back next week. I really have no idea how big it is. In former times I have used VirtualBoxes with snapshots for similar tasks, but if the focus is quite narrow, a docker container is far more easier and quicker than a complete VM. Regards, Dieter On 16.04.19 21:54, [ lloyd@REDACTED ]( mailto:lloyd@REDACTED ) wrote: Hi Dieter, Many thanks for sharing your experience. Could you please outline your installation procedure? Also, the size of your Docker application image (RAM footprint) ? I've been considering LXC containers, but I'd like to test with Docker. All the best, Lloyd -----Original Message----- From: "Dieter Sch?n" [ ]( mailto:dieter@REDACTED ) Sent: Tuesday, April 16, 2019 3:46pm To: "Erlang-Questions Questions" [ ]( mailto:erlang-questions@REDACTED ) Subject: Re: [erlang-questions] How do you go to production? Hi, here is a case from the other end of the spectrum. I developed a protocol converter for a satellite test system, it is installed on 2 (in words: two) PCs. For development, I used one application and rebar3. Production is just "rebar3 as prod tar" (From a labelled git commit). Testing was done on the two PCs, where I used one as the system under test and the other as test harness/data generator. I was also using wireshark and other third party tools, to prevent incestuous behaviour. To test the installation procedure I used docker, which was really nice. I had a blank machine in two seconds, where I could load and execute the installation script from the host. I had turnaround cycles from several seconds. What else.. the application is quite small. It fits into one erlang application. Apart from it, the release only contains the observer and sasl. Unit testing was done in EUnit. This was my first project where I used erlang, and the learning curve was quite gentle. Kind regards, Dieter Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin [ ]( mailto:max.lapshin@REDACTED ): Hi. I'm developing Flussonic for almost 10 years and we have some practices for packaging, deploying, running, maintainig that are not well known, however they are rather good for us. It is interesting how do other people solve this. At first, we do not use releases. It is because when we have started our long path, using of releases was not very easy. Couple of days ago I've tested it with rebar3 and it is really easier to use. Perhaps we would use releases today. Next: we use our own fpm script replacement for packaging. I can boast that it seems to be the only existing implementation of rpm outside of original library, however I'd better never pass this path again. I've written it in pre-docker era and frankly speaking it is a traumatic experience. However, we are using it for debian and it is really convenient: [ https://github.com/flussonic/epm ]( https://github.com/flussonic/epm ) Some time ago we have switched to systemd. I personally consider systemd a very badly designed thing that was created without any discussions with existing system adminstrators. For example, systemd doesn't offer config validation before launch. Another brilliant idea is to offer libsystemd for linking into application. Unknown library with unknown quality. What can go wrong if you link it into your erlang or java application? Sorry, but no. We have systemd.erl: [ https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb ]( https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb ) Use Type=notify in youdaemon.service After you manage to launch your erlang daemon, you need to collect statistics. We had to add some more linux-related tools to fetch: cpu usage, disk I/O usage, system ram usage (swap, etc), per-interface network statistics, udp errors count, nvidia card usage, etc. If this is worthy outsource, I think we can extract it. Our os_stat library is linked with our in-erlang pulsedb library. We try to maintain as less dependencies as possible, so we collect all ticks from monitoring tools inside erlang library pulsedb: [ https://github.com/pulsedb/pulsedb ]( https://github.com/pulsedb/pulsedb ) (maybe should update public branch) It can save several thousands metrics with one tick per 1-3 seconds. Support is an important part of our business, because customers cannot just launch software, they often need help. We have many people in support staff and I do not want to manage their own public ssh keys on customer's servers. So we have written an ssh proxy: system that login to customer server with one private key and allow support guy to use his own key: [ https://github.com/flussonic/ssh-proxy ]( https://github.com/flussonic/ssh-proxy ) All these things are rather useless for development and many of them are not required for in-house development, however it is hard to live without them when you sell software. What is your experience with such things that standard erlang lacks? _______________________________________________erlang-questions mailing list[ erlang-questions@REDACTED ]( mailto:erlang-questions@REDACTED )[ http://erlang.org/mailman/listinfo/erlang-questions ]( http://erlang.org/mailman/listinfo/erlang-questions ) _______________________________________________ erlang-questions mailing list [ erlang-questions@REDACTED ]( mailto:erlang-questions@REDACTED ) [ http://erlang.org/mailman/listinfo/erlang-questions ]( http://erlang.org/mailman/listinfo/erlang-questions ) _______________________________________________ erlang-questions mailing list [ erlang-questions@REDACTED ]( mailto:erlang-questions@REDACTED ) [ http://erlang.org/mailman/listinfo/erlang-questions ]( http://erlang.org/mailman/listinfo/erlang-questions )_______________________________________________ erlang-questions mailing list [ erlang-questions@REDACTED ]( mailto:erlang-questions@REDACTED ) [ http://erlang.org/mailman/listinfo/erlang-questions ]( http://erlang.org/mailman/listinfo/erlang-questions )-- Cheers, -- Pierre Fenoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Thu Apr 18 14:09:13 2019 From: otp@REDACTED (Erlang/OTP) Date: Thu, 18 Apr 2019 14:09:13 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.6 Released Message-ID: <20190418120913.GA19630@erix.ericsson.se> Patch Package: OTP 21.3.6 Git Tag: OTP-21.3.6 Date: 2019-04-18 Trouble Report Id: OTP-15054 Seq num: ERIERL-346 System: OTP Release: 21 Application: ssl-9.2.2 Predecessor: OTP 21.3.5 Check out the git tag OTP-21.3.6, 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. --------------------------------------------------------------------- --- ssl-9.2.2 ------------------------------------------------------- --------------------------------------------------------------------- The ssl-9.2.2 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15054 Application(s): ssl Related Id(s): ERIERL-346 With the default BEAST Mitigation strategy for TLS 1.0 an empty TLS fragment could be sent after a one-byte fragment. This glitch has been fixed. Full runtime dependencies of ssl-9.2.2: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From peer@REDACTED Thu Apr 18 16:33:00 2019 From: peer@REDACTED (Peer Stritzinger) Date: Thu, 18 Apr 2019 16:33:00 +0200 Subject: [erlang-questions] [ANN] GRiSP 2 Kickstarter + Weekly Erlang Live Coding on Twitch.tv Message-ID: We make a new version offer GRiSP board and are starting a Erlang Live Coding Channel on Twitch.tv GRiSP 2 ======= GRiSP is a software platform that allows you to run the full Erlang VM directly on embedded hardware see https://www.grisp.org To get a nice use experience we have made a embedded evaluation board which we can support with our tooling. Now we are making a second version of this board: GRiSP 2 Main improvements from GRiSP 1 to GRiSP 2: * New faster and power efficient CPU * Modular hardware with all essentials on a System on Module -> easier to integrate in your own designs. * Wifi *and* Ethernet (we only had Wifi on GRiSP 1) * It runs the GRiSP software stack (BEAM directly on the hardware, tooling for Erlang&Elixir) but in addition it will be supporting the Nerves platform (runs Erlang VM with Elixir from process number 1 under Linux) To get started making this we are running a Kickstarter: https://www.kickstarter.com/projects/peerstritzinger/grisp-2?ref=b2e8kx Its fully funded already but we have nice stretch goals like a case and battery management still to reach. Disclaimer: we run this as a de facto non profit project so all funding (and quite some of our own) goes directly into the project which is fully open source. Twitch live coding channel ========================== Starting this Friday we will host a weekly Erlang live coding channel on Twitch.tv where we will work on projects using GRiSP and also work on GRiSP itself while you can watch us live while you can comment and as questions via chat. The channel ca be found and followed on here https://www.twitch.tv/grisporg Twitch.tv on Friday April 19th 2019 https://www.twitch.tv/events/WCUTOIzKRIW2uTO_E8ZQ1w ? Munich, Germany: Fri, 19 Apr 2019 at 18:00 CEST ? London, United Kingdom: Fri, 19 Apr 2019 at 17:00 BST ? New York, USA: Fri, 19 Apr 2019 at 12:00 EDT ? San Francisco, USA: Fri, 19 Apr 2019 at 09:00 PDT ? Moscow, Russia: Fri, 19 Apr 2019 at 19:00 MSK ? Corresponding UTC Fri, 19 Apr 2019 at 16:00 Best wishes and Happy Easter, -- Peer From fniksic@REDACTED Fri Apr 19 16:39:39 2019 From: fniksic@REDACTED (Filip Niksic) Date: Fri, 19 Apr 2019 10:39:39 -0400 Subject: [erlang-questions] Node mysteriously sends 11 MB while spawning a process on another node Message-ID: Hi all, I am trying to understand why a node sends 11 MB of unknown data to another node while spawning a process on that node. Let me briefly explain my setup. There are two nodes involved: main and a. I am running them in two docker containers, which in turn are running in a simulated network in which I can inspect and analyze network traffic using Wireshark. Once the nodes are started, main spawns a process on node a with spawn_link(). In Wireshark I can observe an exchange of ErlDP (distribution protocol) packets. The spawn_link causes a colossal REG_SEND message being sent from main to a; the message has length 11011057 (11 MB) and it is broken into 7605 TCP packets. Now, it has to be noted that one of the arguments to the spawned process is a function closure. Could it be that this closure causes the runtime to pack all of its data structures and pass them along with the message? If so, how can such a situation be avoided? Is there some general rule of thumb that function closures should not be passed as arguments in a distributed setting? Thanks, Filip -------------- next part -------------- An HTML attachment was scrubbed... URL: From csrl@REDACTED Fri Apr 19 17:01:47 2019 From: csrl@REDACTED (Chris Rempel) Date: Fri, 19 Apr 2019 17:01:47 +0200 Subject: [erlang-questions] [ANN] GRiSP 2 Kickstarter + Weekly Erlang Live Coding on Twitch.tv In-Reply-To: References: Message-ID: > * New faster and power efficient CPU What will be the total power draw - typical and max? Each watt counts. > Its fully funded already but we have nice stretch goals like a case and battery management still to reach. It would be great to see the battery / power management as the first stretch goal vs the case. Chris From dmkolesnikov@REDACTED Fri Apr 19 17:14:06 2019 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 19 Apr 2019 18:14:06 +0300 Subject: [erlang-questions] Node mysteriously sends 11 MB while spawning a process on another node In-Reply-To: References: Message-ID: <616089EE-0A41-443F-BFE3-AE71478F4B99@gmail.com> Hello > On 19 Apr 2019, at 17.39, Filip Niksic wrote: > > Now, it has to be noted that one of the arguments to the spawned process is a function closure. Could it be that this closure causes the runtime to pack all of its data structures and pass them along with the message? If so, how can such a situation be avoided? Is there some general rule of thumb that function closures should not be passed as arguments in a distributed setting? I would bet that usage of closure function is the major reason. Passing anonymous functions causes a serialisation of its entire environment. It might easily grow to 11MB. Some hints and discussion can be found here http://erlang.org/pipermail/erlang-questions/2008-November/039849.html The best practice to use fun Mod:Fun/N over fun() -> ? end. Best Regards, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Fri Apr 19 17:23:23 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 19 Apr 2019 17:23:23 +0200 Subject: [erlang-questions] Node mysteriously sends 11 MB while spawning a process on another node In-Reply-To: References: Message-ID: As Dmitry says, the closure must be sent upon the function spawn. If it is large, you can expect the 11MB to be sent when the function is spawned. The best way around it is to avoid sending a large body of information when you create a function. My guess is you are referencing a large map or list of data, which in turn gets copied. In some situations, this will also hurt when you spawn the same function locally, so there is good reason to avoid it there as well (though there are some caveats if the referenced data is part of the literal arena in the memory allocation system, and so on). On Fri, Apr 19, 2019 at 4:47 PM Filip Niksic wrote: > Hi all, > > I am trying to understand why a node sends 11 MB of unknown data to > another node while spawning a process on that node. > > Let me briefly explain my setup. There are two nodes involved: main and a. > I am running them in two docker containers, which in turn are running in a > simulated network in which I can inspect and analyze network traffic using > Wireshark. Once the nodes are started, main spawns a process on node a with > spawn_link(). In Wireshark I can observe an exchange of ErlDP (distribution > protocol) packets. The spawn_link causes a colossal REG_SEND message being > sent from main to a; the message has length 11011057 (11 MB) and it is > broken into 7605 TCP packets. > > Now, it has to be noted that one of the arguments to the spawned process > is a function closure. Could it be that this closure causes the runtime to > pack all of its data structures and pass them along with the message? If > so, how can such a situation be avoided? Is there some general rule of > thumb that function closures should not be passed as arguments in a > distributed setting? > > Thanks, > > Filip > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattevans123@REDACTED Sat Apr 20 21:07:31 2019 From: mattevans123@REDACTED (Matthew Evans) Date: Sat, 20 Apr 2019 19:07:31 +0000 Subject: [erlang-questions] Thank you for all you did Joe Armstrong...RIP Message-ID: Sent from my iPhone From lloyd@REDACTED Sat Apr 20 22:27:36 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sat, 20 Apr 2019 16:27:36 -0400 Subject: [erlang-questions] Programmers and teachers Message-ID: There are great programmers and great teachers. Joe Armstrong was both. May we all aspire to as much. Thank you, Joe. Lloyd Sent from my iPad From mononcqc@REDACTED Sun Apr 21 07:10:52 2019 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 21 Apr 2019 01:10:52 -0400 Subject: [erlang-questions] Programmers and teachers In-Reply-To: References: Message-ID: Thanks for this thread. Here?s my eulogy to Joe: https://ferd.ca/goodbye-joe.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex@REDACTED Sun Apr 21 08:18:05 2019 From: alex@REDACTED (alex@REDACTED) Date: Sun, 21 Apr 2019 02:18:05 -0400 Subject: [erlang-questions] Programmers and teachers In-Reply-To: References: Message-ID: <68f98f4503612a2163da9e22c7b40c02@smtp.hushmail.com> OMG!? Thank you Joe, RIP!!! On 4/21/19 1:10 AM, Fred Hebert wrote: > Thanks for this thread. > > Here?s my eulogy to Joe: > https://ferd.ca/goodbye-joe.html > > _______________________________________________ > 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 Apr 21 09:37:04 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sun, 21 Apr 2019 14:37:04 +0700 Subject: [erlang-questions] Programmers and teachers In-Reply-To: <68f98f4503612a2163da9e22c7b40c02@smtp.hushmail.com> References: <68f98f4503612a2163da9e22c7b40c02@smtp.hushmail.com> Message-ID: Hi Lloyd, It would be great if you print out this very memorial photo https://ferd.ca/static/img/joe-fred.jpg and put it on your wall. All of us will miss Joe Pada tanggal Min, 21 Apr 2019 13.18, alex@REDACTED menulis: > OMG! Thank you Joe, RIP!!! > > > On 4/21/19 1:10 AM, Fred Hebert wrote: > > Thanks for this thread. > > Here?s my eulogy to Joe: > https://ferd.ca/goodbye-joe.html > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://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 eric.pailleau@REDACTED Sun Apr 21 10:11:55 2019 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 21 Apr 2019 10:11:55 +0200 Subject: [erlang-questions] Programmers and teachers In-Reply-To: References: Message-ID: <52eaaeef-ea59-8ec8-37aa-9ab0186b8400@wanadoo.fr> Joe's epitaph ? "Brilliant Engineer, Awesome Man" From lloyd@REDACTED Sun Apr 21 16:04:08 2019 From: lloyd@REDACTED (Lloyd R. Prentice) Date: Sun, 21 Apr 2019 10:04:08 -0400 Subject: [erlang-questions] Programmers and teachers In-Reply-To: <52eaaeef-ea59-8ec8-37aa-9ab0186b8400@wanadoo.fr> References: <52eaaeef-ea59-8ec8-37aa-9ab0186b8400@wanadoo.fr> Message-ID: Very touching eulogy, Fred. Thanks. Best wishes, Lloyd Sent from my iPad > On Apr 21, 2019, at 4:11 AM, PAILLEAU Eric wrote: > > > Joe's epitaph ? > > > "Brilliant Engineer, Awesome Man" > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From okaprinarjaya@REDACTED Sun Apr 21 17:11:57 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sun, 21 Apr 2019 22:11:57 +0700 Subject: [erlang-questions] Programmers and teachers In-Reply-To: References: <52eaaeef-ea59-8ec8-37aa-9ab0186b8400@wanadoo.fr> Message-ID: Hi, Sorry my reply is for Fred. Haha so sorry, Pada tanggal Min, 21 Apr 2019 pukul 21.04 Lloyd R. Prentice < lloyd@REDACTED> menulis: > Very touching eulogy, Fred. Thanks. > > Best wishes, > > Lloyd > > > > Sent from my iPad > > > On Apr 21, 2019, at 4:11 AM, PAILLEAU Eric > wrote: > > > > > > Joe's epitaph ? > > > > > > "Brilliant Engineer, Awesome Man" > > _______________________________________________ > > 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 cleancode@REDACTED Mon Apr 22 04:29:54 2019 From: cleancode@REDACTED (cleancode) Date: Mon, 22 Apr 2019 10:29:54 +0800 Subject: [erlang-questions] Thank you for all you did Joe Armstrong...RIP In-Reply-To: References: Message-ID: > > What a sad news! I wanted to talk to Joe Armstrong in person but I didn?t, I thought there would be a better time... May he be happy programming in heaven. -------------- next part -------------- An HTML attachment was scrubbed... URL: From by@REDACTED Mon Apr 22 04:39:54 2019 From: by@REDACTED (by) Date: Mon, 22 Apr 2019 10:39:54 +0800 Subject: [erlang-questions] *WARNING* Missing application sasl. Can not upgrade with this release Message-ID: Hello List, Recently, I am trying to get familiar with "Creating and Upgrading a Target System?. I follow the instructions which documented here: http://erlang.org/doc/system_principles/create_target.html And I am done with 3.1, but with a *WARNING* message saying: "*WARNING* Missing application sasl. Can not upgrade with this release?. How can I suppress this message? By the way, I come from rebar3, and just want to understand how the underlying release handing works in Erlang itself. Best Regards, Yao Bao -------------- next part -------------- An HTML attachment was scrubbed... URL: From by@REDACTED Mon Apr 22 04:52:34 2019 From: by@REDACTED (by) Date: Mon, 22 Apr 2019 10:52:34 +0800 Subject: [erlang-questions] *WARNING* Missing application sasl. Can not upgrade with this release In-Reply-To: References: Message-ID: Sorry for the lack of information, I put the context here for your information: ==== MacBookPro:target_system by$ erl -boot ~/local/pkgs/erlang/erlang21.2.5/lib/erlang/bin/start_sasl -pz ~/local/pkgs/erlang/erlang21.2.5/lib/erlang/lib/sasl-3.3/ebin ~/projects/erls/hello/ebin Erlang/OTP 21 [erts-10.2.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe] Eshell V10.2.3 (abort with ^G) 1> target_system:create("mysystem"). Reading file: "mysystem.rel" ... Creating file: "./plain.rel" from "mysystem.rel" ... Making "./plain.script" and "./plain.boot" files ... *WARNING* Missing application sasl. Can not upgrade with this release Making "mysystem.script" and "mysystem.boot" files ... Creating tar file "mysystem.tar.gz" ... Creating directory "./tmp" ... Extracting "mysystem.tar.gz" into directory "./tmp" ... Deleting "erl" and "start" in directory "./tmp/erts-10.2.3/bin" ... Creating temporary directory "./tmp/bin" ... Copying file "./plain.boot" to "./tmp/bin/start.boot" ... Copying files "epmd", "run_erl" and "to_erl" from "./tmp/erts-10.2.3/bin" to "./tmp/bin" ... Creating temporary directory "./tmp/log" ... Creating "./tmp/releases/start_erl.data" ... Recreating tar file "mysystem.tar.gz" from contents in directory "./tmp" ... Removing directory "./tmp" ... ok 2> ==== > ? 2019?4?22??10:39?by ??? > > Hello List, > > Recently, I am trying to get familiar with "Creating and Upgrading a Target System?. > I follow the instructions which documented here: http://erlang.org/doc/system_principles/create_target.html > And I am done with 3.1, but with a *WARNING* message saying: "*WARNING* Missing application sasl. Can not upgrade with this release?. > How can I suppress this message? > > By the way, I come from rebar3, and just want to understand how the underlying release handing works in Erlang itself. > > Best Regards, > Yao Bao > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From by@REDACTED Mon Apr 22 08:32:51 2019 From: by@REDACTED (by) Date: Mon, 22 Apr 2019 14:32:51 +0800 Subject: [erlang-questions] *WARNING* Missing application sasl. Can not upgrade with this release In-Reply-To: References: Message-ID: <31850927-0889-4DC7-9B31-20C93A55D85E@meetlost.com> I believe I know what happened. I made a local copy of the library sail-3.3, and add some debug printing, use the local copy instead, then the reason shows. The "*WARNING*" message is for ?plain.boot?, and this only contains [{kernel,"6.2",permanent},{stdlib,"3.7",permanent}]. So the "*WARNING*" message correctly reflect what the document said. The console dump below puts the reason. ==== Erlang/OTP 21 [erts-10.2.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe] Eshell V10.2.3 (abort with ^G) 1> target_system:create("mysystem"). Reading file: "mysystem.rel" ... Creating file: "./plain.rel" from "mysystem.rel" ... Making "./plain.script" and "./plain.boot" files ... ====debug: [{kernel,"6.2",permanent},{stdlib,"3.7",permanent}] *WARNING* Missing application sasl. Can not upgrade with this release Making "mysystem.script" and "mysystem.boot" files ... ====debug: [{kernel,"6.2",permanent}, {stdlib,"3.7",permanent}, {sasl,"3.3",permanent}, {hello,"0.1.0",permanent}] Creating tar file "mysystem.tar.gz" ... ====debug: [{kernel,"6.2",permanent}, {stdlib,"3.7",permanent}, {sasl,"3.3",permanent}, {hello,"0.1.0",permanent}] Creating directory "./tmp" ... Extracting "mysystem.tar.gz" into directory "./tmp" ... Deleting "erl" and "start" in directory "./tmp/erts-10.2.3/bin" ... Creating temporary directory "./tmp/bin" ... Copying file "./plain.boot" to "./tmp/bin/start.boot" ... Copying files "epmd", "run_erl" and "to_erl" from "./tmp/erts-10.2.3/bin" to "./tmp/bin" ... Creating temporary directory "./tmp/log" ... Creating "./tmp/releases/start_erl.data" ... Recreating tar file "mysystem.tar.gz" from contents in directory "./tmp" ... Removing directory "./tmp" ... ok 2> ==== > ? 2019?4?22??10:52?by ??? > > Sorry for the lack of information, I put the context here for your information: > ==== > MacBookPro:target_system by$ erl -boot ~/local/pkgs/erlang/erlang21.2.5/lib/erlang/bin/start_sasl -pz ~/local/pkgs/erlang/erlang21.2.5/lib/erlang/lib/sasl-3.3/ebin ~/projects/erls/hello/ebin > Erlang/OTP 21 [erts-10.2.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe] > > Eshell V10.2.3 (abort with ^G) > 1> target_system:create("mysystem"). > Reading file: "mysystem.rel" ... > Creating file: "./plain.rel" from "mysystem.rel" ... > Making "./plain.script" and "./plain.boot" files ... > *WARNING* Missing application sasl. Can not upgrade with this release > Making "mysystem.script" and "mysystem.boot" files ... > Creating tar file "mysystem.tar.gz" ... > Creating directory "./tmp" ... > Extracting "mysystem.tar.gz" into directory "./tmp" ... > Deleting "erl" and "start" in directory "./tmp/erts-10.2.3/bin" ... > Creating temporary directory "./tmp/bin" ... > Copying file "./plain.boot" to "./tmp/bin/start.boot" ... > Copying files "epmd", "run_erl" and "to_erl" from > "./tmp/erts-10.2.3/bin" to "./tmp/bin" ... > Creating temporary directory "./tmp/log" ... > Creating "./tmp/releases/start_erl.data" ... > Recreating tar file "mysystem.tar.gz" from contents in directory "./tmp" ... > Removing directory "./tmp" ... > ok > 2> > ==== > >> ? 2019?4?22??10:39?by > ??? >> >> Hello List, >> >> Recently, I am trying to get familiar with "Creating and Upgrading a Target System?. >> I follow the instructions which documented here: http://erlang.org/doc/system_principles/create_target.html >> And I am done with 3.1, but with a *WARNING* message saying: "*WARNING* Missing application sasl. Can not upgrade with this release?. >> How can I suppress this message? >> >> By the way, I come from rebar3, and just want to understand how the underlying release handing works in Erlang itself. >> >> Best Regards, >> Yao Bao >> _______________________________________________ >> 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 jesper.louis.andersen@REDACTED Mon Apr 22 10:27:27 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 22 Apr 2019 10:27:27 +0200 Subject: [erlang-questions] Programmers and teachers In-Reply-To: References: Message-ID: I'll add mine as well: https://jlouis.github.io/posts/joe-goodbye/ On Sun, Apr 21, 2019 at 7:11 AM Fred Hebert wrote: > Thanks for this thread. > > Here?s my eulogy to Joe: > https://ferd.ca/goodbye-joe.html > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz@REDACTED Tue Apr 23 00:40:13 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Tue, 23 Apr 2019 10:40:13 +1200 Subject: [erlang-questions] Programmers and teachers In-Reply-To: References: Message-ID: What? Joe Armstrong is dead? Oh *NO*! I am so grateful to him for several things and I hoped to say so to his face one day. Why is it raining on my glasses? On Sun, 21 Apr 2019 at 08:27, Lloyd R. Prentice wrote: > There are great programmers and great teachers. Joe Armstrong was both. > May we all aspire to as much. > > Thank you, Joe. > > Lloyd > > Sent from my iPad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierlu@REDACTED Tue Apr 23 12:10:37 2019 From: pierlu@REDACTED (pierlu) Date: Tue, 23 Apr 2019 12:10:37 +0200 Subject: [erlang-questions] Thank you for all you did Joe Armstrong...RIP In-Reply-To: References: Message-ID: I only had become aware of Erlang at the beginning of 2019 and just a month ago I started being interested in it and bought Programming in Erlang. Yet I have to start reading the book, but I saw a few conferences on youtube by mr. Armstrong and it seemed to me he was very passionate and witty and humble. I signed with this newsletter so to get acquainted with the language and spotted that mr. Armstrong posted on the list: his style of writing and his approach confirmed what I have seen in the videos that he was truly a genuine person. I am very saddened to hear the news. Peace. pierlu. On Sat, Apr 20, 2019 at 9:07 PM Matthew Evans wrote: > > Sent from my iPhone > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v@REDACTED Tue Apr 23 13:19:57 2019 From: v@REDACTED (Valentin Micic) Date: Tue, 23 Apr 2019 13:19:57 +0200 Subject: [erlang-questions] A life worth living. In-Reply-To: References: Message-ID: <9BEF5353-D495-4DC2-AB79-0BFACD531DCD@micic.co.za> Dr Joe created a series ripple in our minds (and our hearts). When I met him, he made me feel like I knew him all along. Yes, maybe someone may be able to live even better life, but not by much (..and when I grow up, I want to be just like that!). Indeed, a life worth living. From vfordos@REDACTED Wed Apr 24 10:10:43 2019 From: vfordos@REDACTED (Viktoria Fordos (vfordos)) Date: Wed, 24 Apr 2019 08:10:43 +0000 Subject: [erlang-questions] 3RD CALL FOR PAPERS: Erlang Workshop 2019 Message-ID: <3EDEDB94-4B3E-4AD1-AF37-088BE7D4ECF6@cisco.com> Technical, practice, and application papers related to Erlang, BEAM, Elixir, Scala/Akka, CloudHaskell, Lisp Flavoured Erlang, OCaml, and functional programming are welcome and encouraged. 3RD CALL FOR PAPERS Eighteenth ACM SIGPLAN Erlang Workshop https://icfp19.sigplan.org/home/erlang-2019 Berlin, Germany, 18 August 2019 Satellite event of the 24th ACM SIGPLAN International Conference on Functional Programming (ICFP 2019) 18 - 23 August, 2019 The Erlang Workshop aims to bring together the open source, academic, and industrial communities of Erlang, to discuss technologies and languages related to Erlang. The Erlang model of concurrent programming has been widely emulated, for example by Akka in Scala, and even new programming languages were designed atop of the Erlang VM, such as Elixir. Therefore we would like to broaden the scope of the workshop to include systems like those mentioned above. The workshop will enable participants to familiarize themselves with recent developments on new techniques and tools, novel applications, draw lessons from users' experiences and identify research problems and common areas relevant to the practice of Erlang, Erlang-like languages, functional programming, distribution, concurrency etc. We invite two types of submissions. 1. Technical papers describing language extensions, critical discussions of the status quo, formal semantics of language constructs, program analysis and transformation, virtual machine extensions and compilation techniques, implementations and interfaces of Erlang in/with other languages, and new tools (profilers, tracers, debuggers, testing frameworks, etc.). Submission related to Erlang, Elixir, Scala/Akka, CloudHaskell, Lisp Flavoured Erlang, OCaml, and functional programming are welcome and encouraged. The maximum length for technical papers is restricted to 12 pages, but short papers (max. 6 pages) are welcomed as well. 2. Practice and application papers describing uses of Erlang in the "real-world", Erlang libraries for specific tasks, experiences from using Erlang in specific application domains, reusable programming idioms and elegant new ways of using Erlang to approach or solve a particular problem. The maximum length for the practice and application papers is restricted to 12 pages, but short papers (max. 6 pages) are welcomed as well. Workshop Co-Chairs Adrian Francalanza, University of Malta, Malta Vikt?ria F?rd?s, Cisco Systems, Sweden Program Committee (Note: the Workshop Co-Chairs are also committee members) Annette Bieniusa, University of Kaiserslautern, Germany Christopher S. Meiklejohn, Carnegie Mellon University, USA Clara Benac Earle, Universidad Politecnica de Madrid, Spain Claudio Antares Mezzina, IMT Lucca, Italy Emilio Tuosto, University of Leicester, UK Felix Mulder, Klarna AB, Sweden Francesco Cesarini, Erlang Solutions Ltd, UK Julien Lange, University of Kent, UK Kenji Rikitake, KRPEO, Japan Melinda T?th, ELTE E?tv?s Lor?nd University, Hungary Natalia Chechina, Bournemouth University, UK Rumyana Neykova, Brunel University, UK Scott Lystig Fritchie, Wallaroo, USA Thomas Arts, Quviq AB, Sweden Torben Hoffmann, Alert Logic, Denmark Important Dates Submission deadline: Fri May 10, 2019 Author notification: Fri June 7, 2019 Final submission for the publisher: Sun June 30, 2019 Workshop date: Sun August 18, 2019 Instructions to authors Papers must be submitted online via HotCRP (via the "Erlang2019" event). The submission page is https://erlang19.hotcrp.com Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Each submission must adhere to SIGPLAN's republication policy. Violation risks summary rejection of the offending submission. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. Paper submissions will be considered for poster submission in the case they are not accepted as full papers. Venue & Registration Details For registration, please see the ICFP 2019 web site at: http://icfp19.sigplan.org/ Related Links ICFP 2019 web site: http://icfp19.sigplan.org/ Past ACM SIGPLAN Erlang workshops: http://www.erlang.org/workshop/ Open Source Erlang: http://www.erlang.org/ HotCRP submission site: https://erlang19.hotcrp.com Author Information for SIGPLAN Conferences: http://www.sigplan.org/authorInformation.htm Attendee Information for SIGPLAN Events: http://www.sigplan.org/Resources/Policies/CodeOfConduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Wed Apr 24 10:46:17 2019 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Wed, 24 Apr 2019 18:46:17 +1000 Subject: [erlang-questions] Programmers and teachers In-Reply-To: References: Message-ID: I can safely say, if there's a single programmer I've learned the most from, it is Joe Armstrong. His book and especially his papers were a revelation. Will be missed. RIP. - Edmond - On Sun, 21 Apr 2019 06:27:36 +1000, Lloyd R. Prentice wrote: > There are great programmers and great teachers. Joe Armstrong was both. > May we all aspire to as much. > > Thank you, Joe. > > Lloyd > > Sent from my iPad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Using Opera's mail client: http://www.opera.com/mail/ From max.lapshin@REDACTED Wed Apr 24 11:11:37 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 24 Apr 2019 12:11:37 +0300 Subject: [erlang-questions] Skip building wx and other libraries Message-ID: I compile erlang from sources and I want to skip compiling wx, corba and some other applications. Is there any standard way to skip compiling and installing them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemenkov@REDACTED Wed Apr 24 11:14:48 2019 From: lemenkov@REDACTED (Peter Lemenkov) Date: Wed, 24 Apr 2019 11:14:48 +0200 Subject: [erlang-questions] Skip building wx and other libraries In-Reply-To: References: Message-ID: Yes. Just use --without-foo switches. For example ./configure --without-jinterface \ --without-common_test \ --without-debugger \ --without-dialyzer \ --without-et \ --without-megaco \ --without-observer \ --without-reltool \ --without-wx etc. ??, 24 ???. 2019 ?. ? 11:11, Max Lapshin : > > I compile erlang from sources and I want to skip compiling wx, corba and some other applications. > > Is there any standard way to skip compiling and installing them? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- With best regards, Peter Lemenkov. From gerhard@REDACTED Wed Apr 24 11:15:05 2019 From: gerhard@REDACTED (Gerhard Lazu) Date: Wed, 24 Apr 2019 10:15:05 +0100 Subject: [erlang-questions] Skip building wx and other libraries In-Reply-To: References: Message-ID: ./configure --without-x https://github.com/docker-library/rabbitmq/blob/e834da3935ca6cf1030cfd7c9e3b628b6ce883d9/3.8-rc/ubuntu/Dockerfile#L120-L151 On Wed, Apr 24, 2019 at 10:12 AM Max Lapshin wrote: > I compile erlang from sources and I want to skip compiling wx, corba and > some other applications. > > Is there any standard way to skip compiling and installing them? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Wed Apr 24 12:31:20 2019 From: roger@REDACTED (Roger Lipscombe) Date: Wed, 24 Apr 2019 11:31:20 +0100 Subject: [erlang-questions] Skip building wx and other libraries In-Reply-To: References: Message-ID: If you're using kerl (we are), it looks like you can use the KERL_CONFIGURE_DISABLE_APPLICATIONS variable -- https://github.com/kerl/kerl#kerl_configure_disable_applications From henrik.x.nord@REDACTED Wed Apr 24 12:59:10 2019 From: henrik.x.nord@REDACTED (Henrik Nord X) Date: Wed, 24 Apr 2019 10:59:10 +0000 Subject: [erlang-questions] Erlang OTP-22.0-rc3 is available for testing! Message-ID: This is the 3rd release candidate for OTP 22.0 Erlang/OTP 22 is a new major release with new features and improvements as well as incompatibilities. There are no major highlight for this release, as the main focus of this is bugfixes and polish. Please consult the readme for a detailed changelog for the 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. 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-rc3.readme Pre built versions for Windows can be fetched here: http://erlang.org/download/otp_win32_22.0-rc3.exe http://erlang.org/download/otp_win64_22.0-rc3.exe Online documentation can be browsed here: http://erlang.org/documentation/doc-11.0-rc3/doc The Erlang/OTP source can also be found at GitHub on the official Erlang repository: https://github.com/erlang/otp OTP-22.0-rc3 Thank you for all your contributions! -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Thu Apr 25 09:28:17 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Thu, 25 Apr 2019 09:28:17 +0200 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} In-Reply-To: References: <20190412083842.GA84954@erix.ericsson.se> <20190412123835.GA486@erix.ericsson.se> <119A945C-06F6-4E64-893E-9E6108D655F7@gmail.com> <20190417095442.GA62025@erix.ericsson.se> <20190417143603.GA85420@erix.ericsson.se> Message-ID: <20190425072817.GA39414@erix.ericsson.se> On Wed, Apr 24, 2019 at 06:46:27PM +0100, Peter Morgan wrote: > Hi Raimo, > > I am having great difficultly reproducing in a simple test case. Despite best efforts of hundreds of thousands of processes creating timers and retry_state I?ve not managed to reproduce our production issue - with a vanilla OTP21 without your patch. Will let you know if I do. > Can you try my patch on OTP-21 - pull/2211 to see if it works without errors in your original setup? / Raimo > Thanks again for your help on this issue. > > Regards, > Peter. > > > On 17 Apr 2019, at 15:36, Raimo Niskanen wrote: > > > > On Wed, Apr 17, 2019 at 11:54:42AM +0200, Raimo Niskanen wrote: > >> After some discussions with the VM guys this seems to be a bug in > >> gen_statem coming from a misunderstanding of which guarantees that > >> asynchronous timer cancels gives and does not give. > >> > >> The {timeout, Ref, Msg} message may actually come _after_ the > >> {cancel_timer, Ref, false} message. Heavy load seems to increase the > >> probability from almost zero to very small. > >> > >> So the handling of these messages is broken for gen_statem on OTP-21, but > >> this should be fixed on master (soon to be OTP-22) since gen_statem there > >> does not use asynchronous timer cancels. > >> > >> I will look into how big a diff it will be to rewrite gen_statem in OTP-21.latest > >> to use synchronous timer cancel... > > > > The diff became a fat one, so I created a pull request: > > > > https://github.com/erlang/otp/pull/2211 > > > > If you can try it out, that would be awsome! > > > > Best Regards > > / Raimo > > > > > > > >> > >> Thank you for finding a tricky bug! > >> / Raimo > >> > >> > >> > >> On Fri, Apr 12, 2019 at 04:13:27PM +0100, Peter Morgan wrote: > >>> Hi Raimo, > >>> > >>> Thanks for looking at this, and the background on the implementation which is very useful. I am in the process of putting together a simple test case, but having trouble reproducing it. It appears to happen very infrequently - possibly something that is load related? The original output was from the Crash Report which I?ve attached - where you can see the info timeout was received by our gen_statem behaviour callback. Our OTP is 21.2 (without any 21.2.X patches): > >>> > >>> {stdlib,"ERTS CXC 138 10","3.7?} > >>> {kernel,"ERTS CXC 138 10","6.2?} > >>> > >>> > >>> Your question - ?why so many?? - it could be a failure of a downstream service that is ultimately causing this, and we?re not backing off in this case - something that I?m checking too. However, I still thought it was interesting that the info timeout reaches the behaviour module. > >>> > >> > >>> =CRASH REPORT==== 8-Apr-2019::23:37:19.038905 === <0.969.0> proc_lib:crash_report/4:508 > >>> crasher: > >>> initial call: kafire_fetcher:init/1 > >>> pid: <0.969.0> > >>> registered_name: [] > >>> exception error: no function clause matching > >>> kafire_fetcher:handle_event(info, > >>> {timeout, > >>> #Ref<0.2399112782.889192450.118024>, > >>> fetch}, > >>> subsequent_fetches, > >>> our_state) (src/kafire_fetcher.erl, line 445) > >>> in function gen_statem:call_state_function/5 (gen_statem.erl, line 1662) > >>> in call from gen_statem:loop_event_state_function/6 (gen_statem.erl, line 1023) > >>> ancestors: [<0.931.0>,<0.332.0>,kafire_cluster_sup,kafire_sup,<0.227.0>] > >>> message_queue_len: 279 > >>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > >>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > >>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118061>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118062>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118063>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118064>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118068>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118069>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118070>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118071>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118074>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118079>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118081>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118083>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118087>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118088>,0}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118089>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118093>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118094>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118095>,3}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118096>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118097>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118098>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118099>,3}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118103>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118104>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118105>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118106>,3}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118107>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118108>,1}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118109>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118113>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118114>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118115>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118116>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118117>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118118>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118119>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118120>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118121>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118122>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118123>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118124>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118125>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118126>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118127>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118128>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118129>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118130>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118131>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118132>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118133>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118134>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118135>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118136>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118137>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118138>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118139>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118140>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118141>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118145>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118146>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118147>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118148>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118149>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118150>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118151>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118152>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118153>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118154>,5}, > >>> {timeout,#Ref<0.2399112782.889192450.118159>,fetch}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118159>,false}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118165>,0}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118169>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118170>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118173>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118174>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118175>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118176>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118177>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118178>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118179>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118180>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118181>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118182>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118183>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118184>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118185>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118189>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118190>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118191>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118192>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118196>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118197>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118198>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118199>,5}, > >>> {timeout,#Ref<0.2399112782.889192450.118203>,fetch}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118203>,false}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118206>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118207>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118208>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118212>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118213>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118214>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118215>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118221>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118225>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118226>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118227>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118231>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118235>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118236>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118237>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118238>,2}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118242>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118243>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118244>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118248>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118249>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118250>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118254>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118255>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118256>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118260>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118264>,0}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118265>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118266>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118270>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118271>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118272>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118273>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118274>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118278>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118279>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118280>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118281>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118282>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118283>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118287>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118288>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118289>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118290>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118291>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118295>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118296>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118297>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118298>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118299>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118303>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118304>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118305>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118306>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118307>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118308>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118309>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118313>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118314>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118315>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118316>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118317>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118318>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118319>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118323>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118324>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118325>,5}, > >>> {timeout,#Ref<0.2399112782.889192450.118326>,fetch}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118326>,false}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118327>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118328>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118329>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118330>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118331>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118332>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118333>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118337>,3}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118338>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118339>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118340>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118344>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118345>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118346>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118347>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118351>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118352>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118353>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118357>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118358>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118359>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118360>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118364>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118365>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118366>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118367>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118371>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118372>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118373>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118377>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118378>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118379>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118383>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118384>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118385>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118389>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118390>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118391>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118392>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118393>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118394>,0}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118395>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118399>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118400>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118401>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118402>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118403>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118404>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118405>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118409>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118410>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118411>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118412>,1}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118413>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118414>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118415>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118419>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118420>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118421>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118422>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118423>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118424>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118425>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118429>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118430>,0}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118431>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118432>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118433>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118434>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118435>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118439>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118440>,1}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118441>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118442>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118443>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118444>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118445>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118449>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118450>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118451>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118452>,4}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118453>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118454>,5}, > >>> {cancel_timer,#Ref<0.2399112782.889192450.118455>,5}, > >>> {timeout,#Ref<0.2399112782.889192450.118456>,fetch}, > >>> {'EXIT',<0.10080.8>,normal}, > >>> {'EXIT',<0.10079.8>,normal}, > >>> {'EXIT',<0.10081.8>,normal}, > >>> {'EXIT',<0.10082.8>,normal}, > >>> {'EXIT',<0.10083.8>,normal}, > >>> {'EXIT',<0.10084.8>,normal}, > >>> {'EXIT',<0.10085.8>,normal}, > >>> {'EXIT',<0.10086.8>,normal}, > >>> {'EXIT',<0.10087.8>,normal}, > >>> {'EXIT',<0.10088.8>,normal}, > >>> {'EXIT',<0.10089.8>,normal}, > >>> {'EXIT',<0.10071.8>,normal}] > >>> links: [<0.931.0>] > >>> dictionary: [] > >>> trap_exit: true > >>> status: running > >>> heap_size: 17731 > >>> stack_size: 27 > >>> reductions: 28849413204 > >>> neighbours: > >> > >>> > >>> > >>> I?ll try and get a simple test case for you. > >>> Regards, > >>> Peter. > >>> > >>> > >>> > >>>> On 12 Apr 2019, at 13:38, Raimo Niskanen wrote: > >>>> > >>>> On Fri, Apr 12, 2019 at 10:38:42AM +0200, Raimo Niskanen wrote: > >>>>> On Wed, Apr 10, 2019 at 01:41:06PM +0100, Peter Morgan wrote: > >>>>>> Hello - > >>>>>> > >>>>>> We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. > >>>>>> > >>>>>> The crash looks like: > >>>>>> > >>>>>> =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 > >>>>>> ** State machine {kafire_fetcher,<>,<>,0} terminating > >>>>>> ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} > >>>>>> > >>>>>> We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: > >>>>>> > >>>>>> > >>>>>> message_queue_len: 279 > >>>>>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > >>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > >>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > >>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, > >>>>> > >>>>> Is that from a process_info() call? > >>>>> > >>>>>> > >>>>>> Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? > >>>>> > >>>>> It is not supposed to happen. This must be a bug. > >>>>> > >>>>> The gen_statem engine keeps track of the running state_timeout timer > >>>>> and should never present it as an info event. > >>>>> > >>>>> When a timer is stopped (or restarted) it is done with an asynchronous > >>>>> cancel (in OTP 21) so the cancel_timer messages comes from that. > >>>>> They should be matched against map entries in the internal gen_statem > >>>>> engine state when they arrive so them being in the inbox may be ok. > >>>>> > >>>>> However, how come you have so many? Are you restarting the state_timeout > >>>>> in a very tight loop of repeat_state:s? Can you show the essential parts > >>>>> of the code that causes state_timeout:s? > >>>>> > >>>>> Also - OTP-21.2; is that your exact OTP version? What is your stdlib version? > >>>>> > >>>>> I will look at the relevant parts of the code with the new knowledge that > >>>>> a state_timeout timer can be lost, probably in combination with > >>>>> repeat_state and state_timeout restart! > >>>> > >>>> > >>>> Sorry, the knowledge did not help; I did not find anything suspicous. > >>>> > >>>> More information will be needed... > >>>> > >>>>> > >>>>> On master since Jan 21 so in OTP-22.0-rc1 among other changes the timer handling > >>>>> has been rewritten to use a synchronous cancel, which simplified the code > >>>>> significantly. I do not know if that would be worth trying? > >>>>> > >>>>> / Raimo Niskanen > >>>>> > >>>>> > >>>>>> > >>>>>> Thanks > >>>>>> Peter. > >>>>>> > >>>> > >>>> -- > >>>> > >>>> / Raimo Niskanen, Erlang/OTP, Ericsson AB > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>> > >> > >> > >> -- > >> > >> / Raimo Niskanen, Erlang/OTP, Ericsson AB > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From dieter@REDACTED Thu Apr 25 18:04:41 2019 From: dieter@REDACTED (dieter@REDACTED) Date: Thu, 25 Apr 2019 16:04:41 +0000 Subject: [erlang-questions] lexer for IEEE488.2 numbers Message-ID: <76473f3cf7761ad9416bc82d97db70fc@afterlogic.edis.at> Hi all, I am writing a lexer for a SCPI parser. The number format of 488.2 is more tolerant than list_to_float/1, it seems. .123 and 456. are both valid in 488.2, but list_to_float/1 rejects them. I have not yet found an erlang alternative to list_to_float/1, my current approach is to add the omitted zeroes and feed the patched string to list_to_float/1. This works if the number is only a mantissa, but it gets a bit more complicated when there is also an exponent, like 123.e11 my leex expression for the number looks like {MANTISSA}{EXPONENT} : {token, {float, TokenLine, i488tofloat(TokenChars)}}. With this approach, I have to parse the string in my function a second time, which is not elegant at all. Is there a way to have access to the regex macros (or regex groups) on the left side, like 1, 2? I already tried to push back zeroes, but immediately ran into the promised consequences from note 4 on http://erlang.org/doc/man/leex.html (http://erlang.org/doc/man/leex.html), so I quickly left that alley. The question might be heretic, but why is list_to_float so strict? Every calculator allows to omit a leading 0 before the decimal point. Kind regards, Dieter -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Apr 25 23:00:27 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 25 Apr 2019 23:00:27 +0200 Subject: [erlang-questions] ERTS version number for 21.3.5 and 21.3.6 Git Message-ID: It seems that the ERTS version number is the same for both: erts-10.3.4 Am I right? /Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth@REDACTED Fri Apr 26 07:30:12 2019 From: kenneth@REDACTED (Kenneth Lundin) Date: Fri, 26 Apr 2019 07:30:12 +0200 Subject: [erlang-questions] ERTS version number for 21.3.5 and 21.3.6 Git In-Reply-To: References: Message-ID: Yes you are right and it is just as it should be since in 21.3.6 it is only the ssl application that is changed. Kenneth, Erlang/OTP Ericsson On Thu, Apr 25, 2019, 23:00 Frank Muller wrote: > It seems that the ERTS version number is the same for both: erts-10.3.4 > > > Am I right? > > > /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 Fri Apr 26 08:22:57 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Fri, 26 Apr 2019 08:22:57 +0200 Subject: [erlang-questions] Force TLS v1.2 Message-ID: Hi guys I?m trying to connect to a remote SSL server using a filtering Proxy in between. First, I try to establish a normal TCP connection to this local Proxy using the CONNECT word. Second, I upgrade the TCP socket to SSL as in this snippet code: _______________________________ tcp_client() -> {ok, TcpSock} = gen_tcp:connect("local_proxy_f or_traffic_filtering", 12345, [ binary, {active,true}, {packet,0} ]), ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), ? got 200OK ... TcpSocket. ssl_client() -> TcpSocket = tcp_client(), Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, ['tlsv1.2']} ], {ok, Sock} = ssl:connect(TcpSocket, Opts). connect() -> SslSocket = ssl_client(), ok = ssl:send(SslSocket, <<"...some data...">>), ? ok. _______________________________ When i call the ssl:send/2, the remote SSL server (I?ve no control on this server) immediately closes the connection with {error, closed}. Furthermore, the SSL server claims I?m using SSL v1.3 (from the logs we've got). Questions: a. is it the right way to establish an SSL connection via a proxy? b. how can I really ensure I?m using SSL v1.2 and not v1.3? My config: Erlang 21.3.5, Ubuntu 18.04 LTS, Kernel 4.4.0-grs-64 on a very restricted environment: no sudo, no direct internet access /Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Fri Apr 26 08:25:41 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Fri, 26 Apr 2019 08:25:41 +0200 Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: References: Message-ID: Small typo in ssl_client/0: _______________________________ tcp_client() -> {ok, TcpSock} = gen_tcp:connect("local_proxy_for_traffic_fitering", 12345, [ binary, {active, true}, {packet. 0} ]), ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), ? got 200OK ... TcpSocket. ssl_client() -> TcpSocket = tcp_client(), Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, ['tlsv1.2']} ], {ok, Sock} = ssl:connect(TcpSocket, Opts), Sock. connect() -> SslSocket = ssl_client(), ok = ssl:send("...some data...">>, SslSocket), ? ok. _______________________________ Hi guys > > I?m trying to connect to a remote SSL server using a filtering Proxy in > between. > > First, I try to establish a normal TCP connection to this local Proxy > using the CONNECT word. > > Second, I upgrade the TCP socket to SSL as in this snippet code: > > _______________________________ > tcp_client() -> > {ok, TcpSock} = gen_tcp:connect("local_proxy_f > or_traffic_filtering", 12345, [ binary, {active,true}, {packet,0} ]), > > ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), > ? got 200OK ... > TcpSocket. > > ssl_client() -> > TcpSocket = tcp_client(), > Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, > ['tlsv1.2']} ], > {ok, Sock} = ssl:connect(TcpSocket, Opts). > > connect() -> > SslSocket = ssl_client(), > ok = ssl:send(SslSocket, <<"...some data...">>), > ? > ok. > _______________________________ > > When i call the ssl:send/2, the remote SSL server (I?ve no control on this > server) immediately closes the connection with {error, closed}. > > Furthermore, the SSL server claims I?m using SSL v1.3 (from the logs we've > got). > > Questions: > a. is it the right way to establish an SSL connection via a proxy? > > b. how can I really ensure I?m using SSL v1.2 and not v1.3? > > > My config: Erlang 21.3.5, Ubuntu 18.04 LTS, Kernel 4.4.0-grs-64 on a very > restricted environment: no sudo, no direct internet access > > /Frank > -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Fri Apr 26 14:36:45 2019 From: otp@REDACTED (Erlang/OTP) Date: Fri, 26 Apr 2019 14:36:45 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.7 Released Message-ID: <20190426123645.GA31202@erix.ericsson.se> Patch Package: OTP 21.3.7 Git Tag: OTP-21.3.7 Date: 2019-04-26 Trouble Report Id: OTP-15772 Seq num: System: OTP Release: 21 Application: ssh-4.7.6 Predecessor: OTP 21.3.6 Check out the git tag OTP-21.3.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. --------------------------------------------------------------------- --- ssh-4.7.6 ------------------------------------------------------- --------------------------------------------------------------------- The ssh-4.7.6 application can be applied independently of other applications on a full OTP 21 installation. --- Improvements and New Features --- OTP-15772 Application(s): ssh When an SSH server receives the very first message on a new TCP connection, and that message is not the expected one, the 64 first bytes of the received message are now dumped in the INFO REPORT that reports the Protocol Error. This facilitates the debugging of who sends the bad message or of detecting a possible port scanning. Full runtime dependencies of ssh-4.7.6: crypto-4.2, erts-6.0, kernel-3.0, public_key-1.5.2, stdlib-3.3 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From kingwang98@REDACTED Fri Apr 26 15:34:34 2019 From: kingwang98@REDACTED (WW) Date: Fri, 26 Apr 2019 13:34:34 +0000 (UTC) Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: References: Message-ID: <1839429445.816739.1556285674767@mail.yahoo.com> Dialyzer warning if not export my function convert_result_and_exit/1 %%% ###=====================================================================###-spec convert_result_and_exit(any()) -> no_return().%%% ###=====================================================================###convert_result_and_exit({error, ErrReason}) when is_binary(ErrReason)-> exit({error, ErrReason});convert_result_and_exit(no_permission)-> exit(no_permission);convert_result_and_exit(_E) -> exit({error, <<"Unknown reason">>}). got a warning from dialyzer: 1569: The variable _E can never match since previous clauses completely covered the type 'no_permission' | {'error',binary()} Anybody has an explanation why ?? ? Dialyzer? ?bug ? Best regards//KW Best Regards W.W.(KingWang) On Friday, April 26, 2019, 8:26:00 AM GMT+2, Frank Muller wrote: Small typo in ssl_client/0:_______________________________ tcp_client() -> ? ? {ok, TcpSock} = gen_tcp:connect("local_proxy_for_traffic_fitering", 12345, [ binary, {active, true}, {packet. 0} ]), ? ? ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), ? ? ? got 200OK ... ? ? TcpSocket. ssl_client() -> ? TcpSocket = tcp_client(), ? Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, ['tlsv1.2']} ], ? {ok, Sock} = ssl:connect(TcpSocket, Opts),? ?Sock. connect() -> ? ? ? SslSocket = ssl_client(), ? ? ? ok = ssl:send("...some data...">>, SslSocket), ? ? ? ? ? ? ? ok. _______________________________ Hi guys I?m trying to connect to a remote SSL server using a filtering Proxy in between. First, I try to establish a normal TCP connection to this local Proxy using the CONNECT word. Second, I upgrade the TCP socket to SSL as in this snippet code: _______________________________ tcp_client() -> ? ? {ok, TcpSock} = gen_tcp:connect("local_proxy_for_traffic_filtering", 12345, [ binary, {active,true}, {packet,0} ]), ? ? ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), ? ? ? got 200OK ... ? ? TcpSocket. ssl_client() -> ? TcpSocket = tcp_client(), ? Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, ['tlsv1.2']} ], ? {ok, Sock} = ssl:connect(TcpSocket, Opts). connect() -> ? ? ? SslSocket = ssl_client(), ? ? ? ok = ssl:send(SslSocket, <<"...some data...">>),? ? ? ? ? ? ? ok. _______________________________ When i call the ssl:send/2, the remote SSL server (I?ve no control on this server) immediately closes the connection with {error, closed}.? Furthermore, the SSL server claims I?m using SSL v1.3 (from the logs we've got). Questions: a. is it the right way to establish an SSL connection via a proxy? b. how can I really ensure I?m using SSL v1.2 and not v1.3? My config: Erlang 21.3.5, Ubuntu 18.04 LTS, Kernel 4.4.0-grs-64 on a very restricted environment: no sudo, no direct internet access /Frank _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Fri Apr 26 18:49:39 2019 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 26 Apr 2019 17:49:39 +0100 Subject: [erlang-questions] Ctrl+R bug in erl? Message-ID: Steps to reproduce (in OTP-21.0): 1. Run 'erl'. 2. Evaluate an expression, so there's something in the history. 3. Press Ctrl+R to bring up reverse search. 4. At the (search) prompt, press Backspace. 5. Weirdness ensues. Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe] Eshell V10.0 (abort with ^G) 1> 42 + 42. 84 (search)`': 42 + 42.42 + 42.42 + 42.42 + 42.42 + 42. From gerhard@REDACTED Fri Apr 26 18:56:06 2019 From: gerhard@REDACTED (Gerhard Lazu) Date: Fri, 26 Apr 2019 17:56:06 +0100 Subject: [erlang-questions] Ctrl+R bug in erl? In-Reply-To: References: Message-ID: OTP v21.3.5 on macOS Mojave 10.14.4 works as expected for me: Erlang/OTP 21 [erts-10.3.4] [source] [64-bit] [smp:20:20] [ds:20:20:10] [async-threads:1] [hipe] [dtrace] Eshell V10.3.4 (abort with ^G) 1> 42+42. 84 (search)`': 42+42. 2> 42+42. 84 Have you tried a different machine? On Fri, Apr 26, 2019 at 5:50 PM Roger Lipscombe wrote: > Steps to reproduce (in OTP-21.0): > > 1. Run 'erl'. > 2. Evaluate an expression, so there's something in the history. > 3. Press Ctrl+R to bring up reverse search. > 4. At the (search) prompt, press Backspace. > 5. Weirdness ensues. > > Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:12:12] [ds:12:12:10] > [async-threads:1] [hipe] > > Eshell V10.0 (abort with ^G) > 1> 42 + 42. > 84 > (search)`': 42 + 42.42 + 42.42 + 42.42 + 42.42 + 42. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Fri Apr 26 19:04:29 2019 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 26 Apr 2019 18:04:29 +0100 Subject: [erlang-questions] Ctrl+R bug in erl? In-Reply-To: References: Message-ID: On Fri, 26 Apr 2019 at 17:56, Gerhard Lazu wrote: > (search)`': 42+42. At this point, what did you press? Don't enter any text. Just press Backspace a bunch of times. I get another copy of the previous history line appended each time. From hugo@REDACTED Fri Apr 26 19:04:43 2019 From: hugo@REDACTED (Hugo Mills) Date: Fri, 26 Apr 2019 17:04:43 +0000 Subject: [erlang-questions] Ctrl+R bug in erl? In-Reply-To: References: Message-ID: <20190426170443.GQ5426@carfax.org.uk> On Fri, Apr 26, 2019 at 05:49:39PM +0100, Roger Lipscombe wrote: > Steps to reproduce (in OTP-21.0): > > 1. Run 'erl'. > 2. Evaluate an expression, so there's something in the history. > 3. Press Ctrl+R to bring up reverse search. > 4. At the (search) prompt, press Backspace. > 5. Weirdness ensues. > > Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:12:12] [ds:12:12:10] > [async-threads:1] [hipe] > > Eshell V10.0 (abort with ^G) > 1> 42 + 42. > 84 > (search)`': 42 + 42.42 + 42.42 + 42.42 + 42.42 + 42. I get this, too. I'm on Debian, with their packaged version of 21.2.2. It's probably some peculiarity of the termcap (and hence is only fixable by a midnight sacrifice of an aubergine, performed by a team consisting of three holy fools, two consecrated priestesses, and a virgin unicylist). Hugo. -- Hugo Mills | Purrmetheus stole fur from the Dogs, and was chained hugo@REDACTED carfax.org.uk | up for beagles to eat his liver. http://carfax.org.uk/ | PGP: E2AB1DE4 | Rich and Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From dch@REDACTED Fri Apr 26 19:19:38 2019 From: dch@REDACTED (Dave Cottlehuber) Date: Fri, 26 Apr 2019 13:19:38 -0400 Subject: [erlang-questions] Ctrl+R bug in erl? In-Reply-To: <20190426170443.GQ5426@carfax.org.uk> References: <20190426170443.GQ5426@carfax.org.uk> Message-ID: <1945fe7c-c890-4cb1-9f20-21550831ede8@www.fastmail.com> On Fri, 26 Apr 2019, at 19:05, Hugo Mills wrote: > On Fri, Apr 26, 2019 at 05:49:39PM +0100, Roger Lipscombe wrote: > > Steps to reproduce (in OTP-21.0): > > > > 1. Run 'erl'. > > 2. Evaluate an expression, so there's something in the history. > > 3. Press Ctrl+R to bring up reverse search. > > 4. At the (search) prompt, press Backspace. > > 5. Weirdness ensues. > > > > Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:12:12] [ds:12:12:10] > > [async-threads:1] [hipe] > > > > Eshell V10.0 (abort with ^G) > > 1> 42 + 42. > > 84 > > (search)`': 42 + 42.42 + 42.42 + 42.42 + 42.42 + 42. > > I get this, too. I'm on Debian, with their packaged version of > 21.2.2. It's probably some peculiarity of the termcap On FreeBSD 12.0 All using the same system readline I get weirdness on OTP21 and 22 but not OTP19 or OTP20 erts 9.3.3.10. This bug seems rather cosmetic. More like an erts change than a readline or termcap thing? ? Dave Cottlehuber -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard@REDACTED Fri Apr 26 19:19:27 2019 From: gerhard@REDACTED (Gerhard Lazu) Date: Fri, 26 Apr 2019 18:19:27 +0100 Subject: [erlang-questions] Ctrl+R bug in erl? In-Reply-To: References: Message-ID: You are right. I tried again and can confirm the same behaviour as you reported - every backspace repeats the previous command: erl Erlang/OTP 21 [erts-10.3.4] [source] [64-bit] [smp:20:20] [ds:20:20:10] [async-threads:1] [hipe] [dtrace] Eshell V10.3.4 (abort with ^G) 1> 42+42. 84 (search)`': 42+42.42+42.42+42.42+42.42+42.42+42.42+42. Just upgraded to 21.3.6 and still seeing the same incorrect behaviour. On Fri, Apr 26, 2019 at 6:04 PM Roger Lipscombe wrote: > On Fri, 26 Apr 2019 at 17:56, Gerhard Lazu wrote: > > (search)`': 42+42. > > At this point, what did you press? Don't enter any text. Just press > Backspace a bunch of times. I get another copy of the previous history > line appended each time. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From per@REDACTED Fri Apr 26 19:22:02 2019 From: per@REDACTED (Per Hedeland) Date: Fri, 26 Apr 2019 19:22:02 +0200 Subject: [erlang-questions] Ctrl+R bug in erl? In-Reply-To: <20190426170443.GQ5426@carfax.org.uk> References: <20190426170443.GQ5426@carfax.org.uk> Message-ID: <14f1f9e7-7b9f-91a9-3a38-60fdd405514f@hedeland.org> On 2019-04-26 19:04, Hugo Mills wrote: > On Fri, Apr 26, 2019 at 05:49:39PM +0100, Roger Lipscombe wrote: >> Steps to reproduce (in OTP-21.0): >> >> 1. Run 'erl'. >> 2. Evaluate an expression, so there's something in the history. >> 3. Press Ctrl+R to bring up reverse search. >> 4. At the (search) prompt, press Backspace. >> 5. Weirdness ensues. >> >> Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:12:12] [ds:12:12:10] >> [async-threads:1] [hipe] >> >> Eshell V10.0 (abort with ^G) >> 1> 42 + 42. >> 84 >> (search)`': 42 + 42.42 + 42.42 + 42.42 + 42.42 + 42. > > I get this, too. I'm on Debian, with their packaged version of > 21.2.2. Me too, on FreeBSD, with 21.2 built from source. > It's probably some peculiarity of the termcap (and hence is > only fixable by a midnight sacrifice of an aubergine, performed by a > team consisting of three holy fools, two consecrated priestesses, and > a virgin unicylist). :-) Well, it's definitely something related to that, i.e. the resulting display is wrong - but my guess is that it's not a problem with termcap but with how the Erlang shell interprets it (or not). But anyway, in many(/most?) "terminal editing sessions", Ctrl-L will clean up the mess and tell you what the current state of affairs is. Unfortunately it also drops you out of search mode. Of course, you can also just refrain from hitting "backspace" when you don't actually have anything to delete... --Per Hedeland From roger@REDACTED Fri Apr 26 22:35:59 2019 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 26 Apr 2019 21:35:59 +0100 Subject: [erlang-questions] Hang in ssl_connection:call/2 with ranch Message-ID: (OTP-21.0) I'm looking at a deadlock on one of our servers (fortunately only in staging bring-up, so it's not bothering anyone yet). I've got a ranch protocol handler blocked in ranch:accept_ack, waiting for a 'shoot' message. That's never being sent because the ranch_conns_sup process is blocked in ssl:controlling_process -> ssl_connection:new_user -> ssl_connection:call -> gen_statem:call_dirty -> gen:do_call. This is *not* happening on any of our other servers. If I restart the node, it happens again when a client connects. It's also (afaict) only affecting two of the configured ranch listeners; the other two appear to be fine. I've got a crash dump: all I can see is the ranch_conns_sup process is blocking in gen_statem:call_dirty but the receiving process appears (afaict) to be happily sitting in gen_statem:loop_receive, with message_queue_len = 0, so I don't know why the call's not completing. Any ideas? What else can I look at, assuming it continues to happen? (OTP-21.0, ranch 1.3.2) From petergi@REDACTED Sat Apr 27 04:59:38 2019 From: petergi@REDACTED (Peter J Etheridge) Date: Sat, 27 Apr 2019 12:59:38 +1000 Subject: [erlang-questions] erlang-doc ubuntu Message-ID: <8a0ee96e7ffb91978cd4b47d497ab86e979a80a4@webmail.iinet.net.au> Dear Erlangers,I have installed a number of erlang versions and always managed to set up the manual. Lately i installed Ubuntu 18. wx:demo().&erl -man both work. What linux command makes erlang-doc into html ? Thank you in advance.Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Sat Apr 27 10:30:47 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sat, 27 Apr 2019 10:30:47 +0200 Subject: [erlang-questions] lexer for IEEE488.2 numbers In-Reply-To: <76473f3cf7761ad9416bc82d97db70fc@afterlogic.edis.at> References: <76473f3cf7761ad9416bc82d97db70fc@afterlogic.edis.at> Message-ID: On Thu, Apr 25, 2019 at 6:04 PM wrote: > > Hi all, > > I am writing a lexer for a SCPI parser. The number format of 488.2 is more tolerant than > list_to_float/1, it seems. > .123 and 456. are both valid in 488.2, but list_to_float/1 rejects them. > > I have not yet found an erlang alternative to list_to_float/1, > my current approach is to add the omitted zeroes and feed the patched string to list_to_float/1. > > This works if the number is only a mantissa, but > it gets a bit more complicated when there is also an exponent, like 123.e11 > my leex expression for the number looks like > > {MANTISSA}{EXPONENT} : {token, {float, TokenLine, i488tofloat(TokenChars)}}. > > With this approach, I have to parse the string in my function a second time, which is not elegant at all. > > Is there a way to have access to the regex macros (or regex groups) on the left side, like \1, \2? > > I already tried to push back zeroes, but immediately ran into the promised consequences from note 4 on > http://erlang.org/doc/man/leex.html, so I quickly left that alley. > > The question might be heretic, but why is list_to_float so strict? Every calculator allows to omit a leading 0 before the decimal point. list_to_float is there to convert Erlang-style floating-point numbers, not anyone else's, and since Erlang has some restrictions(*) on its floats, that's reflected in this function. This is normal. C's strtoul() for instance can't convert Erlang-style Base#Digits numbers. You have two options: either fix up the string to match Erlang's syntax before passing it to list_to_integer (which is what you're already doing) or write your own stand-alone conversion code. I'd usually do the latter. (*) Apart from syntax Erlang's floats are restricted to "finite" values: infinities and NaNs are not permitted anywhere. I don't approve of this restriction, but it's there. From kostis@REDACTED Sat Apr 27 12:32:18 2019 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 27 Apr 2019 12:32:18 +0200 Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: <1839429445.816739.1556285674767@mail.yahoo.com> References: <1839429445.816739.1556285674767@mail.yahoo.com> Message-ID: On 4/26/19 3:34 PM, WW wrote: > Dialyzer warning if not export my function convert_result_and_exit/1 > > > %%% > ###=====================================================================### > -spec convert_result_and_exit(any()) -> no_return(). > %%% > ###=====================================================================### > convert_result_and_exit({error, ErrReason}) when is_binary(ErrReason)-> > exit({error, ErrReason}); > convert_result_and_exit(no_permission)-> exit(no_permission); > convert_result_and_exit(_E) -> exit({error, <<"Unknown reason">>}). > > > got a warning from dialyzer: > > 1569: The variable _E can never match since previous clauses completely > covered the type 'no_permission' | {'error',binary()} > > Anybody has an explanation why ? Because all calls to convert_result_and_exit/1 are either with an {'error',binary()} tuple or the 'no_permission' atom. Thus, Dialyzer can figure out that the third clause is unreachable and informs you about it. Effectively, it tells you that you have either made a mistake somewhere and you have no call with something other than 'no_permission' | {'error',binary()} or you can remove this clause (comment it out). Once you have done that, perhaps you may also want to strengthen the spec of the function. > Dialyzer? ?bug ? Remember the slogan: "Dialyzer is never wrong!" Kostis From kingwang98@REDACTED Sat Apr 27 12:43:29 2019 From: kingwang98@REDACTED (WW) Date: Sat, 27 Apr 2019 10:43:29 +0000 (UTC) Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: References: <1839429445.816739.1556285674767@mail.yahoo.com> Message-ID: <386493866.1152665.1556361809603@mail.yahoo.com> But according to spec? ?the input of the function can be any()! It is obvious the _E? should be considered, otherwise erlang will crash. Am I wrong?? Best Regards W.W.(KingWang) On Saturday, April 27, 2019, 12:30:21 PM GMT+2, Kostis Sagonas wrote: On 4/26/19 3:34 PM, WW wrote: > Dialyzer warning if not export my function convert_result_and_exit/1 > > > %%% > ###=====================================================================### > -spec convert_result_and_exit(any()) -> no_return(). > %%% > ###=====================================================================### > convert_result_and_exit({error, ErrReason}) when is_binary(ErrReason)-> > exit({error, ErrReason}); > convert_result_and_exit(no_permission)-> exit(no_permission); > convert_result_and_exit(_E) -> exit({error, <<"Unknown reason">>}). > > > got a warning from dialyzer: > > 1569: The variable _E can never match since previous clauses completely > covered the type 'no_permission' | {'error',binary()} > > Anybody has an explanation why ? Because all calls to convert_result_and_exit/1 are either with an {'error',binary()} tuple or the 'no_permission' atom.? Thus, Dialyzer can figure out that the third clause is unreachable and informs you about it. Effectively, it tells you that you have either made a mistake somewhere and you have no call with something other than 'no_permission' | {'error',binary()} or you can remove this clause (comment it out). Once you have done that, perhaps you may also want to strengthen the spec of the function. > Dialyzer? ?bug ? Remember the slogan: "Dialyzer is never wrong!" Kostis _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Sat Apr 27 12:49:50 2019 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 27 Apr 2019 12:49:50 +0200 Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: <386493866.1152665.1556361809603@mail.yahoo.com> References: <1839429445.816739.1556285674767@mail.yahoo.com> <386493866.1152665.1556361809603@mail.yahoo.com> Message-ID: On 4/27/19 12:43 PM, WW wrote: > But according to spec? ?the input of the function can be any()! It is > obvious the _E? should be considered, otherwise erlang will crash. > > Am I wrong? Yes, you are. The function is not exported; all calls to it are from within the module (i.e., known to dialyzer), so they cannot be with any() as argument; they can only be with the term types that dialyzer has inferred. Kostis From kingwang98@REDACTED Sat Apr 27 22:15:10 2019 From: kingwang98@REDACTED (WW) Date: Sat, 27 Apr 2019 20:15:10 +0000 (UTC) Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: References: <1839429445.816739.1556285674767@mail.yahoo.com> <386493866.1152665.1556361809603@mail.yahoo.com> Message-ID: <1597250570.1315373.1556396110482@mail.yahoo.com> Thank you for your answer Kostis. But will erlang crash if any other internal function call this internal function with an argument?of integer() or someother term()? --------------------------------------------------------------------------------------------------------------------------------------------------------------?###=====================================================================### ?-spec convert_result_and_exit(any()) -> no_return(). ?%%%? ?###=====================================================================### convert_result_and_exit({error, ErrReason}) when is_binary(ErrReason)->? exit({error, ErrReason});?convert_result_and_exit(no_permission)-> exit(no_permission). test() ->? ? convert_result_and_exit ( [1,2,3] ).? ? ?( It is a use case , why "so they cannot be with any() as argument" ?? Where in the erlang doc defined that?) In this case, test() will crash owing to missing the?convert_result_and_exit(_E) -> exit({error, <<"Unknown reason">>}).? ?I do not want it crash, I need a quiet exit (catch it afterwards)instead, will that be possible ?---------------------------------------------------------------------------------------------------------------------------------------------------------------- The question is : Why dialyzer could not detect the internal non-exported spec ?? Or Erlang module interal function should not have any spec at all , because dialyzer doesn't care? Is it? the limitation of dialyzer or? wrong in the design? What is the best solution, in my situation? BR//Wei Wang Best Regards W.W.(KingWang) On Saturday, April 27, 2019, 4:52:29 PM GMT+2, Kostis Sagonas wrote: On 4/27/19 12:43 PM, WW wrote: > But according to spec? ?the input of the function can be any()! It is > obvious the _E? should be considered, otherwise erlang will crash. > > Am I wrong? Yes, you are. The function is not exported; all calls to it are from within the module (i.e., known to dialyzer), so they cannot be with any() as argument; they can only be with the term types that dialyzer has inferred. Kostis -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingwang98@REDACTED Sat Apr 27 22:42:07 2019 From: kingwang98@REDACTED (WW) Date: Sat, 27 Apr 2019 20:42:07 +0000 (UTC) Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: <1597250570.1315373.1556396110482@mail.yahoo.com> References: <1839429445.816739.1556285674767@mail.yahoo.com> <386493866.1152665.1556361809603@mail.yahoo.com> <1597250570.1315373.1556396110482@mail.yahoo.com> Message-ID: <1418402431.1329357.1556397727045@mail.yahoo.com> Will it be the only solution that I exported that function even it is not used by outside? Called exported internal function? Best Regards W.W.(KingWang) On Saturday, April 27, 2019, 10:15:10 PM GMT+2, WW wrote: Thank you for your answer Kostis. But will erlang crash if any other internal function call this internal function with an argument?of integer() or someother term()? --------------------------------------------------------------------------------------------------------------------------------------------------------------?###=====================================================================### ?-spec convert_result_and_exit(any()) -> no_return(). ?%%%? ?###=====================================================================### convert_result_and_exit({error, ErrReason}) when is_binary(ErrReason)->? exit({error, ErrReason});?convert_result_and_exit(no_permission)-> exit(no_permission). test() ->? ? convert_result_and_exit ( [1,2,3] ).? ? ?( It is a use case , why "so they cannot be with any() as argument" ?? Where in the erlang doc defined that?) In this case, test() will crash owing to missing the?convert_result_and_exit(_E) -> exit({error, <<"Unknown reason">>}).? ?I do not want it crash, I need a quiet exit (catch it afterwards)instead, will that be possible ?---------------------------------------------------------------------------------------------------------------------------------------------------------------- The question is : Why dialyzer could not detect the internal non-exported spec ?? Or Erlang module interal function should not have any spec at all , because dialyzer doesn't care? Is it? the limitation of dialyzer or? wrong in the design? What is the best solution, in my situation? BR//Wei Wang Best Regards W.W.(KingWang) On Saturday, April 27, 2019, 4:52:29 PM GMT+2, Kostis Sagonas wrote: On 4/27/19 12:43 PM, WW wrote: > But according to spec? ?the input of the function can be any()! It is > obvious the _E? should be considered, otherwise erlang will crash. > > Am I wrong? Yes, you are. The function is not exported; all calls to it are from within the module (i.e., known to dialyzer), so they cannot be with any() as argument; they can only be with the term types that dialyzer has inferred. Kostis -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugo@REDACTED Sat Apr 27 22:52:08 2019 From: hugo@REDACTED (Hugo Mills) Date: Sat, 27 Apr 2019 20:52:08 +0000 Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: <1597250570.1315373.1556396110482@mail.yahoo.com> References: <1839429445.816739.1556285674767@mail.yahoo.com> <386493866.1152665.1556361809603@mail.yahoo.com> <1597250570.1315373.1556396110482@mail.yahoo.com> Message-ID: <20190427205208.GS5426@carfax.org.uk> On Sat, Apr 27, 2019 at 08:15:10PM +0000, WW wrote: > Thank you for your answer Kostis. > But will erlang crash if any other internal function call this internal function with an argument?of integer() or someother term()? The point here is that dialyzer can *prove* that the function will not be called with anything other than the first two cases. It therefore tells you that the third catch-all case is impossible. You can safely remove that third clause. If at some point in the future you write some code which could call the function with some other input, then dialyzer will tell you about that, too. If you want a quiet dialyzer, the solution here is to remove the third (catch-all) clause, until you have some code which actually needs it. Hugo. > --------------------------------------------------------------------------------------------------------------------------------------------------------------?###=====================================================================### > ?-spec convert_result_and_exit(any()) -> no_return(). > ?%%%? > ?###=====================================================================### > convert_result_and_exit({error, ErrReason}) when is_binary(ErrReason)->? > exit({error, ErrReason});?convert_result_and_exit(no_permission)-> exit(no_permission). > > test() ->? ? convert_result_and_exit ( [1,2,3] ).? ? ?( It is a use case , why "so they cannot be with any() as argument" ?? Where in the erlang doc defined that?) > > In this case, test() will crash owing to missing the?convert_result_and_exit(_E) -> exit({error, <<"Unknown reason">>}).? ?I do not want it crash, I need a quiet exit (catch it afterwards)instead, will that be possible ?---------------------------------------------------------------------------------------------------------------------------------------------------------------- > The question is : Why dialyzer could not detect the internal non-exported spec ?? Or Erlang module interal function should not have any spec at all , because dialyzer doesn't care? > Is it? the limitation of dialyzer or? wrong in the design? What is the best solution, in my situation? > BR//Wei Wang > Best Regards W.W.(KingWang) > > On Saturday, April 27, 2019, 4:52:29 PM GMT+2, Kostis Sagonas wrote: > > On 4/27/19 12:43 PM, WW wrote: > > But according to spec? ?the input of the function can be any()! It is > > obvious the _E? should be considered, otherwise erlang will crash. > > > > Am I wrong? > > Yes, you are. > > The function is not exported; all calls to it are from within the module > (i.e., known to dialyzer), so they cannot be with any() as argument; > they can only be with the term types that dialyzer has inferred. > > Kostis > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Hugo Mills | You can get more with a kind word and a two-by-four hugo@REDACTED carfax.org.uk | than you can with just a kind word. http://carfax.org.uk/ | PGP: E2AB1DE4 | Marcus Cole, Babylon 5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From kingwang98@REDACTED Sun Apr 28 01:30:02 2019 From: kingwang98@REDACTED (WW) Date: Sat, 27 Apr 2019 23:30:02 +0000 (UTC) Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: <20190427205208.GS5426@carfax.org.uk> References: <1839429445.816739.1556285674767@mail.yahoo.com> <386493866.1152665.1556361809603@mail.yahoo.com> <1597250570.1315373.1556396110482@mail.yahoo.com> <20190427205208.GS5426@carfax.org.uk> Message-ID: <2015745796.1295117.1556407802944@mail.yahoo.com> The problem is that I have already a internal function call that (any())? case Best Regards W.W.(KingWang) On Saturday, April 27, 2019, 10:52:11 PM GMT+2, Hugo Mills wrote: On Sat, Apr 27, 2019 at 08:15:10PM +0000, WW wrote: > Thank you for your answer Kostis. > But will erlang crash if any other internal function call this internal function with an argument?of integer() or someother term()? ? The point here is that dialyzer can *prove* that the function will not be called with anything other than the first two cases. It therefore tells you that the third catch-all case is impossible. You can safely remove that third clause. ? If at some point in the future you write some code which could call the function with some other input, then dialyzer will tell you about that, too. ? If you want a quiet dialyzer, the solution here is to remove the third (catch-all) clause, until you have some code which actually needs it. ? Hugo. > --------------------------------------------------------------------------------------------------------------------------------------------------------------?###=====================================================================### > ?-spec convert_result_and_exit(any()) -> no_return(). > ?%%%? > ?###=====================================================================### > convert_result_and_exit({error, ErrReason}) when is_binary(ErrReason)->? > exit({error, ErrReason});?convert_result_and_exit(no_permission)-> exit(no_permission). > > test() ->? ? convert_result_and_exit ( [1,2,3] ).? ? ?( It is a use case , why "so they cannot be with any() as argument" ?? Where in the erlang doc defined that?) > > In this case, test() will crash owing to missing the?convert_result_and_exit(_E) -> exit({error, <<"Unknown reason">>}).? ?I do not want it crash, I need a quiet exit (catch it afterwards)instead, will that be possible ?---------------------------------------------------------------------------------------------------------------------------------------------------------------- > The question is : Why dialyzer could not detect the internal non-exported spec ?? Or Erlang module interal function should not have any spec at all , because dialyzer doesn't care? > Is it? the limitation of dialyzer or? wrong in the design? What is the best solution, in my situation? > BR//Wei Wang > Best Regards W.W.(KingWang) > >? ? On Saturday, April 27, 2019, 4:52:29 PM GMT+2, Kostis Sagonas wrote:? >? >? On 4/27/19 12:43 PM, WW wrote: > > But according to spec? ?the input of the function can be any()! It is > > obvious the _E? should be considered, otherwise erlang will crash. > > > > Am I wrong? > > Yes, you are. > > The function is not exported; all calls to it are from within the module > (i.e., known to dialyzer), so they cannot be with any() as argument; > they can only be with the term types that dialyzer has inferred. > > Kostis >? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Hugo Mills? ? ? ? ? ? | You can get more with a kind word and a two-by-four hugo@REDACTED carfax.org.uk | than you can with just a kind word. http://carfax.org.uk/ | PGP: E2AB1DE4? ? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Marcus Cole, Babylon 5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Sun Apr 28 07:48:21 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Sun, 28 Apr 2019 07:48:21 +0200 Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: <20190427205208.GS5426@carfax.org.uk> References: <1839429445.816739.1556285674767@mail.yahoo.com> <386493866.1152665.1556361809603@mail.yahoo.com> <1597250570.1315373.1556396110482@mail.yahoo.com> <20190427205208.GS5426@carfax.org.uk> Message-ID: Hey guys Why this thread is about Dialyzer? I created it because a TLS issue i had (see my original post). Thank you. /Frank > On Sat, Apr 27, 2019 at 08:15:10PM +0000, WW wrote: > > Thank you for your answer Kostis. > > But will erlang crash if any other internal function call this internal > function with an argument of integer() or someother term()? > > The point here is that dialyzer can *prove* that the function will > not be called with anything other than the first two cases. It > therefore tells you that the third catch-all case is impossible. You > can safely remove that third clause. > > If at some point in the future you write some code which could call > the function with some other input, then dialyzer will tell you about > that, too. > > If you want a quiet dialyzer, the solution here is to remove the > third (catch-all) clause, until you have some code which actually > needs it. > > Hugo. > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------- ###=====================================================================### > > -spec convert_result_and_exit(any()) -> no_return(). > > %%% > > > ###=====================================================================### > > convert_result_and_exit({error, ErrReason}) when is_binary(ErrReason)-> > > exit({error, ErrReason}); convert_result_and_exit(no_permission)-> > exit(no_permission). > > > > test() -> convert_result_and_exit ( [1,2,3] ). ( It is a use case > , why "so they cannot be with any() as argument" ? Where in the erlang doc > defined that?) > > > > In this case, test() will crash owing to missing > the convert_result_and_exit(_E) -> exit({error, <<"Unknown reason">>}). I > do not want it crash, I need a quiet exit (catch it afterwards)instead, > will that be possible > ?---------------------------------------------------------------------------------------------------------------------------------------------------------------- > > The question is : Why dialyzer could not detect the internal > non-exported spec ? Or Erlang module interal function should not have any > spec at all , because dialyzer doesn't care? > > Is it the limitation of dialyzer or wrong in the design? What is the > best solution, in my situation? > > BR//Wei Wang > > Best Regards W.W.(KingWang) > > > > On Saturday, April 27, 2019, 4:52:29 PM GMT+2, Kostis Sagonas < > kostis@REDACTED> wrote: > > > > On 4/27/19 12:43 PM, WW wrote: > > > But according to spec the input of the function can be any()! It is > > > obvious the _E should be considered, otherwise erlang will crash. > > > > > > Am I wrong? > > > > Yes, you are. > > > > The function is not exported; all calls to it are from within the module > > (i.e., known to dialyzer), so they cannot be with any() as argument; > > they can only be with the term types that dialyzer has inferred. > > > > Kostis > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > Hugo Mills | You can get more with a kind word and a > two-by-four > hugo@REDACTED carfax.org.uk | than you can with just a kind word. > http://carfax.org.uk/ | > PGP: E2AB1DE4 | Marcus Cole, > Babylon 5 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingwang98@REDACTED Sun Apr 28 18:41:44 2019 From: kingwang98@REDACTED (WW) Date: Sun, 28 Apr 2019 16:41:44 +0000 (UTC) Subject: [erlang-questions] Erlang dialyzer warnings for internal functions. References: <1438388483.1489307.1556469704226.ref@mail.yahoo.com> Message-ID: <1438388483.1489307.1556469704226@mail.yahoo.com> Sorry for disturbing Frank! Now the new thread for discussion of dialyzer issues .......... Hi guys I have moved dialyzer discussions on this thread, so we can continue here! Code example =======================================================-module(helloworld). -export([start/0]). %%-export([validator/1]). start()-> ?? ?try ?? ??? ?validator(undefined), ?? ??? ?validator([]), ?? ??? ?validator(3) ?? ?catch ?? ? ??? ?exit:Reason-> ?? ? ??? ??? ?{error, Reason}?? ? ?? ?end. %%%###=======================================================================### -spec validator(X::any())->no_return(). %%%###=======================================================================###?? ????? ? validator([])-> exit({error, "empty list"});?? ??????? ? ?? ?????? ? validator(undefined) -> exit({error, undefined}); validator(_Any)-> exit({error,"unknown"}). =========================================================================================When function in module validator/1 is not exported, dialyzer gives warnings.?Checking whether the PLT /home/eweiwan/.dialyzer_plt is up-to-date... yes ? Proceeding with analysis... helloworld.erl:18: The pattern [] can never match the type 'undefined' helloworld.erl:24: The variable _Any can never match since previous clauses completely covered the type 'undefined' ?done in 0m1.45s done (warnings were emitted)?? <<<<<<<<<<<<<<<<<<<<<<<<<< ------------------------------------------------------------------------------------------------------------------------------------------------- When function is exported, dialyzer result : ?Checking whether the PLT /home/eweiwan/.dialyzer_plt is up-to-date... yes ? Proceeding with analysis... done in 0m1.55s done (passed successfully)??? <<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------------------------------------------------------------------------------------------------------------------------------------------- What is the best solution to avoid dialyzer warnings meanwhile also satisfy my use cases.? Thank you BR//Wei -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Sun Apr 28 21:32:04 2019 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 28 Apr 2019 21:32:04 +0200 Subject: [erlang-questions] Erlang dialyzer warnings for internal functions. In-Reply-To: <1438388483.1489307.1556469704226@mail.yahoo.com> References: <1438388483.1489307.1556469704226.ref@mail.yahoo.com> <1438388483.1489307.1556469704226@mail.yahoo.com> Message-ID: On 4/28/19 6:41 PM, WW wrote: > > What is the best solution to avoid dialyzer warnings meanwhile also > satisfy my use cases.? > One cannot really answer this question without knowing what your "use case(s)" really is.,,, If it really is the code example you posted, if you pay close attention to the warning that you get from dialyzer, dialyzer also tells you that the call validator([]), let alone validator(3), is actually unreachable code in your example. This is because dialyzer discovers that the prior call (validator(undefined)) will throw an exit exception and control-flow will never reach the validator([]) (and validator(3)) calls. Once again, remember the slogan: "Dialyzer is never wrong." Kostis From kingwang98@REDACTED Sun Apr 28 22:38:13 2019 From: kingwang98@REDACTED (WW) Date: Sun, 28 Apr 2019 20:38:13 +0000 (UTC) Subject: [erlang-questions] Erlang dialyzer warnings for internal functions. In-Reply-To: References: <1438388483.1489307.1556469704226.ref@mail.yahoo.com> <1438388483.1489307.1556469704226@mail.yahoo.com> Message-ID: <250506048.1505067.1556483893889@mail.yahoo.com> Why dialyzer did not complain when? I? exported the function validator/1 ? It means exported function allowing never reach the calls ? On Sunday, April 28, 2019, 9:30:03 PM GMT+2, Kostis Sagonas wrote: On 4/28/19 6:41 PM, WW wrote: > > What is the best solution to avoid dialyzer warnings meanwhile also > satisfy my use cases.? > One cannot really answer this question without knowing what your "use case(s)" really is.,,, If it really is the code example you posted, if you pay close attention to the warning that you get from dialyzer, dialyzer also tells you that the call validator([]), let alone validator(3), is actually unreachable code in your example.? This is because dialyzer discovers that the prior call (validator(undefined)) will throw an exit exception and control-flow will never reach the validator([]) (and validator(3)) calls. Once again, remember the slogan: "Dialyzer is never wrong." Kostis -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre@REDACTED Sun Apr 28 22:59:34 2019 From: andre@REDACTED (Andre Nathan) Date: Sun, 28 Apr 2019 17:59:34 -0300 Subject: [erlang-questions] Adding a NIF to prim_file Message-ID: <0c379c78-c2a5-fcf4-bc1a-6a0116b1fe0f@digirati.com.br> Hi I'm trying to figure out how to add a NIF to the prim_file module. To try to get it working, I'm just trying to add an existing function under a different name: In prim_file_nif.c I added the lines below: WRAP_FILE_HANDLE_EXPORT(my_truncate_nif) static ErlNifFunc nif_funcs[] = { ... {"my_truncate_nif", 1, my_truncate_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, ... }; Then I copied truncate_nif_impl and renamed the copy to my_truncate_nif_impl. In prim_file.erl I copied the truncate function, renamed the copy to my_truncate and changed it to call my_truncate_nif instead of truncate_nif. Then I added my_truncate_nif(_FileRef) -> erlang:nif_error(undef). However, when I try to build OTP, I get this error: (no logger present) unexpected logger message: {log,error,"Error in process ~p with exit value:~n~p~n",[<0.0.0>,{{badmatch,{error,{bad_lib,"Function not found prim_file:my_truncate_nif/1"}}},[{prim_file,on_load,0,[]},{erl_init,start,2,[]}]}],#{error_logger=>#{emulator=>true,tag=>error},gl=><0.0.0>,pid=><0.0.0>,time=>1556484838271817}} Is there anything else I have to do to allow the new function to be detected? I couldn't find any other references to truncate_nif that I could replicate. The full diff is pasted below. Thanks, Andre diff --git a/erts/emulator/nifs/common/prim_file_nif.c b/erts/emulator/nifs/common/prim_file_nif.c index 3df04e42e2..61a9b70679 100644 --- a/erts/emulator/nifs/common/prim_file_nif.c +++ b/erts/emulator/nifs/common/prim_file_nif.c @@ -162,6 +162,7 @@ WRAP_FILE_HANDLE_EXPORT(allocate_nif) WRAP_FILE_HANDLE_EXPORT(advise_nif) WRAP_FILE_HANDLE_EXPORT(get_handle_nif) WRAP_FILE_HANDLE_EXPORT(ipread_s32bu_p32bu_nif) +WRAP_FILE_HANDLE_EXPORT(my_truncate_nif) static ErlNifFunc nif_funcs[] = { /* File handle ops */ @@ -174,6 +175,7 @@ static ErlNifFunc nif_funcs[] = { {"seek_nif", 3, seek_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, {"sync_nif", 2, sync_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, {"truncate_nif", 1, truncate_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, + {"my_truncate_nif", 1, my_truncate_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, {"allocate_nif", 3, allocate_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, {"advise_nif", 4, advise_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, @@ -721,6 +723,16 @@ static ERL_NIF_TERM sync_nif_impl(efile_data_t *d, ErlNifEnv *env, int argc, con return am_ok; } +static ERL_NIF_TERM my_truncate_nif_impl(efile_data_t *d, ErlNifEnv *env, int argc, const ERL_NIF_TERM argv[]) { + ASSERT(argc == 0); + + if(!efile_truncate(d)) { + return posix_error_to_tuple(env, d->posix_errno); + } + + return am_ok; +} + static ERL_NIF_TERM truncate_nif_impl(efile_data_t *d, ErlNifEnv *env, int argc, const ERL_NIF_TERM argv[]) { ASSERT(argc == 0); diff --git a/erts/preloaded/src/prim_file.erl b/erts/preloaded/src/prim_file.erl index 1aa5d85c64..e350cd9a19 100644 --- a/erts/preloaded/src/prim_file.erl +++ b/erts/preloaded/src/prim_file.erl @@ -22,7 +22,7 @@ -export([on_load/0]). -export([open/2, close/1, - sync/1, datasync/1, truncate/1, advise/4, allocate/3, + sync/1, datasync/1, truncate/1, my_truncate/1, advise/4, allocate/3, read_line/1, read/2, write/2, position/2, pread/2, pread/3, pwrite/2, pwrite/3]). @@ -242,6 +242,15 @@ truncate(Fd) -> error:badarg -> {error, badarg} end. +my_truncate(Fd) -> + try + #{ handle := FRef } = get_fd_data(Fd), + reset_write_position(Fd), + my_truncate_nif(FRef) + catch + error:badarg -> {error, badarg} + end. + advise(Fd, Offset, Length, Advise) -> try #{ handle := FRef } = get_fd_data(Fd), @@ -493,6 +502,8 @@ allocate_nif(_FileRef, _Offset, _Length) -> erlang:nif_error(undef). truncate_nif(_FileRef) -> erlang:nif_error(undef). +my_truncate_nif(_FileRef) -> + erlang:nif_error(undef). get_handle_nif(_FileRef) -> erlang:nif_error(undef). delayed_close_nif(_FileRef) -> From g@REDACTED Sun Apr 28 23:19:13 2019 From: g@REDACTED (Guilherme Andrade) Date: Sun, 28 Apr 2019 22:19:13 +0100 Subject: [erlang-questions] Erlang dialyzer warnings for internal functions. In-Reply-To: <250506048.1505067.1556483893889@mail.yahoo.com> References: <1438388483.1489307.1556469704226.ref@mail.yahoo.com> <1438388483.1489307.1556469704226@mail.yahoo.com> <250506048.1505067.1556483893889@mail.yahoo.com> Message-ID: Hello Wei, On Sun, 28 Apr 2019 at 21:38, WW wrote: > Why dialyzer did not complain when I exported the function validator/1 ? > > It means exported function allowing never reach the calls ? > Because when you export said function, Dialyzer can't assume it won't be called from code outside its analysis scope (e.g. modules in uncovered apps, modules loaded in runtime, function references generated in run time, the shell, ..) and so it can't determine the full range of possible arguments - anything goes. And if anything goes, there's no way of saying: "this particular execution flow will never happen." Which is usually not the case with internal functions, where all possible calling arguments /may/ be known when performing analysis, depending on your code and how precisely Dialyzer can track type constraints in it. > > > On Sunday, April 28, 2019, 9:30:03 PM GMT+2, Kostis Sagonas < > kostis@REDACTED> wrote: > > > On 4/28/19 6:41 PM, WW wrote: > > > > > What is the best solution to avoid dialyzer warnings meanwhile also > > satisfy my use cases.? > > > > > One cannot really answer this question without knowing what your "use > case(s)" really is.,,, > > If it really is the code example you posted, if you pay close attention > to the warning that you get from dialyzer, dialyzer also tells you that > the call validator([]), let alone validator(3), is actually unreachable > code in your example. This is because dialyzer discovers that the prior > call (validator(undefined)) will throw an exit exception and > control-flow will never reach the validator([]) (and validator(3)) calls. > > Once again, remember the slogan: "Dialyzer is never wrong." > > Kostis > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Guilherme -------------- next part -------------- An HTML attachment was scrubbed... URL: From prakash.parmar@REDACTED Mon Apr 29 08:23:37 2019 From: prakash.parmar@REDACTED (Prakash Parmar) Date: Mon, 29 Apr 2019 06:23:37 +0000 Subject: [erlang-questions] Static Map ( Keys known at compile time ) Message-ID: Hello All, Does Erlang supports Static Maps ? Something like, All possible Keys of Map has to be define at compile time and Can not be added/deleted dynamically. In a project we have a record with ~50 element and their fields will be accessed/Modified multiple times through out the Business Logic flow. Though we are not storing it in Mnesia. Does replacing Record with Map will be better option in terms of performance ? The primary thing we want is Static Map. No one should add/delete Keys in Map. Is it Possible ? Thanks, Prakash -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Mon Apr 29 08:29:36 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Mon, 29 Apr 2019 08:29:36 +0200 Subject: [erlang-questions] Static Map ( Keys known at compile time ) In-Reply-To: References: Message-ID: http://erlang.org/doc/man/persistent_term.html /Frank Hello All, > > Does Erlang supports Static Maps ? Something like, All possible Keys of > Map has to be define at compile time and Can not be added/deleted > dynamically. > > In a project we have a record with ~50 element and their fields will be > accessed/Modified multiple times through out the Business Logic flow. > Though we are not storing it in Mnesia. Does replacing Record with Map will > be better option in terms of performance ? > > The primary thing we want is Static Map. No one should add/delete Keys in > Map. Is it Possible ? > > Thanks, > Prakash > > _______________________________________________ > 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 Mon Apr 29 08:30:52 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Mon, 29 Apr 2019 08:30:52 +0200 Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: References: Message-ID: Help please!!! Small typo in ssl_client/0: > _______________________________ > tcp_client() -> > {ok, TcpSock} = gen_tcp:connect("local_proxy_for_traffic_fitering", > 12345, [ binary, {active, true}, {packet. 0} ]), > ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), > ? got 200OK ... > TcpSocket. > > ssl_client() -> > TcpSocket = tcp_client(), > Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, > ['tlsv1.2']} ], > {ok, Sock} = ssl:connect(TcpSocket, Opts), > Sock. > > connect() -> > SslSocket = ssl_client(), > ok = ssl:send("...some data...">>, SslSocket), > ? > ok. > _______________________________ > > > Hi guys >> >> I?m trying to connect to a remote SSL server using a filtering Proxy in >> between. >> >> First, I try to establish a normal TCP connection to this local Proxy >> using the CONNECT word. >> >> Second, I upgrade the TCP socket to SSL as in this snippet code: >> >> _______________________________ >> tcp_client() -> >> {ok, TcpSock} = gen_tcp:connect("local_proxy_f >> or_traffic_filtering", 12345, [ binary, {active,true}, {packet,0} ]), >> >> ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), >> ? got 200OK ... >> TcpSocket. >> >> ssl_client() -> >> TcpSocket = tcp_client(), >> Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, >> ['tlsv1.2']} ], >> {ok, Sock} = ssl:connect(TcpSocket, Opts). >> >> connect() -> >> SslSocket = ssl_client(), >> ok = ssl:send(SslSocket, <<"...some data...">>), >> ? >> ok. >> _______________________________ >> >> When i call the ssl:send/2, the remote SSL server (I?ve no control on >> this server) immediately closes the connection with {error, closed}. >> >> Furthermore, the SSL server claims I?m using SSL v1.3 (from the logs >> we've got). >> >> Questions: >> a. is it the right way to establish an SSL connection via a proxy? >> >> b. how can I really ensure I?m using SSL v1.2 and not v1.3? >> >> >> My config: Erlang 21.3.5, Ubuntu 18.04 LTS, Kernel 4.4.0-grs-64 on a very >> restricted environment: no sudo, no direct internet access >> >> /Frank >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Mon Apr 29 08:40:41 2019 From: john@REDACTED (John =?ISO-8859-1?Q?H=F6gberg?=) Date: Mon, 29 Apr 2019 08:40:41 +0200 Subject: [erlang-questions] Adding a NIF to prim_file In-Reply-To: <0c379c78-c2a5-fcf4-bc1a-6a0116b1fe0f@digirati.com.br> References: <0c379c78-c2a5-fcf4-bc1a-6a0116b1fe0f@digirati.com.br> Message-ID: <89f074c527ed95ee5478ef8293d1b1344e95ac78.camel@erlang.org> Hi, `prim_file` is a prebuilt module that's statically embedded into the emulator, and the emulator crashes if there are any problems initializing it. In this case you've added a function to the NIF but haven't yet rebuilt the module, so it crashes when trying to inject the non-existent `my_truncate_nif/1`. To update these prebuilt modules, you need to run: ./otp_build update_preloaded --no-commit Try doing this on a clean build without changes to the NIF (C code), and then rebuild the emulator with the changes applied. Note that you will need to rebuild the emulator every time you update the preloaded modules for the changes to take effect. Hope that helps! Regards, John H?gberg On Sun, 2019-04-28 at 17:59 -0300, Andre Nathan wrote: > Hi > > I'm trying to figure out how to add a NIF to the prim_file module. > To > try to get it working, I'm just trying to add an existing function > under > a different name: > > In prim_file_nif.c I added the lines below: > > WRAP_FILE_HANDLE_EXPORT(my_truncate_nif) > > static ErlNifFunc nif_funcs[] = { > ... > {"my_truncate_nif", 1, my_truncate_nif, > ERL_NIF_DIRTY_JOB_IO_BOUND}, > ... > }; > > Then I copied truncate_nif_impl and renamed the copy to > my_truncate_nif_impl. > > > In prim_file.erl I copied the truncate function, renamed the copy to > my_truncate and changed it to call my_truncate_nif instead of > truncate_nif. Then I added > > my_truncate_nif(_FileRef) -> > erlang:nif_error(undef). > > However, when I try to build OTP, I get this error: > > (no logger present) unexpected logger message: {log,error,"Error in > process ~p with exit > value:~n~p~n",[<0.0.0>,{{badmatch,{error,{bad_lib,"Function not > found > prim_file:my_truncate_nif/1"}}},[{prim_file,on_load,0,[]},{erl_init,s > tart,2,[]}]}],#{error_logger=>#{emulator=>true,tag=>error},gl=><0.0.0 > >,pid=><0.0.0>,time=>1556484838271817}} > > Is there anything else I have to do to allow the new function to be > detected? I couldn't find any other references to truncate_nif that > I > could replicate. > > The full diff is pasted below. > > Thanks, > Andre > > > diff --git a/erts/emulator/nifs/common/prim_file_nif.c > b/erts/emulator/nifs/common/prim_file_nif.c > index 3df04e42e2..61a9b70679 100644 > --- a/erts/emulator/nifs/common/prim_file_nif.c > +++ b/erts/emulator/nifs/common/prim_file_nif.c > @@ -162,6 +162,7 @@ WRAP_FILE_HANDLE_EXPORT(allocate_nif) > WRAP_FILE_HANDLE_EXPORT(advise_nif) > WRAP_FILE_HANDLE_EXPORT(get_handle_nif) > WRAP_FILE_HANDLE_EXPORT(ipread_s32bu_p32bu_nif) > +WRAP_FILE_HANDLE_EXPORT(my_truncate_nif) > > static ErlNifFunc nif_funcs[] = { > /* File handle ops */ > @@ -174,6 +175,7 @@ static ErlNifFunc nif_funcs[] = { > {"seek_nif", 3, seek_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, > {"sync_nif", 2, sync_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, > {"truncate_nif", 1, truncate_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, > + {"my_truncate_nif", 1, my_truncate_nif, > ERL_NIF_DIRTY_JOB_IO_BOUND}, > {"allocate_nif", 3, allocate_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, > {"advise_nif", 4, advise_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, > > @@ -721,6 +723,16 @@ static ERL_NIF_TERM sync_nif_impl(efile_data_t > *d, > ErlNifEnv *env, int argc, con > return am_ok; > } > > +static ERL_NIF_TERM my_truncate_nif_impl(efile_data_t *d, ErlNifEnv > *env, int argc, const ERL_NIF_TERM argv[]) { > + ASSERT(argc == 0); > + > + if(!efile_truncate(d)) { > + return posix_error_to_tuple(env, d->posix_errno); > + } > + > + return am_ok; > +} > + > static ERL_NIF_TERM truncate_nif_impl(efile_data_t *d, ErlNifEnv > *env, > int argc, const ERL_NIF_TERM argv[]) { > ASSERT(argc == 0); > > diff --git a/erts/preloaded/src/prim_file.erl > b/erts/preloaded/src/prim_file.erl > index 1aa5d85c64..e350cd9a19 100644 > --- a/erts/preloaded/src/prim_file.erl > +++ b/erts/preloaded/src/prim_file.erl > @@ -22,7 +22,7 @@ > -export([on_load/0]). > > -export([open/2, close/1, > - sync/1, datasync/1, truncate/1, advise/4, allocate/3, > + sync/1, datasync/1, truncate/1, my_truncate/1, advise/4, > allocate/3, > read_line/1, read/2, write/2, position/2, > pread/2, pread/3, pwrite/2, pwrite/3]). > > > @@ -242,6 +242,15 @@ truncate(Fd) -> > error:badarg -> {error, badarg} > end. > > +my_truncate(Fd) -> > + try > + #{ handle := FRef } = get_fd_data(Fd), > + reset_write_position(Fd), > + my_truncate_nif(FRef) > + catch > + error:badarg -> {error, badarg} > + end. > + > advise(Fd, Offset, Length, Advise) -> > try > #{ handle := FRef } = get_fd_data(Fd), > @@ -493,6 +502,8 @@ allocate_nif(_FileRef, _Offset, _Length) -> > erlang:nif_error(undef). > truncate_nif(_FileRef) -> > erlang:nif_error(undef). > +my_truncate_nif(_FileRef) -> > + erlang:nif_error(undef). > get_handle_nif(_FileRef) -> > erlang:nif_error(undef). > delayed_close_nif(_FileRef) -> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From andreas.schultz@REDACTED Mon Apr 29 08:41:40 2019 From: andreas.schultz@REDACTED (Andreas Schultz) Date: Mon, 29 Apr 2019 08:41:40 +0200 Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: References: Message-ID: Hi Frank, Sorry, that I can't really help you, but I did notice that the Erlang SSL usage example for upgrading a socket to TLS [1] says: *> Step 5:* Ensure active is set to false before trying to upgrade a connection to an SSL connection, otherwise SSL handshake messages can be delivered to the wrong process Your example seems to be using an active connection. Maybe you could post a more complete, ready to run sample to get more feedback... Regards Andreas 1: http://erlang.org/doc/apps/ssl/using_ssl.html Am Fr., 26. Apr. 2019 um 08:25 Uhr schrieb Frank Muller < frank.muller.erl@REDACTED>: > Small typo in ssl_client/0: > _______________________________ > tcp_client() -> > {ok, TcpSock} = gen_tcp:connect("local_proxy_for_traffic_fitering", > 12345, [ binary, {active, true}, {packet. 0} ]), > ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), > ? got 200OK ... > TcpSocket. > > ssl_client() -> > TcpSocket = tcp_client(), > Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, > ['tlsv1.2']} ], > {ok, Sock} = ssl:connect(TcpSocket, Opts), > Sock. > > connect() -> > SslSocket = ssl_client(), > ok = ssl:send("...some data...">>, SslSocket), > ? > ok. > _______________________________ > > > Hi guys >> >> I?m trying to connect to a remote SSL server using a filtering Proxy in >> between. >> >> First, I try to establish a normal TCP connection to this local Proxy >> using the CONNECT word. >> >> Second, I upgrade the TCP socket to SSL as in this snippet code: >> >> _______________________________ >> tcp_client() -> >> {ok, TcpSock} = gen_tcp:connect("local_proxy_f >> or_traffic_filtering", 12345, [ binary, {active,true}, {packet,0} ]), >> >> ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), >> ? got 200OK ... >> TcpSocket. >> >> ssl_client() -> >> TcpSocket = tcp_client(), >> Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, >> ['tlsv1.2']} ], >> {ok, Sock} = ssl:connect(TcpSocket, Opts). >> >> connect() -> >> SslSocket = ssl_client(), >> ok = ssl:send(SslSocket, <<"...some data...">>), >> ? >> ok. >> _______________________________ >> >> When i call the ssl:send/2, the remote SSL server (I?ve no control on >> this server) immediately closes the connection with {error, closed}. >> >> Furthermore, the SSL server claims I?m using SSL v1.3 (from the logs >> we've got). >> >> Questions: >> a. is it the right way to establish an SSL connection via a proxy? >> >> b. how can I really ensure I?m using SSL v1.2 and not v1.3? >> >> >> My config: Erlang 21.3.5, Ubuntu 18.04 LTS, Kernel 4.4.0-grs-64 on a very >> restricted environment: no sudo, no direct internet access >> >> /Frank >> > _______________________________________________ > 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 Mon Apr 29 08:41:55 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Mon, 29 Apr 2019 08:41:55 +0200 Subject: [erlang-questions] Static Map ( Keys known at compile time ) In-Reply-To: References: Message-ID: Mochiglobal: http://erlang.org/pipermail/erlang-questions/2012-May/066892.html http://erlang.org/doc/man/persistent_term.html > > /Frank > > Hello All, >> >> Does Erlang supports Static Maps ? Something like, All possible Keys of >> Map has to be define at compile time and Can not be added/deleted >> dynamically. >> >> In a project we have a record with ~50 element and their fields will be >> accessed/Modified multiple times through out the Business Logic flow. >> Though we are not storing it in Mnesia. Does replacing Record with Map will >> be better option in terms of performance ? >> >> The primary thing we want is Static Map. No one should add/delete Keys in >> Map. Is it Possible ? >> >> Thanks, >> Prakash >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingwang98@REDACTED Mon Apr 29 09:00:29 2019 From: kingwang98@REDACTED (WW) Date: Mon, 29 Apr 2019 07:00:29 +0000 (UTC) Subject: [erlang-questions] Erlang dialyzer warnings for internal functions. In-Reply-To: References: <1438388483.1489307.1556469704226.ref@mail.yahoo.com> <1438388483.1489307.1556469704226@mail.yahoo.com> <250506048.1505067.1556483893889@mail.yahoo.com> Message-ID: <1953665683.1686212.1556521229747@mail.yahoo.com> Thank you, Guilhenrme! Here is my conclusion: For internal function call, we need actually implement to cover all cases specified in the function (missing implementation dialyzer will give warning), however, when exporting that function, dialyzer??can't determine the full range of possible arguments, so it will not give warning.? solution:? 1) Export that function.????????????? ? 2) Switch off? thedialyzer warning for that function:?-dialyzer({nowarn_function, validator/1}). Best regards //Wei. W On Sunday, April 28, 2019, 11:19:26 PM GMT+2, Guilherme Andrade wrote: Hello Wei, On Sun, 28 Apr 2019 at 21:38, WW wrote: Why dialyzer did not complain when? I? exported the function validator/1 ? It means exported function allowing never reach the calls ? Because when you export said function, Dialyzer can't assume it won't be called from code outside its analysis scope (e.g. modules in uncovered apps, modules loaded in runtime, function references generated in run time, the shell, ..) and so it can't determine the full range of possible arguments - anything goes. And if anything goes, there's no way of saying: "this particular execution flow will never happen." Which is usually not the case with internal functions, where all possible calling arguments /may/ be known when performing analysis, depending on your code and how precisely Dialyzer can track type constraints in it. ? On Sunday, April 28, 2019, 9:30:03 PM GMT+2, Kostis Sagonas wrote: On 4/28/19 6:41 PM, WW wrote: > > What is the best solution to avoid dialyzer warnings meanwhile also > satisfy my use cases.? > One cannot really answer this question without knowing what your "use case(s)" really is.,,, If it really is the code example you posted, if you pay close attention to the warning that you get from dialyzer, dialyzer also tells you that the call validator([]), let alone validator(3), is actually unreachable code in your example.? This is because dialyzer discovers that the prior call (validator(undefined)) will throw an exit exception and control-flow will never reach the validator([]) (and validator(3)) calls. Once again, remember the slogan: "Dialyzer is never wrong." Kostis _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- Guilherme -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessvegas@REDACTED Mon Apr 29 10:21:33 2019 From: chessvegas@REDACTED (DOBRO) Date: Mon, 29 Apr 2019 11:21:33 +0300 Subject: [erlang-questions] Equal binaries with different integers Message-ID: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Apr 29 10:28:51 2019 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 29 Apr 2019 09:28:51 +0100 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> Message-ID: <47ed796f-78ce-814d-5dc9-bc9594d5ce88@llaisdy.com> > 24930 rem 256. 98 On 29/04/2019 09:21, DOBRO wrote: > <<24930>> =:= <<98>>. -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Ymchwil a Datblygu Technoleg Lleferydd Speech Technology Research and Development ivan@REDACTED @llaisdy llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From mikpelinux@REDACTED Mon Apr 29 10:29:24 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Mon, 29 Apr 2019 10:29:24 +0200 Subject: [erlang-questions] Static Map ( Keys known at compile time ) In-Reply-To: References: Message-ID: On Mon, Apr 29, 2019 at 8:23 AM Prakash Parmar wrote: > > Hello All, > > Does Erlang supports Static Maps ? Something like, All possible Keys of Map has to be define at compile time and Can not be added/deleted dynamically. > > In a project we have a record with ~50 element and their fields will be accessed/Modified multiple times through out the Business Logic flow. Though we are not storing it in Mnesia. Does replacing Record with Map will be better option in terms of performance ? That depends. In principle a record is faster because the field-to-index mapping is a compile-time constant, so all you're left with at runtime are element and setelement calls, which are O(1). A map OTOH has a dynamic key set so must indirect through a hash to search tree. For smaller mappings a record should always win. However, your records are quite large, and you state that they're updated multiple times. While lookups (element calls) are as fast as can be, updates are O(size(Tuple)). Past some point, it becomes more efficient to split the tuple into chunks to reduce update costs, at the expense of slightly higher lookup costs. What's optimal depends very much on the job mix and the HW it's running on. So for these large mappings, maps may very well be faster. You'll need to measure on your own job mix. From bob@REDACTED Mon Apr 29 10:31:38 2019 From: bob@REDACTED (Bob Ippolito) Date: Mon, 29 Apr 2019 01:31:38 -0700 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> Message-ID: It's possible because the default size for an integer in bit syntax is 8. 1> 24930 rem 256 =:= 98. true For further explanation of this behavior you can take a look at this section of the documentation: http://erlang.org/doc/programming_examples/bit_syntax.html#Defaults -bob On Mon, Apr 29, 2019 at 1:27 AM DOBRO wrote: > Hi, > could anyone explain me how is it possible? > > In shell: > > 1> <<24930>> =:= <<98>>. > true > > > I'm using OTP-21.3.7. > > _______________________________________________ > 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 Mon Apr 29 11:35:51 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Mon, 29 Apr 2019 11:35:51 +0200 Subject: [erlang-questions] Force TLS v1.2 In-Reply-To: References: Message-ID: Hi Andreas Thanks for pointing out that. I just tried with {active,false} but nothing changed. The connection is closed immediately. Any other hint? /Frank Hi Frank, > > Sorry, that I can't really help you, but I did notice that the Erlang SSL > usage example for upgrading a socket to TLS [1] says: > > *> Step 5:* Ensure active is set to false before trying to upgrade a > connection to an SSL connection, otherwise SSL handshake messages can be > delivered to the wrong process > > Your example seems to be using an active connection. > > Maybe you could post a more complete, ready to run sample to get more > feedback... > > Regards > Andreas > > 1: http://erlang.org/doc/apps/ssl/using_ssl.html > > Am Fr., 26. Apr. 2019 um 08:25 Uhr schrieb Frank Muller < > frank.muller.erl@REDACTED>: > >> Small typo in ssl_client/0: >> _______________________________ >> tcp_client() -> >> {ok, TcpSock} = gen_tcp:connect("local_proxy_for_traffic_fitering", >> 12345, [ binary, {active, true}, {packet. 0} ]), >> ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), >> ? got 200OK ... >> TcpSocket. >> >> ssl_client() -> >> TcpSocket = tcp_client(), >> Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, >> ['tlsv1.2']} ], >> {ok, Sock} = ssl:connect(TcpSocket, Opts), >> Sock. >> >> connect() -> >> SslSocket = ssl_client(), >> ok = ssl:send("...some data...">>, SslSocket), >> ? >> ok. >> _______________________________ >> >> >> Hi guys >>> >>> I?m trying to connect to a remote SSL server using a filtering Proxy in >>> between. >>> >>> First, I try to establish a normal TCP connection to this local Proxy >>> using the CONNECT word. >>> >>> Second, I upgrade the TCP socket to SSL as in this snippet code: >>> >>> _______________________________ >>> tcp_client() -> >>> {ok, TcpSock} = gen_tcp:connect("local_proxy_f >>> or_traffic_filtering", 12345, [ binary, {active,true}, {packet,0} ]), >>> >>> ok = gen_tcp:send(TcpSocket, <<"CONNECT?">>), >>> ? got 200OK ... >>> TcpSocket. >>> >>> ssl_client() -> >>> TcpSocket = tcp_client(), >>> Opts = [ {verify, verify_none}, {cacertfile, "cacert.pem"}, {versions, >>> ['tlsv1.2']} ], >>> {ok, Sock} = ssl:connect(TcpSocket, Opts). >>> >>> connect() -> >>> SslSocket = ssl_client(), >>> ok = ssl:send(SslSocket, <<"...some data...">>), >>> ? >>> ok. >>> _______________________________ >>> >>> When i call the ssl:send/2, the remote SSL server (I?ve no control on >>> this server) immediately closes the connection with {error, closed}. >>> >>> Furthermore, the SSL server claims I?m using SSL v1.3 (from the logs >>> we've got). >>> >>> Questions: >>> a. is it the right way to establish an SSL connection via a proxy? >>> >>> b. how can I really ensure I?m using SSL v1.2 and not v1.3? >>> >>> >>> My config: Erlang 21.3.5, Ubuntu 18.04 LTS, Kernel 4.4.0-grs-64 on a >>> very restricted environment: no sudo, no direct internet access >>> >>> /Frank >>> >> _______________________________________________ > > >> 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 raoknz@REDACTED Mon Apr 29 12:31:49 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Mon, 29 Apr 2019 22:31:49 +1200 Subject: [erlang-questions] Static Map ( Keys known at compile time ) In-Reply-To: References: Message-ID: It's not clear to me why you would have a record with 50 fields. Imagine for a moment that Erlang's record declaration syntax were generalised slightly: '-' 'record' '(' ',' ')' '.' where = '{' ( | )+',' '}' = ['=' ] The generalisation here is allowing s as well as s inside s. A nested group would be a nested tuple with no element reserved for a tag. So -record(foo, {{a,b},{c,d}}). means that a typical instance would look like {foo,{A,B},{C,D}}. The time to fetch a field would be proportional to the number of groups it is in; the time to replace it would be proportional to the sum of the sizes of the groups it is. Put nested fields into groups that are commonly read or written together, and you trade a small increase in read time for a large decrease in write time, with automatic economisation in pattern matching, but needing special attention from the compiler to fully economise updates. That would be a nice extension of Erlang records, letting you make performance tradeoffs just by adding and removing curly braces with no change to code elsewhere. Unless/until that's implemented, do it manually. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.james.morgan@REDACTED Mon Apr 29 12:49:18 2019 From: peter.james.morgan@REDACTED (Peter Morgan) Date: Mon, 29 Apr 2019 11:49:18 +0100 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} In-Reply-To: <20190425072817.GA39414@erix.ericsson.se> References: <20190412083842.GA84954@erix.ericsson.se> <20190412123835.GA486@erix.ericsson.se> <119A945C-06F6-4E64-893E-9E6108D655F7@gmail.com> <20190417095442.GA62025@erix.ericsson.se> <20190417143603.GA85420@erix.ericsson.se> <20190425072817.GA39414@erix.ericsson.se> Message-ID: Hi Raimo, I?ve tried your patch and it hasn?t caused any errors. We are still having problems reproducing the issue, but it at least doesn?t look to have caused any side effects. Regards, Peter. > On 25 Apr 2019, at 08:28, Raimo Niskanen wrote: > > On Wed, Apr 24, 2019 at 06:46:27PM +0100, Peter Morgan wrote: >> Hi Raimo, >> >> I am having great difficultly reproducing in a simple test case. Despite best efforts of hundreds of thousands of processes creating timers and retry_state I?ve not managed to reproduce our production issue - with a vanilla OTP21 without your patch. Will let you know if I do. >> > > Can you try my patch on OTP-21 - pull/2211 to see if it works without > errors in your original setup? > > / Raimo > > > >> Thanks again for your help on this issue. >> >> Regards, >> Peter. >> >>> On 17 Apr 2019, at 15:36, Raimo Niskanen wrote: >>> >>> On Wed, Apr 17, 2019 at 11:54:42AM +0200, Raimo Niskanen wrote: >>>> After some discussions with the VM guys this seems to be a bug in >>>> gen_statem coming from a misunderstanding of which guarantees that >>>> asynchronous timer cancels gives and does not give. >>>> >>>> The {timeout, Ref, Msg} message may actually come _after_ the >>>> {cancel_timer, Ref, false} message. Heavy load seems to increase the >>>> probability from almost zero to very small. >>>> >>>> So the handling of these messages is broken for gen_statem on OTP-21, but >>>> this should be fixed on master (soon to be OTP-22) since gen_statem there >>>> does not use asynchronous timer cancels. >>>> >>>> I will look into how big a diff it will be to rewrite gen_statem in OTP-21.latest >>>> to use synchronous timer cancel... >>> >>> The diff became a fat one, so I created a pull request: >>> >>> https://github.com/erlang/otp/pull/2211 > >>> >>> If you can try it out, that would be awsome! >>> >>> Best Regards >>> / Raimo >>> >>> >>> >>>> >>>> Thank you for finding a tricky bug! >>>> / Raimo >>>> >>>> >>>> >>>> On Fri, Apr 12, 2019 at 04:13:27PM +0100, Peter Morgan wrote: >>>>> Hi Raimo, >>>>> >>>>> Thanks for looking at this, and the background on the implementation which is very useful. I am in the process of putting together a simple test case, but having trouble reproducing it. It appears to happen very infrequently - possibly something that is load related? The original output was from the Crash Report which I?ve attached - where you can see the info timeout was received by our gen_statem behaviour callback. Our OTP is 21.2 (without any 21.2.X patches): >>>>> >>>>> {stdlib,"ERTS CXC 138 10","3.7?} >>>>> {kernel,"ERTS CXC 138 10","6.2?} >>>>> >>>>> >>>>> Your question - ?why so many?? - it could be a failure of a downstream service that is ultimately causing this, and we?re not backing off in this case - something that I?m checking too. However, I still thought it was interesting that the info timeout reaches the behaviour module. >>>>> >>>> >>>>> =CRASH REPORT==== 8-Apr-2019::23:37:19.038905 === <0.969.0> proc_lib:crash_report/4:508 >>>>> crasher: >>>>> initial call: kafire_fetcher:init/1 >>>>> pid: <0.969.0> >>>>> registered_name: [] >>>>> exception error: no function clause matching >>>>> kafire_fetcher:handle_event(info, >>>>> {timeout, >>>>> #Ref<0.2399112782.889192450.118024>, >>>>> fetch}, >>>>> subsequent_fetches, >>>>> our_state) (src/kafire_fetcher.erl, line 445) >>>>> in function gen_statem:call_state_function/5 (gen_statem.erl, line 1662) >>>>> in call from gen_statem:loop_event_state_function/6 (gen_statem.erl, line 1023) >>>>> ancestors: [<0.931.0>,<0.332.0>,kafire_cluster_sup,kafire_sup,<0.227.0>] >>>>> message_queue_len: 279 >>>>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, >>>>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, >>>>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118061>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118062>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118063>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118064>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118068>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118069>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118070>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118071>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118074>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118079>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118081>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118083>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118087>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118088>,0}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118089>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118093>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118094>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118095>,3}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118096>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118097>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118098>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118099>,3}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118103>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118104>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118105>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118106>,3}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118107>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118108>,1}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118109>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118113>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118114>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118115>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118116>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118117>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118118>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118119>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118120>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118121>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118122>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118123>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118124>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118125>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118126>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118127>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118128>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118129>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118130>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118131>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118132>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118133>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118134>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118135>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118136>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118137>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118138>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118139>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118140>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118141>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118145>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118146>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118147>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118148>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118149>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118150>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118151>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118152>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118153>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118154>,5}, >>>>> {timeout,#Ref<0.2399112782.889192450.118159>,fetch}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118159>,false}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118165>,0}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118169>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118170>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118173>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118174>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118175>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118176>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118177>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118178>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118179>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118180>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118181>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118182>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118183>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118184>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118185>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118189>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118190>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118191>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118192>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118196>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118197>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118198>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118199>,5}, >>>>> {timeout,#Ref<0.2399112782.889192450.118203>,fetch}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118203>,false}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118206>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118207>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118208>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118212>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118213>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118214>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118215>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118221>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118225>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118226>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118227>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118231>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118235>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118236>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118237>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118238>,2}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118242>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118243>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118244>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118248>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118249>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118250>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118254>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118255>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118256>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118260>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118264>,0}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118265>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118266>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118270>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118271>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118272>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118273>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118274>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118278>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118279>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118280>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118281>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118282>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118283>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118287>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118288>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118289>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118290>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118291>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118295>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118296>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118297>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118298>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118299>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118303>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118304>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118305>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118306>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118307>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118308>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118309>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118313>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118314>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118315>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118316>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118317>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118318>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118319>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118323>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118324>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118325>,5}, >>>>> {timeout,#Ref<0.2399112782.889192450.118326>,fetch}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118326>,false}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118327>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118328>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118329>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118330>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118331>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118332>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118333>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118337>,3}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118338>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118339>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118340>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118344>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118345>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118346>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118347>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118351>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118352>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118353>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118357>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118358>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118359>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118360>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118364>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118365>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118366>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118367>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118371>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118372>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118373>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118377>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118378>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118379>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118383>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118384>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118385>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118389>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118390>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118391>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118392>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118393>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118394>,0}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118395>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118399>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118400>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118401>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118402>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118403>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118404>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118405>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118409>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118410>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118411>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118412>,1}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118413>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118414>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118415>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118419>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118420>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118421>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118422>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118423>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118424>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118425>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118429>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118430>,0}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118431>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118432>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118433>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118434>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118435>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118439>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118440>,1}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118441>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118442>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118443>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118444>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118445>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118449>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118450>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118451>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118452>,4}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118453>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118454>,5}, >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118455>,5}, >>>>> {timeout,#Ref<0.2399112782.889192450.118456>,fetch}, >>>>> {'EXIT',<0.10080.8>,normal}, >>>>> {'EXIT',<0.10079.8>,normal}, >>>>> {'EXIT',<0.10081.8>,normal}, >>>>> {'EXIT',<0.10082.8>,normal}, >>>>> {'EXIT',<0.10083.8>,normal}, >>>>> {'EXIT',<0.10084.8>,normal}, >>>>> {'EXIT',<0.10085.8>,normal}, >>>>> {'EXIT',<0.10086.8>,normal}, >>>>> {'EXIT',<0.10087.8>,normal}, >>>>> {'EXIT',<0.10088.8>,normal}, >>>>> {'EXIT',<0.10089.8>,normal}, >>>>> {'EXIT',<0.10071.8>,normal}] >>>>> links: [<0.931.0>] >>>>> dictionary: [] >>>>> trap_exit: true >>>>> status: running >>>>> heap_size: 17731 >>>>> stack_size: 27 >>>>> reductions: 28849413204 >>>>> neighbours: >>>> >>>>> >>>>> >>>>> I?ll try and get a simple test case for you. >>>>> Regards, >>>>> Peter. >>>>> >>>>> >>>>> >>>>>> On 12 Apr 2019, at 13:38, Raimo Niskanen wrote: >>>>>> >>>>>> On Fri, Apr 12, 2019 at 10:38:42AM +0200, Raimo Niskanen wrote: >>>>>>> On Wed, Apr 10, 2019 at 01:41:06PM +0100, Peter Morgan wrote: >>>>>>>> Hello - >>>>>>>> >>>>>>>> We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. >>>>>>>> >>>>>>>> The crash looks like: >>>>>>>> >>>>>>>> =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 >>>>>>>> ** State machine {kafire_fetcher,<>,<>,0} terminating >>>>>>>> ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} >>>>>>>> >>>>>>>> We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: >>>>>>>> >>>>>>>> >>>>>>>> message_queue_len: 279 >>>>>>>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, >>>>>>> >>>>>>> Is that from a process_info() call? >>>>>>> >>>>>>>> >>>>>>>> Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? >>>>>>> >>>>>>> It is not supposed to happen. This must be a bug. >>>>>>> >>>>>>> The gen_statem engine keeps track of the running state_timeout timer >>>>>>> and should never present it as an info event. >>>>>>> >>>>>>> When a timer is stopped (or restarted) it is done with an asynchronous >>>>>>> cancel (in OTP 21) so the cancel_timer messages comes from that. >>>>>>> They should be matched against map entries in the internal gen_statem >>>>>>> engine state when they arrive so them being in the inbox may be ok. >>>>>>> >>>>>>> However, how come you have so many? Are you restarting the state_timeout >>>>>>> in a very tight loop of repeat_state:s? Can you show the essential parts >>>>>>> of the code that causes state_timeout:s? >>>>>>> >>>>>>> Also - OTP-21.2; is that your exact OTP version? What is your stdlib version? >>>>>>> >>>>>>> I will look at the relevant parts of the code with the new knowledge that >>>>>>> a state_timeout timer can be lost, probably in combination with >>>>>>> repeat_state and state_timeout restart! >>>>>> >>>>>> >>>>>> Sorry, the knowledge did not help; I did not find anything suspicous. >>>>>> >>>>>> More information will be needed... >>>>>> >>>>>>> >>>>>>> On master since Jan 21 so in OTP-22.0-rc1 among other changes the timer handling >>>>>>> has been rewritten to use a synchronous cancel, which simplified the code >>>>>>> significantly. I do not know if that would be worth trying? >>>>>>> >>>>>>> / Raimo Niskanen >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Peter. >>>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> / Raimo Niskanen, Erlang/OTP, Ericsson AB >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> >>>> >>>> -- >>>> >>>> / Raimo Niskanen, Erlang/OTP, Ericsson AB >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> -- >>> >>> / Raimo Niskanen, Erlang/OTP, Ericsson AB >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Mon Apr 29 14:40:42 2019 From: roger@REDACTED (Roger Lipscombe) Date: Mon, 29 Apr 2019 13:40:42 +0100 Subject: [erlang-questions] Hang in ssl_connection:call/2 with ranch In-Reply-To: References: Message-ID: I found the underlying problem: the cert/key files are busted: <<"\n">>. The failure mode is ... surprising, though. On Fri, 26 Apr 2019 at 21:35, Roger Lipscombe wrote: > > (OTP-21.0) > > I'm looking at a deadlock on one of our servers (fortunately only in > staging bring-up, so it's not bothering anyone yet). > > I've got a ranch protocol handler blocked in ranch:accept_ack, waiting > for a 'shoot' message. That's never being sent because the > ranch_conns_sup process is blocked in ssl:controlling_process -> > ssl_connection:new_user -> ssl_connection:call -> > gen_statem:call_dirty -> gen:do_call. > > This is *not* happening on any of our other servers. If I restart the > node, it happens again when a client connects. > > It's also (afaict) only affecting two of the configured ranch > listeners; the other two appear to be fine. > > I've got a crash dump: all I can see is the ranch_conns_sup process is > blocking in gen_statem:call_dirty but the receiving process appears > (afaict) to be happily sitting in gen_statem:loop_receive, with > message_queue_len = 0, so I don't know why the call's not completing. > > Any ideas? What else can I look at, assuming it continues to happen? > > (OTP-21.0, ranch 1.3.2) From essen@REDACTED Mon Apr 29 14:48:08 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Mon, 29 Apr 2019 14:48:08 +0200 Subject: [erlang-questions] Hang in ssl_connection:call/2 with ranch In-Reply-To: References: Message-ID: <5af0536d-f163-0aa2-5357-242e2fb2928a@ninenines.eu> Hey, It was solved in 21.1: https://bugs.erlang.org/browse/ERL-664 Cheers, On 29/04/2019 14:40, Roger Lipscombe wrote: > I found the underlying problem: the cert/key files are busted: <<"\n">>. > > The failure mode is ... surprising, though. > > On Fri, 26 Apr 2019 at 21:35, Roger Lipscombe wrote: >> >> (OTP-21.0) >> >> I'm looking at a deadlock on one of our servers (fortunately only in >> staging bring-up, so it's not bothering anyone yet). >> >> I've got a ranch protocol handler blocked in ranch:accept_ack, waiting >> for a 'shoot' message. That's never being sent because the >> ranch_conns_sup process is blocked in ssl:controlling_process -> >> ssl_connection:new_user -> ssl_connection:call -> >> gen_statem:call_dirty -> gen:do_call. >> >> This is *not* happening on any of our other servers. If I restart the >> node, it happens again when a client connects. >> >> It's also (afaict) only affecting two of the configured ranch >> listeners; the other two appear to be fine. >> >> I've got a crash dump: all I can see is the ranch_conns_sup process is >> blocking in gen_statem:call_dirty but the receiving process appears >> (afaict) to be happily sitting in gen_statem:loop_receive, with >> message_queue_len = 0, so I don't know why the call's not completing. >> >> Any ideas? What else can I look at, assuming it continues to happen? >> >> (OTP-21.0, ranch 1.3.2) > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin https://ninenines.eu From roger@REDACTED Mon Apr 29 14:50:42 2019 From: roger@REDACTED (Roger Lipscombe) Date: Mon, 29 Apr 2019 13:50:42 +0100 Subject: [erlang-questions] Hang in ssl_connection:call/2 with ranch In-Reply-To: <5af0536d-f163-0aa2-5357-242e2fb2928a@ninenines.eu> References: <5af0536d-f163-0aa2-5357-242e2fb2928a@ninenines.eu> Message-ID: Thanks. I'll get us upgraded. On Mon, 29 Apr 2019 at 13:47, Lo?c Hoguin wrote: > > Hey, > > It was solved in 21.1: https://bugs.erlang.org/browse/ERL-664 > > Cheers, > > On 29/04/2019 14:40, Roger Lipscombe wrote: > > I found the underlying problem: the cert/key files are busted: <<"\n">>. > > > > The failure mode is ... surprising, though. > > > > On Fri, 26 Apr 2019 at 21:35, Roger Lipscombe wrote: > >> > >> (OTP-21.0) > >> > >> I'm looking at a deadlock on one of our servers (fortunately only in > >> staging bring-up, so it's not bothering anyone yet). > >> > >> I've got a ranch protocol handler blocked in ranch:accept_ack, waiting > >> for a 'shoot' message. That's never being sent because the > >> ranch_conns_sup process is blocked in ssl:controlling_process -> > >> ssl_connection:new_user -> ssl_connection:call -> > >> gen_statem:call_dirty -> gen:do_call. > >> > >> This is *not* happening on any of our other servers. If I restart the > >> node, it happens again when a client connects. > >> > >> It's also (afaict) only affecting two of the configured ranch > >> listeners; the other two appear to be fine. > >> > >> I've got a crash dump: all I can see is the ranch_conns_sup process is > >> blocking in gen_statem:call_dirty but the receiving process appears > >> (afaict) to be happily sitting in gen_statem:loop_receive, with > >> message_queue_len = 0, so I don't know why the call's not completing. > >> > >> Any ideas? What else can I look at, assuming it continues to happen? > >> > >> (OTP-21.0, ranch 1.3.2) > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Lo?c Hoguin > https://ninenines.eu From andre@REDACTED Mon Apr 29 15:23:31 2019 From: andre@REDACTED (Andre Nathan) Date: Mon, 29 Apr 2019 10:23:31 -0300 Subject: [erlang-questions] Adding a NIF to prim_file In-Reply-To: <89f074c527ed95ee5478ef8293d1b1344e95ac78.camel@erlang.org> References: <0c379c78-c2a5-fcf4-bc1a-6a0116b1fe0f@digirati.com.br> <89f074c527ed95ee5478ef8293d1b1344e95ac78.camel@erlang.org> Message-ID: <1824d3a0-9d54-e97d-7221-32ded0e5bec2@digirati.com.br> That worked, thanks! On 4/29/19 3:40 AM, John H?gberg wrote: > Hi, > > `prim_file` is a prebuilt module that's statically embedded into the > emulator, and the emulator crashes if there are any problems > initializing it. In this case you've added a function to the NIF but > haven't yet rebuilt the module, so it crashes when trying to inject the > non-existent `my_truncate_nif/1`. > > To update these prebuilt modules, you need to run: > > ./otp_build update_preloaded --no-commit > > Try doing this on a clean build without changes to the NIF (C code), > and then rebuild the emulator with the changes applied. Note that you > will need to rebuild the emulator every time you update the preloaded > modules for the changes to take effect. > > Hope that helps! > > Regards, > John H?gberg > > On Sun, 2019-04-28 at 17:59 -0300, Andre Nathan wrote: >> Hi >> >> I'm trying to figure out how to add a NIF to the prim_file module. >> To >> try to get it working, I'm just trying to add an existing function >> under >> a different name: >> >> In prim_file_nif.c I added the lines below: >> >> WRAP_FILE_HANDLE_EXPORT(my_truncate_nif) >> >> static ErlNifFunc nif_funcs[] = { >> ... >> {"my_truncate_nif", 1, my_truncate_nif, >> ERL_NIF_DIRTY_JOB_IO_BOUND}, >> ... >> }; >> >> Then I copied truncate_nif_impl and renamed the copy to >> my_truncate_nif_impl. >> >> >> In prim_file.erl I copied the truncate function, renamed the copy to >> my_truncate and changed it to call my_truncate_nif instead of >> truncate_nif. Then I added >> >> my_truncate_nif(_FileRef) -> >> erlang:nif_error(undef). >> >> However, when I try to build OTP, I get this error: >> >> (no logger present) unexpected logger message: {log,error,"Error in >> process ~p with exit >> value:~n~p~n",[<0.0.0>,{{badmatch,{error,{bad_lib,"Function not >> found >> prim_file:my_truncate_nif/1"}}},[{prim_file,on_load,0,[]},{erl_init,s >> tart,2,[]}]}],#{error_logger=>#{emulator=>true,tag=>error},gl=><0.0.0 >>> ,pid=><0.0.0>,time=>1556484838271817}} >> >> Is there anything else I have to do to allow the new function to be >> detected? I couldn't find any other references to truncate_nif that >> I >> could replicate. >> >> The full diff is pasted below. >> >> Thanks, >> Andre >> >> >> diff --git a/erts/emulator/nifs/common/prim_file_nif.c >> b/erts/emulator/nifs/common/prim_file_nif.c >> index 3df04e42e2..61a9b70679 100644 >> --- a/erts/emulator/nifs/common/prim_file_nif.c >> +++ b/erts/emulator/nifs/common/prim_file_nif.c >> @@ -162,6 +162,7 @@ WRAP_FILE_HANDLE_EXPORT(allocate_nif) >> WRAP_FILE_HANDLE_EXPORT(advise_nif) >> WRAP_FILE_HANDLE_EXPORT(get_handle_nif) >> WRAP_FILE_HANDLE_EXPORT(ipread_s32bu_p32bu_nif) >> +WRAP_FILE_HANDLE_EXPORT(my_truncate_nif) >> >> static ErlNifFunc nif_funcs[] = { >> /* File handle ops */ >> @@ -174,6 +175,7 @@ static ErlNifFunc nif_funcs[] = { >> {"seek_nif", 3, seek_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, >> {"sync_nif", 2, sync_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, >> {"truncate_nif", 1, truncate_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, >> + {"my_truncate_nif", 1, my_truncate_nif, >> ERL_NIF_DIRTY_JOB_IO_BOUND}, >> {"allocate_nif", 3, allocate_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, >> {"advise_nif", 4, advise_nif, ERL_NIF_DIRTY_JOB_IO_BOUND}, >> >> @@ -721,6 +723,16 @@ static ERL_NIF_TERM sync_nif_impl(efile_data_t >> *d, >> ErlNifEnv *env, int argc, con >> return am_ok; >> } >> >> +static ERL_NIF_TERM my_truncate_nif_impl(efile_data_t *d, ErlNifEnv >> *env, int argc, const ERL_NIF_TERM argv[]) { >> + ASSERT(argc == 0); >> + >> + if(!efile_truncate(d)) { >> + return posix_error_to_tuple(env, d->posix_errno); >> + } >> + >> + return am_ok; >> +} >> + >> static ERL_NIF_TERM truncate_nif_impl(efile_data_t *d, ErlNifEnv >> *env, >> int argc, const ERL_NIF_TERM argv[]) { >> ASSERT(argc == 0); >> >> diff --git a/erts/preloaded/src/prim_file.erl >> b/erts/preloaded/src/prim_file.erl >> index 1aa5d85c64..e350cd9a19 100644 >> --- a/erts/preloaded/src/prim_file.erl >> +++ b/erts/preloaded/src/prim_file.erl >> @@ -22,7 +22,7 @@ >> -export([on_load/0]). >> >> -export([open/2, close/1, >> - sync/1, datasync/1, truncate/1, advise/4, allocate/3, >> + sync/1, datasync/1, truncate/1, my_truncate/1, advise/4, >> allocate/3, >> read_line/1, read/2, write/2, position/2, >> pread/2, pread/3, pwrite/2, pwrite/3]). >> >> >> @@ -242,6 +242,15 @@ truncate(Fd) -> >> error:badarg -> {error, badarg} >> end. >> >> +my_truncate(Fd) -> >> + try >> + #{ handle := FRef } = get_fd_data(Fd), >> + reset_write_position(Fd), >> + my_truncate_nif(FRef) >> + catch >> + error:badarg -> {error, badarg} >> + end. >> + >> advise(Fd, Offset, Length, Advise) -> >> try >> #{ handle := FRef } = get_fd_data(Fd), >> @@ -493,6 +502,8 @@ allocate_nif(_FileRef, _Offset, _Length) -> >> erlang:nif_error(undef). >> truncate_nif(_FileRef) -> >> erlang:nif_error(undef). >> +my_truncate_nif(_FileRef) -> >> + erlang:nif_error(undef). >> get_handle_nif(_FileRef) -> >> erlang:nif_error(undef). >> delayed_close_nif(_FileRef) -> >> _______________________________________________ >> 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 raimo+erlang-questions@REDACTED Mon Apr 29 16:53:39 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Mon, 29 Apr 2019 16:53:39 +0200 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} In-Reply-To: References: <20190412083842.GA84954@erix.ericsson.se> <20190412123835.GA486@erix.ericsson.se> <119A945C-06F6-4E64-893E-9E6108D655F7@gmail.com> <20190417095442.GA62025@erix.ericsson.se> <20190417143603.GA85420@erix.ericsson.se> <20190425072817.GA39414@erix.ericsson.se> Message-ID: <20190429145339.GA71269@erix.ericsson.se> On Mon, Apr 29, 2019 at 11:49:18AM +0100, Peter Morgan wrote: > Hi Raimo, > > I?ve tried your patch and it hasn?t caused any errors. We are still having problems reproducing the issue, but it at least doesn?t look to have caused any side effects. Well, that is at least reassuring :-) So, it is so hard to reproduce that you can not be sure that a patch (any patch) has fixed it...? I will put it in our daily builds too, but we do not have many machines running daily for OTP-21, and this is a backported change from OTP-22, so it is hard to be sure that the change is exactly the same as in OTP-22 where it runs without problems. Since it passes your regression test, if it does not cause any regression errors for our few OTP-21 machines, I will probably place it in queue for next OTP-21 maintenance patch... If you get to any further conclusions on whether the patch fixes your problem or breaks anything, please let me know ASAP. Thank you for your help in investigating this! / Raimo > > Regards, > Peter. > > > On 25 Apr 2019, at 08:28, Raimo Niskanen wrote: > > > > On Wed, Apr 24, 2019 at 06:46:27PM +0100, Peter Morgan wrote: > >> Hi Raimo, > >> > >> I am having great difficultly reproducing in a simple test case. Despite best efforts of hundreds of thousands of processes creating timers and retry_state I?ve not managed to reproduce our production issue - with a vanilla OTP21 without your patch. Will let you know if I do. > >> > > > > Can you try my patch on OTP-21 - pull/2211 to see if it works without > > errors in your original setup? > > > > / Raimo > > > > > > > >> Thanks again for your help on this issue. > >> > >> Regards, > >> Peter. > >> > >>> On 17 Apr 2019, at 15:36, Raimo Niskanen wrote: > >>> > >>> On Wed, Apr 17, 2019 at 11:54:42AM +0200, Raimo Niskanen wrote: > >>>> After some discussions with the VM guys this seems to be a bug in > >>>> gen_statem coming from a misunderstanding of which guarantees that > >>>> asynchronous timer cancels gives and does not give. > >>>> > >>>> The {timeout, Ref, Msg} message may actually come _after_ the > >>>> {cancel_timer, Ref, false} message. Heavy load seems to increase the > >>>> probability from almost zero to very small. > >>>> > >>>> So the handling of these messages is broken for gen_statem on OTP-21, but > >>>> this should be fixed on master (soon to be OTP-22) since gen_statem there > >>>> does not use asynchronous timer cancels. > >>>> > >>>> I will look into how big a diff it will be to rewrite gen_statem in OTP-21.latest > >>>> to use synchronous timer cancel... > >>> > >>> The diff became a fat one, so I created a pull request: > >>> > >>> https://github.com/erlang/otp/pull/2211 > > >>> > >>> If you can try it out, that would be awsome! > >>> > >>> Best Regards > >>> / Raimo > >>> > >>> > >>> > >>>> > >>>> Thank you for finding a tricky bug! > >>>> / Raimo > >>>> > >>>> > >>>> > >>>> On Fri, Apr 12, 2019 at 04:13:27PM +0100, Peter Morgan wrote: > >>>>> Hi Raimo, > >>>>> > >>>>> Thanks for looking at this, and the background on the implementation which is very useful. I am in the process of putting together a simple test case, but having trouble reproducing it. It appears to happen very infrequently - possibly something that is load related? The original output was from the Crash Report which I?ve attached - where you can see the info timeout was received by our gen_statem behaviour callback. Our OTP is 21.2 (without any 21.2.X patches): > >>>>> > >>>>> {stdlib,"ERTS CXC 138 10","3.7?} > >>>>> {kernel,"ERTS CXC 138 10","6.2?} > >>>>> > >>>>> > >>>>> Your question - ?why so many?? - it could be a failure of a downstream service that is ultimately causing this, and we?re not backing off in this case - something that I?m checking too. However, I still thought it was interesting that the info timeout reaches the behaviour module. > >>>>> > >>>> > >>>>> =CRASH REPORT==== 8-Apr-2019::23:37:19.038905 === <0.969.0> proc_lib:crash_report/4:508 > >>>>> crasher: > >>>>> initial call: kafire_fetcher:init/1 > >>>>> pid: <0.969.0> > >>>>> registered_name: [] > >>>>> exception error: no function clause matching > >>>>> kafire_fetcher:handle_event(info, > >>>>> {timeout, > >>>>> #Ref<0.2399112782.889192450.118024>, > >>>>> fetch}, > >>>>> subsequent_fetches, > >>>>> our_state) (src/kafire_fetcher.erl, line 445) > >>>>> in function gen_statem:call_state_function/5 (gen_statem.erl, line 1662) > >>>>> in call from gen_statem:loop_event_state_function/6 (gen_statem.erl, line 1023) > >>>>> ancestors: [<0.931.0>,<0.332.0>,kafire_cluster_sup,kafire_sup,<0.227.0>] > >>>>> message_queue_len: 279 > >>>>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > >>>>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > >>>>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118061>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118062>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118063>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118064>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118068>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118069>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118070>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118071>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118074>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118079>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118081>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118083>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118087>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118088>,0}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118089>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118093>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118094>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118095>,3}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118096>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118097>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118098>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118099>,3}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118103>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118104>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118105>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118106>,3}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118107>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118108>,1}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118109>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118113>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118114>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118115>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118116>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118117>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118118>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118119>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118120>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118121>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118122>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118123>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118124>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118125>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118126>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118127>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118128>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118129>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118130>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118131>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118132>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118133>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118134>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118135>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118136>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118137>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118138>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118139>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118140>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118141>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118145>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118146>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118147>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118148>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118149>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118150>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118151>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118152>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118153>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118154>,5}, > >>>>> {timeout,#Ref<0.2399112782.889192450.118159>,fetch}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118159>,false}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118165>,0}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118169>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118170>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118173>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118174>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118175>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118176>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118177>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118178>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118179>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118180>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118181>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118182>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118183>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118184>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118185>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118189>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118190>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118191>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118192>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118196>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118197>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118198>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118199>,5}, > >>>>> {timeout,#Ref<0.2399112782.889192450.118203>,fetch}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118203>,false}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118206>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118207>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118208>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118212>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118213>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118214>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118215>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118221>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118225>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118226>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118227>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118231>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118235>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118236>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118237>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118238>,2}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118242>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118243>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118244>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118248>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118249>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118250>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118254>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118255>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118256>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118260>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118264>,0}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118265>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118266>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118270>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118271>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118272>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118273>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118274>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118278>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118279>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118280>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118281>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118282>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118283>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118287>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118288>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118289>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118290>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118291>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118295>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118296>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118297>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118298>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118299>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118303>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118304>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118305>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118306>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118307>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118308>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118309>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118313>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118314>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118315>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118316>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118317>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118318>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118319>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118323>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118324>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118325>,5}, > >>>>> {timeout,#Ref<0.2399112782.889192450.118326>,fetch}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118326>,false}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118327>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118328>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118329>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118330>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118331>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118332>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118333>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118337>,3}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118338>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118339>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118340>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118344>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118345>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118346>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118347>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118351>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118352>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118353>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118357>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118358>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118359>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118360>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118364>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118365>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118366>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118367>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118371>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118372>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118373>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118377>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118378>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118379>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118383>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118384>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118385>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118389>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118390>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118391>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118392>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118393>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118394>,0}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118395>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118399>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118400>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118401>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118402>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118403>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118404>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118405>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118409>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118410>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118411>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118412>,1}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118413>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118414>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118415>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118419>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118420>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118421>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118422>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118423>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118424>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118425>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118429>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118430>,0}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118431>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118432>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118433>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118434>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118435>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118439>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118440>,1}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118441>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118442>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118443>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118444>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118445>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118449>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118450>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118451>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118452>,4}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118453>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118454>,5}, > >>>>> {cancel_timer,#Ref<0.2399112782.889192450.118455>,5}, > >>>>> {timeout,#Ref<0.2399112782.889192450.118456>,fetch}, > >>>>> {'EXIT',<0.10080.8>,normal}, > >>>>> {'EXIT',<0.10079.8>,normal}, > >>>>> {'EXIT',<0.10081.8>,normal}, > >>>>> {'EXIT',<0.10082.8>,normal}, > >>>>> {'EXIT',<0.10083.8>,normal}, > >>>>> {'EXIT',<0.10084.8>,normal}, > >>>>> {'EXIT',<0.10085.8>,normal}, > >>>>> {'EXIT',<0.10086.8>,normal}, > >>>>> {'EXIT',<0.10087.8>,normal}, > >>>>> {'EXIT',<0.10088.8>,normal}, > >>>>> {'EXIT',<0.10089.8>,normal}, > >>>>> {'EXIT',<0.10071.8>,normal}] > >>>>> links: [<0.931.0>] > >>>>> dictionary: [] > >>>>> trap_exit: true > >>>>> status: running > >>>>> heap_size: 17731 > >>>>> stack_size: 27 > >>>>> reductions: 28849413204 > >>>>> neighbours: > >>>> > >>>>> > >>>>> > >>>>> I?ll try and get a simple test case for you. > >>>>> Regards, > >>>>> Peter. > >>>>> > >>>>> > >>>>> > >>>>>> On 12 Apr 2019, at 13:38, Raimo Niskanen wrote: > >>>>>> > >>>>>> On Fri, Apr 12, 2019 at 10:38:42AM +0200, Raimo Niskanen wrote: > >>>>>>> On Wed, Apr 10, 2019 at 01:41:06PM +0100, Peter Morgan wrote: > >>>>>>>> Hello - > >>>>>>>> > >>>>>>>> We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. > >>>>>>>> > >>>>>>>> The crash looks like: > >>>>>>>> > >>>>>>>> =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 > >>>>>>>> ** State machine {kafire_fetcher,<>,<>,0} terminating > >>>>>>>> ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} > >>>>>>>> > >>>>>>>> We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: > >>>>>>>> > >>>>>>>> > >>>>>>>> message_queue_len: 279 > >>>>>>>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, > >>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, > >>>>>>> > >>>>>>> Is that from a process_info() call? > >>>>>>> > >>>>>>>> > >>>>>>>> Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? > >>>>>>> > >>>>>>> It is not supposed to happen. This must be a bug. > >>>>>>> > >>>>>>> The gen_statem engine keeps track of the running state_timeout timer > >>>>>>> and should never present it as an info event. > >>>>>>> > >>>>>>> When a timer is stopped (or restarted) it is done with an asynchronous > >>>>>>> cancel (in OTP 21) so the cancel_timer messages comes from that. > >>>>>>> They should be matched against map entries in the internal gen_statem > >>>>>>> engine state when they arrive so them being in the inbox may be ok. > >>>>>>> > >>>>>>> However, how come you have so many? Are you restarting the state_timeout > >>>>>>> in a very tight loop of repeat_state:s? Can you show the essential parts > >>>>>>> of the code that causes state_timeout:s? > >>>>>>> > >>>>>>> Also - OTP-21.2; is that your exact OTP version? What is your stdlib version? > >>>>>>> > >>>>>>> I will look at the relevant parts of the code with the new knowledge that > >>>>>>> a state_timeout timer can be lost, probably in combination with > >>>>>>> repeat_state and state_timeout restart! > >>>>>> > >>>>>> > >>>>>> Sorry, the knowledge did not help; I did not find anything suspicous. > >>>>>> > >>>>>> More information will be needed... > >>>>>> > >>>>>>> > >>>>>>> On master since Jan 21 so in OTP-22.0-rc1 among other changes the timer handling > >>>>>>> has been rewritten to use a synchronous cancel, which simplified the code > >>>>>>> significantly. I do not know if that would be worth trying? > >>>>>>> > >>>>>>> / Raimo Niskanen > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Peter. > >>>>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> / Raimo Niskanen, Erlang/OTP, Ericsson AB > >>>>>> _______________________________________________ > >>>>>> erlang-questions mailing list > >>>>>> erlang-questions@REDACTED > >>>>>> http://erlang.org/mailman/listinfo/erlang-questions > >>>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> / Raimo Niskanen, Erlang/OTP, Ericsson AB > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>> > >>> -- > >>> > >>> / Raimo Niskanen, Erlang/OTP, Ericsson AB > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questions@REDACTED > > >>> http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From gergo.nyiro@REDACTED Mon Apr 29 21:04:51 2019 From: gergo.nyiro@REDACTED (=?UTF-8?B?TnlpcsWRIEdlcmfFkQ==?=) Date: Mon, 29 Apr 2019 21:04:51 +0200 Subject: [erlang-questions] erlzmq2 as rebar3 depency Message-ID: Dear List, I would like to setup an example project which uses zmq rep/req. I would prefer rebar3 as project management tool however I'm stucked with the following error in rebar3 shell: 1> erlzmq:context(). ** exception error: undefined function erlzmq_nif:context/1 I refers to erlzmq2 in the rebar.config like this: {deps, [{erlzmq, {git, "https://github.com/zeromq/erlzmq2.git"}}]}. When I use directly the erlzmq2 repository, then the `erlzmq:context()` call succeed. Should I add the port_specs, port_env and pre_hooks options of the https://github.com/zeromq/erlzmq2/blob/master/rebar.config directly into my rebar.config, too? Any help or advice are welcome. -- Gerg? From dmkolesnikov@REDACTED Mon Apr 29 21:28:26 2019 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 29 Apr 2019 22:28:26 +0300 Subject: [erlang-questions] erlzmq2 as rebar3 depency In-Reply-To: References: Message-ID: <57887379-0587-495B-9B2A-FF7EABBBE3E2@gmail.com> Hello, Try to add to your rebar.config ``` {deps, [ {erlzmq, {git, "https://github.com/zeromq/erlzmq2.git"}} ]}. {plugins, [pc]}. {overrides, [ {override, erlzmq, [ {plugins, [pc]}, {provider_hooks, [ {post, [ {compile, {pc, compile}}, {clean, {pc, clean}} ]} ]} ]} ]}. ``` It made a trick to me ``` 1> erlzmq:context(). {ok,#Ref<0.2526647583.4010409989.113935>} ``` - Dmitry > On 29 Apr 2019, at 22.04, Nyir? Gerg? wrote: > > Dear List, > > I would like to setup an example project which uses zmq rep/req. > I would prefer rebar3 as project management tool however I'm stucked > with the following error in rebar3 shell: > > 1> erlzmq:context(). > ** exception error: undefined function erlzmq_nif:context/1 > > I refers to erlzmq2 in the rebar.config like this: > > {deps, [{erlzmq, {git, "https://github.com/zeromq/erlzmq2.git"}}]}. > > When I use directly the erlzmq2 repository, then the `erlzmq:context()` > call succeed. > Should I add the port_specs, port_env and pre_hooks options of the > https://github.com/zeromq/erlzmq2/blob/master/rebar.config directly > into my rebar.config, too? > > Any help or advice are welcome. > > -- > Gerg? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kostis@REDACTED Mon Apr 29 21:34:08 2019 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 29 Apr 2019 21:34:08 +0200 Subject: [erlang-questions] Static Map ( Keys known at compile time ) In-Reply-To: References: Message-ID: <6a29d973-0d98-3cd2-df03-28ad4510dc37@cs.ntua.gr> On 4/29/19 12:31 PM, Richard O'Keefe wrote: > It's not clear to me why you would have a record with > 50 fields. Same here, of course. >? Imagine for a moment that Erlang's record > declaration syntax were generalised slightly: > > '-' 'record' '(' ',' ')' '.' > where > ? = '{' ( | )+',' '}' > ? = ['=' ] > > The generalisation here is allowing s as well > as s inside s.? A nested group would be > a nested tuple with no element reserved for a tag.? So > -record(foo, {{a,b},{c,d}}). > means that a typical instance would look like > {foo,{A,B},{C,D}}. > The time to fetch a field would be proportional to the > number of groups it is in; the time to replace it would > be proportional to the sum of the sizes of the groups > it is. > Put nested fields into groups that are commonly read > or written together, and you trade a small increase > in read time for a large decrease in write time, with > automatic economisation in pattern matching, but needing > special attention from the compiler to fully economise > updates. > > That would be a nice extension of Erlang records, letting > you make performance tradeoffs just by adding and removing > curly braces with no change to code elsewhere. I see very little benefit, if any at all, compared to the (natural, IMO) alternative of using nested records for such use cases: -record(foo, {#grp1{a,b},#grp2{c,d}}). which requires no language (or implementation) extension. What am I missing? Kostis From gergo.nyiro@REDACTED Mon Apr 29 23:15:14 2019 From: gergo.nyiro@REDACTED (=?UTF-8?B?TnlpcsWRIEdlcmfFkQ==?=) Date: Mon, 29 Apr 2019 23:15:14 +0200 Subject: [erlang-questions] erlzmq2 as rebar3 depency In-Reply-To: <57887379-0587-495B-9B2A-FF7EABBBE3E2@gmail.com> References: <57887379-0587-495B-9B2A-FF7EABBBE3E2@gmail.com> Message-ID: Thank you, that solved my problem. -- Gerg? On Mon, Apr 29, 2019 at 9:28 PM Dmitry Kolesnikov wrote: > > Hello, > > Try to add to your rebar.config > > ``` > {deps, [ > {erlzmq, {git, "https://github.com/zeromq/erlzmq2.git"}} > ]}. > > {plugins, [pc]}. > > {overrides, [ > {override, erlzmq, [ > {plugins, [pc]}, > > {provider_hooks, [ > {post, [ > {compile, {pc, compile}}, > {clean, {pc, clean}} > ]} > ]} > ]} > ]}. > ``` > > It made a trick to me > > ``` > 1> erlzmq:context(). > {ok,#Ref<0.2526647583.4010409989.113935>} > ``` > > - Dmitry > > > On 29 Apr 2019, at 22.04, Nyir? Gerg? wrote: > > > > Dear List, > > > > I would like to setup an example project which uses zmq rep/req. > > I would prefer rebar3 as project management tool however I'm stucked > > with the following error in rebar3 shell: > > > > 1> erlzmq:context(). > > ** exception error: undefined function erlzmq_nif:context/1 > > > > I refers to erlzmq2 in the rebar.config like this: > > > > {deps, [{erlzmq, {git, "https://github.com/zeromq/erlzmq2.git"}}]}. > > > > When I use directly the erlzmq2 repository, then the `erlzmq:context()` > > call succeed. > > Should I add the port_specs, port_env and pre_hooks options of the > > https://github.com/zeromq/erlzmq2/blob/master/rebar.config directly > > into my rebar.config, too? > > > > Any help or advice are welcome. > > > > -- > > Gerg? > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > From raoknz@REDACTED Tue Apr 30 04:28:59 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Tue, 30 Apr 2019 14:28:59 +1200 Subject: [erlang-questions] Static Map ( Keys known at compile time ) In-Reply-To: <6a29d973-0d98-3cd2-df03-28ad4510dc37@cs.ntua.gr> References: <6a29d973-0d98-3cd2-df03-28ad4510dc37@cs.ntua.gr> Message-ID: The advantage over nested records is fourfold. Clarity: the factoring of a "record" into a nest of tuples is invisible in the source code. Use Foo#R_F rather than Foo#R_F#N_G. Easier to read. Maintainability: changing the factoring does not affect the field names. Only the record declaration changes. Space: the nested groups do not have tags. If you have say a 10-slot record containing 10 5-slot records, you need 82 words. With nested groups, you save 10 words, or about 12% of the space. Time: with tag-less nested groups, copying time is less. Of COURSE nested records are a good approach right now. It could just be a bit better. On Tue, 30 Apr 2019 at 07:32, Kostis Sagonas wrote: > On 4/29/19 12:31 PM, Richard O'Keefe wrote: > > It's not clear to me why you would have a record with > > 50 fields. > > Same here, of course. > > > Imagine for a moment that Erlang's record > > declaration syntax were generalised slightly: > > > > '-' 'record' '(' ',' ')' '.' > > where > > = '{' ( | )+',' '}' > > = ['=' ] > > > > The generalisation here is allowing s as well > > as s inside s. A nested group would be > > a nested tuple with no element reserved for a tag. So > > -record(foo, {{a,b},{c,d}}). > > means that a typical instance would look like > > {foo,{A,B},{C,D}}. > > The time to fetch a field would be proportional to the > > number of groups it is in; the time to replace it would > > be proportional to the sum of the sizes of the groups > > it is. > > Put nested fields into groups that are commonly read > > or written together, and you trade a small increase > > in read time for a large decrease in write time, with > > automatic economisation in pattern matching, but needing > > special attention from the compiler to fully economise > > updates. > > > > That would be a nice extension of Erlang records, letting > > you make performance tradeoffs just by adding and removing > > curly braces with no change to code elsewhere. > > I see very little benefit, if any at all, compared to the (natural, IMO) > alternative of using nested records for such use cases: > > -record(foo, {#grp1{a,b},#grp2{c,d}}). > > which requires no language (or implementation) extension. > > What am I missing? > > Kostis > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessvegas@REDACTED Tue Apr 30 10:11:20 2019 From: chessvegas@REDACTED (DOBRO Sergei) Date: Tue, 30 Apr 2019 11:11:20 +0300 Subject: [erlang-questions] Equal binaries with different integers In-Reply-To: References: <7678451556526093@myt6-67cd1de25d8a.qloud-c.yandex.net> Message-ID: <15313921556611880@sas1-19a94364928d.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From peter.james.morgan@REDACTED Tue Apr 30 13:10:09 2019 From: peter.james.morgan@REDACTED (Peter Morgan) Date: Tue, 30 Apr 2019 12:10:09 +0100 Subject: [erlang-questions] gen_statem - state_timeout sometimes reaching callback module as [info, {timeout, Ref, Name} In-Reply-To: <20190429145339.GA71269@erix.ericsson.se> References: <20190412083842.GA84954@erix.ericsson.se> <20190412123835.GA486@erix.ericsson.se> <119A945C-06F6-4E64-893E-9E6108D655F7@gmail.com> <20190417095442.GA62025@erix.ericsson.se> <20190417143603.GA85420@erix.ericsson.se> <20190425072817.GA39414@erix.ericsson.se> <20190429145339.GA71269@erix.ericsson.se> Message-ID: <95E03F6E-A8F8-433E-9399-7C4DC71A44AF@gmail.com> Hi Raimo, > On 29 Apr 2019, at 15:53, Raimo Niskanen wrote: > > On Mon, Apr 29, 2019 at 11:49:18AM +0100, Peter Morgan wrote: >> Hi Raimo, >> >> I?ve tried your patch and it hasn?t caused any errors. We are still having problems reproducing the issue, but it at least doesn?t look to have caused any side effects. > > Well, that is at least reassuring :-) > > So, it is so hard to reproduce that you can not be sure that a patch (any > patch) has fixed it?? Correct. We?ve managed to get it to happen _once_ pre patch, and suspect that it is some combination of load and/or environment (AWS). Sadly, it is proving elusive to reproduce. > > I will put it in our daily builds too, but we do not have many machines > running daily for OTP-21, and this is a backported change from OTP-22, so > it is hard to be sure that the change is exactly the same as in OTP-22 > where it runs without problems. > > Since it passes your regression test, if it does not cause any regression > errors for our few OTP-21 machines, I will probably place it in queue for next > OTP-21 maintenance patch? That would be superb if we can get it into the queue for a maintenance patch. > > If you get to any further conclusions on whether the patch fixes your > problem or breaks anything, please let me know ASAP. :) Will do. Thanks again, Peter. > > Thank you for your help in investigating this! > > / Raimo > > > >> >> Regards, >> Peter. >> >>> On 25 Apr 2019, at 08:28, Raimo Niskanen wrote: >>> >>> On Wed, Apr 24, 2019 at 06:46:27PM +0100, Peter Morgan wrote: >>>> Hi Raimo, >>>> >>>> I am having great difficultly reproducing in a simple test case. Despite best efforts of hundreds of thousands of processes creating timers and retry_state I?ve not managed to reproduce our production issue - with a vanilla OTP21 without your patch. Will let you know if I do. >>>> >>> >>> Can you try my patch on OTP-21 - pull/2211 to see if it works without >>> errors in your original setup? >>> >>> / Raimo >>> >>> >>> >>>> Thanks again for your help on this issue. >>>> >>>> Regards, >>>> Peter. >>>> >>>>> On 17 Apr 2019, at 15:36, Raimo Niskanen wrote: >>>>> >>>>> On Wed, Apr 17, 2019 at 11:54:42AM +0200, Raimo Niskanen wrote: >>>>>> After some discussions with the VM guys this seems to be a bug in >>>>>> gen_statem coming from a misunderstanding of which guarantees that >>>>>> asynchronous timer cancels gives and does not give. >>>>>> >>>>>> The {timeout, Ref, Msg} message may actually come _after_ the >>>>>> {cancel_timer, Ref, false} message. Heavy load seems to increase the >>>>>> probability from almost zero to very small. >>>>>> >>>>>> So the handling of these messages is broken for gen_statem on OTP-21, but >>>>>> this should be fixed on master (soon to be OTP-22) since gen_statem there >>>>>> does not use asynchronous timer cancels. >>>>>> >>>>>> I will look into how big a diff it will be to rewrite gen_statem in OTP-21.latest >>>>>> to use synchronous timer cancel... >>>>> >>>>> The diff became a fat one, so I created a pull request: >>>>> >>>>> https://github.com/erlang/otp/pull/2211 > >> >>>>> >>>>> If you can try it out, that would be awsome! >>>>> >>>>> Best Regards >>>>> / Raimo >>>>> >>>>> >>>>> >>>>>> >>>>>> Thank you for finding a tricky bug! >>>>>> / Raimo >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 12, 2019 at 04:13:27PM +0100, Peter Morgan wrote: >>>>>>> Hi Raimo, >>>>>>> >>>>>>> Thanks for looking at this, and the background on the implementation which is very useful. I am in the process of putting together a simple test case, but having trouble reproducing it. It appears to happen very infrequently - possibly something that is load related? The original output was from the Crash Report which I?ve attached - where you can see the info timeout was received by our gen_statem behaviour callback. Our OTP is 21.2 (without any 21.2.X patches): >>>>>>> >>>>>>> {stdlib,"ERTS CXC 138 10","3.7?} >>>>>>> {kernel,"ERTS CXC 138 10","6.2?} >>>>>>> >>>>>>> >>>>>>> Your question - ?why so many?? - it could be a failure of a downstream service that is ultimately causing this, and we?re not backing off in this case - something that I?m checking too. However, I still thought it was interesting that the info timeout reaches the behaviour module. >>>>>>> >>>>>> >>>>>>> =CRASH REPORT==== 8-Apr-2019::23:37:19.038905 === <0.969.0> proc_lib:crash_report/4:508 >>>>>>> crasher: >>>>>>> initial call: kafire_fetcher:init/1 >>>>>>> pid: <0.969.0> >>>>>>> registered_name: [] >>>>>>> exception error: no function clause matching >>>>>>> kafire_fetcher:handle_event(info, >>>>>>> {timeout, >>>>>>> #Ref<0.2399112782.889192450.118024>, >>>>>>> fetch}, >>>>>>> subsequent_fetches, >>>>>>> our_state) (src/kafire_fetcher.erl, line 445) >>>>>>> in function gen_statem:call_state_function/5 (gen_statem.erl, line 1662) >>>>>>> in call from gen_statem:loop_event_state_function/6 (gen_statem.erl, line 1023) >>>>>>> ancestors: [<0.931.0>,<0.332.0>,kafire_cluster_sup,kafire_sup,<0.227.0>] >>>>>>> message_queue_len: 279 >>>>>>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, >>>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, >>>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118061>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118062>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118063>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118064>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118068>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118069>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118070>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118071>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118074>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118079>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118081>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118083>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118087>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118088>,0}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118089>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118093>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118094>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118095>,3}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118096>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118097>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118098>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118099>,3}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118103>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118104>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118105>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118106>,3}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118107>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118108>,1}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118109>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118113>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118114>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118115>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118116>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118117>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118118>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118119>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118120>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118121>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118122>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118123>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118124>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118125>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118126>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118127>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118128>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118129>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118130>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118131>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118132>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118133>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118134>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118135>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118136>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118137>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118138>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118139>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118140>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118141>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118145>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118146>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118147>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118148>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118149>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118150>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118151>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118152>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118153>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118154>,5}, >>>>>>> {timeout,#Ref<0.2399112782.889192450.118159>,fetch}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118159>,false}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118165>,0}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118169>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118170>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118173>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118174>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118175>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118176>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118177>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118178>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118179>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118180>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118181>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118182>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118183>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118184>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118185>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118189>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118190>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118191>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118192>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118196>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118197>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118198>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118199>,5}, >>>>>>> {timeout,#Ref<0.2399112782.889192450.118203>,fetch}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118203>,false}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118206>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118207>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118208>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118212>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118213>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118214>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118215>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118221>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118225>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118226>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118227>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118231>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118235>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118236>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118237>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118238>,2}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118242>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118243>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118244>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118248>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118249>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118250>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118254>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118255>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118256>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118260>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118264>,0}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118265>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118266>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118270>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118271>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118272>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118273>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118274>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118278>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118279>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118280>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118281>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118282>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118283>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118287>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118288>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118289>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118290>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118291>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118295>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118296>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118297>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118298>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118299>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118303>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118304>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118305>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118306>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118307>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118308>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118309>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118313>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118314>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118315>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118316>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118317>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118318>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118319>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118323>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118324>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118325>,5}, >>>>>>> {timeout,#Ref<0.2399112782.889192450.118326>,fetch}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118326>,false}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118327>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118328>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118329>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118330>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118331>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118332>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118333>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118337>,3}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118338>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118339>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118340>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118344>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118345>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118346>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118347>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118351>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118352>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118353>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118357>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118358>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118359>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118360>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118364>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118365>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118366>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118367>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118371>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118372>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118373>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118377>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118378>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118379>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118383>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118384>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118385>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118389>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118390>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118391>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118392>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118393>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118394>,0}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118395>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118399>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118400>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118401>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118402>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118403>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118404>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118405>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118409>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118410>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118411>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118412>,1}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118413>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118414>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118415>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118419>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118420>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118421>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118422>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118423>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118424>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118425>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118429>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118430>,0}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118431>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118432>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118433>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118434>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118435>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118439>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118440>,1}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118441>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118442>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118443>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118444>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118445>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118449>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118450>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118451>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118452>,4}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118453>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118454>,5}, >>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118455>,5}, >>>>>>> {timeout,#Ref<0.2399112782.889192450.118456>,fetch}, >>>>>>> {'EXIT',<0.10080.8>,normal}, >>>>>>> {'EXIT',<0.10079.8>,normal}, >>>>>>> {'EXIT',<0.10081.8>,normal}, >>>>>>> {'EXIT',<0.10082.8>,normal}, >>>>>>> {'EXIT',<0.10083.8>,normal}, >>>>>>> {'EXIT',<0.10084.8>,normal}, >>>>>>> {'EXIT',<0.10085.8>,normal}, >>>>>>> {'EXIT',<0.10086.8>,normal}, >>>>>>> {'EXIT',<0.10087.8>,normal}, >>>>>>> {'EXIT',<0.10088.8>,normal}, >>>>>>> {'EXIT',<0.10089.8>,normal}, >>>>>>> {'EXIT',<0.10071.8>,normal}] >>>>>>> links: [<0.931.0>] >>>>>>> dictionary: [] >>>>>>> trap_exit: true >>>>>>> status: running >>>>>>> heap_size: 17731 >>>>>>> stack_size: 27 >>>>>>> reductions: 28849413204 >>>>>>> neighbours: >>>>>> >>>>>>> >>>>>>> >>>>>>> I?ll try and get a simple test case for you. >>>>>>> Regards, >>>>>>> Peter. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 12 Apr 2019, at 13:38, Raimo Niskanen wrote: >>>>>>>> >>>>>>>> On Fri, Apr 12, 2019 at 10:38:42AM +0200, Raimo Niskanen wrote: >>>>>>>>> On Wed, Apr 10, 2019 at 01:41:06PM +0100, Peter Morgan wrote: >>>>>>>>>> Hello - >>>>>>>>>> >>>>>>>>>> We are _sometimes_ seeing cases where a state_timeout in a gen_statem results in the timeout reaching the callback module as info {timeout, Ref, Name} with OTP 21.2. >>>>>>>>>> >>>>>>>>>> The crash looks like: >>>>>>>>>> >>>>>>>>>> =ERROR REPORT==== 8-Apr-2019::23:37:19.035346 === <0.969.0> gen_statem:error_info/5:1895 >>>>>>>>>> ** State machine {kafire_fetcher,<>,<>,0} terminating >>>>>>>>>> ** Last event = {info,{timeout,#Ref<0.2399112782.889192450.118024>,fetch}} >>>>>>>>>> >>>>>>>>>> We crash because we are not expecting info messages - interestingly the following messages are in the queue for the crashed process: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> message_queue_len: 279 >>>>>>>>>> messages: [{timeout,#Ref<0.2399112782.903610369.70160>,fetch}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70160>,false}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.903610369.70168>,4}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118038>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118039>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118043>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118044>,4}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118045>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118049>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118050>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118051>,4}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118052>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118053>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118054>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118055>,4}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118056>,5}, >>>>>>>>>> {cancel_timer,#Ref<0.2399112782.889192450.118060>,5}, >>>>>>>>> >>>>>>>>> Is that from a process_info() call? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Followed by lots more cancel_timer messages (200ish!). Our gen_statem does use {state_timeout, 500, fetch} so we are expecting a ?fetch? timeout to happen, and we use repeat_state_and_data to requeue the state timeout (and also transition to other states). Is it possible that timeouts in gen_statem can be delivered as an info message? >>>>>>>>> >>>>>>>>> It is not supposed to happen. This must be a bug. >>>>>>>>> >>>>>>>>> The gen_statem engine keeps track of the running state_timeout timer >>>>>>>>> and should never present it as an info event. >>>>>>>>> >>>>>>>>> When a timer is stopped (or restarted) it is done with an asynchronous >>>>>>>>> cancel (in OTP 21) so the cancel_timer messages comes from that. >>>>>>>>> They should be matched against map entries in the internal gen_statem >>>>>>>>> engine state when they arrive so them being in the inbox may be ok. >>>>>>>>> >>>>>>>>> However, how come you have so many? Are you restarting the state_timeout >>>>>>>>> in a very tight loop of repeat_state:s? Can you show the essential parts >>>>>>>>> of the code that causes state_timeout:s? >>>>>>>>> >>>>>>>>> Also - OTP-21.2; is that your exact OTP version? What is your stdlib version? >>>>>>>>> >>>>>>>>> I will look at the relevant parts of the code with the new knowledge that >>>>>>>>> a state_timeout timer can be lost, probably in combination with >>>>>>>>> repeat_state and state_timeout restart! >>>>>>>> >>>>>>>> >>>>>>>> Sorry, the knowledge did not help; I did not find anything suspicous. >>>>>>>> >>>>>>>> More information will be needed... >>>>>>>> >>>>>>>>> >>>>>>>>> On master since Jan 21 so in OTP-22.0-rc1 among other changes the timer handling >>>>>>>>> has been rewritten to use a synchronous cancel, which simplified the code >>>>>>>>> significantly. I do not know if that would be worth trying? >>>>>>>>> >>>>>>>>> / Raimo Niskanen >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Peter. >>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> / Raimo Niskanen, Erlang/OTP, Ericsson AB >>>>>>>> _______________________________________________ >>>>>>>> erlang-questions mailing list >>>>>>>> erlang-questions@REDACTED >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> / Raimo Niskanen, Erlang/OTP, Ericsson AB >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> -- >>>>> >>>>> / Raimo Niskanen, Erlang/OTP, Ericsson AB >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED > >> >>>>> http://erlang.org/mailman/listinfo/erlang-questions > >> >>> >>> -- >>> >>> / Raimo Niskanen, Erlang/OTP, Ericsson AB >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre@REDACTED Tue Apr 30 17:22:49 2019 From: andre@REDACTED (Andre Nathan) Date: Tue, 30 Apr 2019 12:22:49 -0300 Subject: [erlang-questions] Compiling OTP on Windows Message-ID: Hi Does anyone have a pointer to up to date instructions on how to setup Windows to build OTP? I tried to follow the guide at [1] but it seems to be out of date (e.g. I can't find Visual Studio 2013 anymore). I tried to adapt the steps to the latest Visual Studio but I haven't used Windows in 20 years and failed miserably. Alternatively, if someone has a VirtualBox VM set up for development that I could download, it would be greatly appreciated, though I don't know if that would be legal... Thanks in advance, Andre [1] http://erlang.org/doc/installation_guide/INSTALL-WIN32.html From dmytro.lytovchenko@REDACTED Tue Apr 30 17:36:29 2019 From: dmytro.lytovchenko@REDACTED (Dmytro Lytovchenko) Date: Tue, 30 Apr 2019 17:36:29 +0200 Subject: [erlang-questions] Compiling OTP on Windows In-Reply-To: References: Message-ID: >From what I know the building instructions are pure magic involving MinGW and Visual Studio, and it is dangerous to go alone. Take this https://visualstudio.microsoft.com/vs/older-downloads/ On Tue, 30 Apr 2019 at 17:23, Andre Nathan wrote: > Hi > > Does anyone have a pointer to up to date instructions on how to setup > Windows to build OTP? I tried to follow the guide at [1] but it seems to > be out of date (e.g. I can't find Visual Studio 2013 anymore). > > I tried to adapt the steps to the latest Visual Studio but I haven't > used Windows in 20 years and failed miserably. > > Alternatively, if someone has a VirtualBox VM set up for development > that I could download, it would be greatly appreciated, though I don't > know if that would be legal... > > Thanks in advance, > Andre > > > [1] http://erlang.org/doc/installation_guide/INSTALL-WIN32.html > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre@REDACTED Tue Apr 30 17:49:52 2019 From: andre@REDACTED (Andre Nathan) Date: Tue, 30 Apr 2019 12:49:52 -0300 Subject: [erlang-questions] Compiling OTP on Windows In-Reply-To: References: Message-ID: On 4/30/19 12:36 PM, Dmytro Lytovchenko wrote: > From what I know the building instructions are pure magic involving > MinGW and Visual Studio, and it is dangerous to go alone. > Take this https://visualstudio.microsoft.com/vs/older-downloads/ Yeah, I've found that, but the VS 2013 link leads to a page that says no downloads are available. Thanks, Andre From wde@REDACTED Tue Apr 30 20:11:48 2019 From: wde@REDACTED (wde@REDACTED) Date: Tue, 30 Apr 2019 20:11:48 +0200 Subject: [erlang-questions] Thank you for all you did Joe Armstrong...RIP In-Reply-To: References: Message-ID: Dear all, What a sad news. I didn't post here since many years. I have discovered Erlang and Mr Armstrong's book in 2007. This is for me one of the most important book I have ever read. I have learnt so many things by discovering the Erlang world. Even if I don't write code anymore, this experience makes be better in my job, every days... how to think, how to solve IT problems...? I carry on spreading the Erlang philosophy each time I have the opportunity. I am quite proud to say that I have transmit that to younger IT guys. Mr Armstrong, thank you for your work. Your legacy will stay with us (with me) for long. Nicolas On 23.04.19 12:10, pierlu wrote: > I only had become aware of Erlang at the beginning of 2019 and just a > month ago I started being interested in it and bought Programming in > Erlang. > > Yet I have to start reading the book, but I saw a few conferences on > youtube by mr. Armstrong and it seemed to me he was very passionate > and witty and humble. > I signed with this newsletter so to get acquainted with the language > and spotted that mr. Armstrong posted on the list: his style of > writing and his approach confirmed what I have seen in the videos that > he was truly a genuine person. > > I am very saddened to hear the news. > Peace. > > pierlu. > > > On Sat, Apr 20, 2019 at 9:07 PM Matthew Evans > > wrote: > > > Sent from my iPhone > _______________________________________________ > 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: