From okaprinarjaya@REDACTED Mon Jul 1 04:03:23 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Mon, 1 Jul 2019 10:03:23 +0800 Subject: [erlang-questions] 10 processes, but only 5 or 8 processes replying to the caller. Why? Message-ID: Hi, I have following code https://pastebin.com/rQE1t1XA (order_manager.erl) and https://pastebin.com/ruGvGEKS (example_worker.erl) order_manager:create_order(poolnameany) will create 10 worker processes, under supervisor named poolnameany. Each worker processes is spawn of example_worker.erl order_manager:cast_order(poolnameany) will sending / distributing message to all of worker processes in paralalel. So all 10 worker processes will receive same message content. In example_worker.erl have following lines of code part: %% example_worker.erl -define(SLEEP_RANDOM, [3000, 4000, 5000, 6000, 2000]). pick_random_sleep() -> Res = lists:nth(rand:uniform(5), ?SLEEP_RANDOM), Res. ... ... ... handle_call({receive_initial_order, Ref, InitialOrders}, _From, State) -> io:format("~p is receiving: ~p~n", [self(), InitialOrders]), timer:sleep(pick_random_sleep()), {reply, {ok, self(), Ref}, State#state{offset=3}}; My problem is, i am not able to get reply completely from all 10 worker processes. Why? I always only get 5 or 8 reply from 5 or 8 worker processes. 8 often. And, this is the handler to receive reply from each worker processes buzz(_N, 11, _PoolName, _InitialOrders) -> ok; buzz(N, Incr, PoolName, InitialOrders) -> spawn(fun() -> poolboy:transaction( PoolName, fun(Worker) -> Ref = make_ref(), {ok, WorkerPid, Ref} = gen_server:call(Worker, {receive_initial_order, Ref, InitialOrders}), io:format("Reply: [WorkerPid: ~p], [Ref: ~p]~n", [WorkerPid, Ref]) end ) end), buzz(N, Incr+1, PoolName, InitialOrders). [image: Screen Shot 2019-07-01 at 10.02.02.png] Eshell V10.2 (abort with ^G) 1> ===> The rebar3 shell is a development tool; to deploy applications in production, consider using releases (http://www.rebar3.org/docs/releases) ===> Booted sasl ===> Booted wx ===> Booted observer ===> Booted dist_procs_je_asane 1> order_manager:create_order(balihome). ok 2> order_manager:cast_order(balihome). <0.183.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] <0.182.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] <0.181.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] <0.180.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] <0.179.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] <0.178.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] <0.177.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] ok <0.176.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] 3> <0.175.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] <0.174.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] Reply: [WorkerPid: <0.180.0>], [Ref: #Ref<0.2480760321.1800142849.332>] Reply: [WorkerPid: <0.183.0>], [Ref: #Ref<0.2480760321.1800142849.326>] Reply: [WorkerPid: <0.182.0>], [Ref: #Ref<0.2480760321.1800142849.328>] Reply: [WorkerPid: <0.176.0>], [Ref: #Ref<0.2480760321.1800142849.340>] Reply: [WorkerPid: <0.181.0>], [Ref: #Ref<0.2480760321.1800142849.330>] Reply: [WorkerPid: <0.179.0>], [Ref: #Ref<0.2480760321.1800142849.334>] Reply: [WorkerPid: <0.175.0>], [Ref: #Ref<0.2480760321.1800142849.342>] Reply: [WorkerPid: <0.178.0>], [Ref: #Ref<0.2480760321.1800142849.336>] Please enlightenment Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2019-07-01 at 10.02.02.png Type: image/png Size: 175413 bytes Desc: not available URL: From yurinvv@REDACTED Mon Jul 1 06:09:52 2019 From: yurinvv@REDACTED (Slava Yurin) Date: Mon, 01 Jul 2019 11:09:52 +0700 Subject: [erlang-questions] 10 processes, but only 5 or 8 processes replying to the caller. Why? In-Reply-To: References: Message-ID: <13998191561954192@iva8-03ad76494624.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2019-07-01 at 10.02.02.png Type: image/png Size: 175413 bytes Desc: not available URL: From petergi@REDACTED Mon Jul 1 10:36:30 2019 From: petergi@REDACTED (Peter J Etheridge) Date: Mon, 01 Jul 2019 18:36:30 +1000 Subject: [erlang-questions] nonode@nohost Message-ID: dear friends,i am trying to send a record from my wx module to mnesia module. the error message i receive is; node_not_started, nonode@REDACTED some reading of the manual mentions that nonode@REDACTED is an error message.(self explanatory in hindsight.) which module of the manual (or other resource) should a beginner read for instructions to correctly set up a node? thank you in advance,peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Mon Jul 1 13:16:44 2019 From: roger@REDACTED (Roger Lipscombe) Date: Mon, 1 Jul 2019 12:16:44 +0100 Subject: [erlang-questions] How do I prevent escript from reading stdin? Message-ID: If I paste a sequence of commands into my terminal window... ./some-escript ./not-escript ...then not-escript never gets run, because (afaict), some-escript ate all of the input. If I paste the following: ./some-escript References: Message-ID: IIRC you can pass the -noinput flag at the beginning of the escript: #!/usr/bin/env escript %%! -noinput *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Mon, Jul 1, 2019 at 1:17 PM Roger Lipscombe wrote: > If I paste a sequence of commands into my terminal window... > > ./some-escript > ./not-escript > > ...then not-escript never gets run, because (afaict), some-escript ate > all of the input. If I paste the following: > > ./some-escript ./not-escript > > ...then it's fine. But that's ugly. > > How do I prevent escript from reading stdin? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus@REDACTED Mon Jul 1 13:26:38 2019 From: magnus@REDACTED (Magnus Henoch) Date: Mon, 1 Jul 2019 12:26:38 +0100 Subject: [erlang-questions] How do I prevent escript from reading stdin? In-Reply-To: References: Message-ID: On 01/07/2019 12:16, Roger Lipscombe wrote: > If I paste a sequence of commands into my terminal window... > > ./some-escript > ./not-escript > > ...then not-escript never gets run, because (afaict), some-escript ate > all of the input. If I paste the following: > > ./some-escript ./not-escript > > ...then it's fine. But that's ugly. > > How do I prevent escript from reading stdin? You can add a line to your escript to pass an emulator argument and make it not read any input: #!/usr/bin/env escript %%! -noinput main(_) -> ??? io:format("hello world\n"). IIRC, the %%! line needs to be the second or third line in the file. Regards, Magnus From roger@REDACTED Mon Jul 1 15:42:46 2019 From: roger@REDACTED (Roger Lipscombe) Date: Mon, 1 Jul 2019 14:42:46 +0100 Subject: [erlang-questions] How do I prevent escript from reading stdin? In-Reply-To: References: Message-ID: On Mon, 1 Jul 2019 at 12:22, Jos? Valim wrote: > > IIRC you can pass the -noinput flag at the beginning of the escript: > > #!/usr/bin/env escript > %%! -noinput Works. Thanks. From jacob01@REDACTED Mon Jul 1 16:25:39 2019 From: jacob01@REDACTED (Jacob) Date: Mon, 1 Jul 2019 16:25:39 +0200 Subject: [erlang-questions] How do I prevent escript from reading stdin? In-Reply-To: References: Message-ID: <9c3b6940-9b50-d8b0-bdf2-2dc2183ca101@gmx.net> Hi, On 7/1/19 1:16 PM, Roger Lipscombe wrote: > If I paste a sequence of commands into my terminal window... > > ./some-escript > ./not-escript > > ...then not-escript never gets run, because (afaict), some-escript ate > all of the input. If I paste the following: > > ./some-escript ./not-escript > > ...then it's fine. But that's ugly. While this might look ugly, it has the advantage of clearly showing your intention, even if the escript was not consuming stdin. At least if you put code like that into a script, it will help a future reader (possibly including the writer) a lot. When using bash/dash, you could also explicitly just close stdin explicitly by ./some-escript <&- ./not-escript with a similar effect but perhaps (depending on taste) less ugly. (Other shells may also have a similar feature) Jacob From gfborn@REDACTED Tue Jul 2 09:53:24 2019 From: gfborn@REDACTED (Grigory Fateyev) Date: Tue, 2 Jul 2019 10:53:24 +0300 Subject: [erlang-questions] Encode data using public RSA key Message-ID: <20190702105324.3e9d8823@gregf.gregf> Hello, Erlangers! I have RSA public key (seems its C#) like: ...... ok, I can convert it to normal public key. How can I encode any data using this key? Thank you! -- Best regards! From roger@REDACTED Tue Jul 2 10:20:53 2019 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 2 Jul 2019 09:20:53 +0100 Subject: [erlang-questions] Encode data using public RSA key In-Reply-To: <20190702105324.3e9d8823@gregf.gregf> References: <20190702105324.3e9d8823@gregf.gregf> Message-ID: http://erlang.org/doc/man/public_key.html#encrypt_public-2 On Tue, 2 Jul 2019 at 08:53, Grigory Fateyev wrote: > > Hello, Erlangers! > > I have RSA public key (seems its C#) like: > > ...... > > ok, I can convert it to normal public key. How can I encode any data > using this key? > > Thank you! > > -- > Best regards! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From okaprinarjaya@REDACTED Tue Jul 2 17:28:24 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Tue, 2 Jul 2019 23:28:24 +0800 Subject: [erlang-questions] 10 processes, but only 5 or 8 processes replying to the caller. Why? In-Reply-To: <13998191561954192@iva8-03ad76494624.qloud-c.yandex.net> References: <13998191561954192@iva8-03ad76494624.qloud-c.yandex.net> Message-ID: Hi, Thank you very much :) Thanks for the clue, then it works after increasing the timeout through 3rd parameter of gen_server:call() Pada tanggal Sen, 1 Jul 2019 pukul 12.09 Slava Yurin menulis: > gen_server:call has default timeout = 5000. Your spawned process in buzz > function get from gen_server:call timeout error and than exit with bad > match. > As it not linked or supervised, an error message is not printed. > > 01.07.2019, 09:04, "I Gusti Ngurah Oka Prinarjaya" < > okaprinarjaya@REDACTED>: > > Hi, > > I have following code > > https://pastebin.com/rQE1t1XA (order_manager.erl) > > and > > https://pastebin.com/ruGvGEKS (example_worker.erl) > > order_manager:create_order(poolnameany) will create 10 worker processes, > under supervisor named poolnameany. Each worker processes is spawn of > example_worker.erl > > order_manager:cast_order(poolnameany) will sending / distributing message > to all of worker processes in paralalel. So all 10 worker processes will > receive same message content. > > In example_worker.erl have following lines of code part: > > %% example_worker.erl > -define(SLEEP_RANDOM, [3000, 4000, 5000, 6000, 2000]). > > pick_random_sleep() -> > Res = lists:nth(rand:uniform(5), ?SLEEP_RANDOM), > Res. > ... > ... > ... > handle_call({receive_initial_order, Ref, InitialOrders}, _From, State) -> > io:format("~p is receiving: ~p~n", [self(), InitialOrders]), > timer:sleep(pick_random_sleep()), > {reply, {ok, self(), Ref}, State#state{offset=3}}; > > My problem is, i am not able to get reply completely from all 10 worker > processes. Why? > I always only get 5 or 8 reply from 5 or 8 worker processes. 8 often. > > And, this is the handler to receive reply from each worker processes > > buzz(_N, 11, _PoolName, _InitialOrders) -> > ok; > > buzz(N, Incr, PoolName, InitialOrders) -> > spawn(fun() -> > poolboy:transaction( > PoolName, > fun(Worker) -> > Ref = make_ref(), > {ok, WorkerPid, Ref} = gen_server:call(Worker, > {receive_initial_order, Ref, InitialOrders}), > io:format("Reply: [WorkerPid: ~p], [Ref: ~p]~n", [WorkerPid, Ref]) > end > ) > end), > buzz(N, Incr+1, PoolName, InitialOrders). > > [image: Screen Shot 2019-07-01 at 10.02.02.png] > > > > Eshell V10.2 (abort with ^G) > > 1> ===> The rebar3 shell is a development tool; to deploy applications in > production, consider using releases (http://www.rebar3.org/docs/releases) > > ===> Booted sasl > > ===> Booted wx > > ===> Booted observer > > ===> Booted dist_procs_je_asane > > > > 1> order_manager:create_order(balihome). > > ok > > 2> order_manager:cast_order(balihome). > > <0.183.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > <0.182.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > <0.181.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > <0.180.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > <0.179.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > <0.178.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > <0.177.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > ok > > <0.176.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > 3> <0.175.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > <0.174.0> is receiving: [<<"Satu">>,<<"Dua">>,<<"Tiga">>] > > Reply: [WorkerPid: <0.180.0>], [Ref: #Ref<0.2480760321.1800142849.332>] > > Reply: [WorkerPid: <0.183.0>], [Ref: #Ref<0.2480760321.1800142849.326>] > > Reply: [WorkerPid: <0.182.0>], [Ref: #Ref<0.2480760321.1800142849.328>] > > Reply: [WorkerPid: <0.176.0>], [Ref: #Ref<0.2480760321.1800142849.340>] > > Reply: [WorkerPid: <0.181.0>], [Ref: #Ref<0.2480760321.1800142849.330>] > > Reply: [WorkerPid: <0.179.0>], [Ref: #Ref<0.2480760321.1800142849.334>] > > Reply: [WorkerPid: <0.175.0>], [Ref: #Ref<0.2480760321.1800142849.342>] > > Reply: [WorkerPid: <0.178.0>], [Ref: #Ref<0.2480760321.1800142849.336>] > > > > Please enlightenment > > Thank you > > > > > > , > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2019-07-01 at 10.02.02.png Type: image/png Size: 175413 bytes Desc: not available URL: From matwey.kornilov@REDACTED Tue Jul 2 19:44:47 2019 From: matwey.kornilov@REDACTED (Matwey V. Kornilov) Date: Tue, 2 Jul 2019 20:44:47 +0300 Subject: [erlang-questions] crypto: priv/obj and OTP-4828 Message-ID: Hi, I see the following in the changelog for the quite old version of crypto: """ Fixed Bugs and Malfunctions It was not possible in R9 to relink the crypto driver. The object file was missing as well as an example makefile. The crypto driver object file is now released with the application (installed in priv/obj). An example makefile has also been added to the priv/obj directory. The makefile serves as an example of how to relink the driver on Unix (crypto_drv.so) or Windows (crypto_drv.dll). Own Id: OTP-4828 Aux Id: seq8193 """ priv/obj is still there. I would like to have more details on this issue. Could somebody give an example when one needs to relink crypto_drv.so? From otp@REDACTED Wed Jul 3 10:27:31 2019 From: otp@REDACTED (Erlang/OTP) Date: Wed, 3 Jul 2019 10:27:31 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8.5 Released Message-ID: <20190703082731.GA60054@erix.ericsson.se> Patch Package: OTP 21.3.8.5 Git Tag: OTP-21.3.8.5 Date: 2019-07-03 Trouble Report Id: OTP-15909, OTP-15910, OTP-15938, OTP-15939, OTP-15941 Seq num: ERL-979, ERL-986 System: OTP Release: 21 Application: erts-10.3.5.4, ssl-9.2.3.4 Predecessor: OTP 21.3.8.4 Check out the git tag OTP-21.3.8.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. --------------------------------------------------------------------- --- erts-10.3.5.4 --------------------------------------------------- --------------------------------------------------------------------- Note! The erts-10.3.5.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-15909 Application(s): erts Related Id(s): ERL-979 Fixed bug causing VM crash when doing textual dump of a process containing an unhandled monitor down signal. Textual process dumps can be done with erlang:system_info(procs), trace feature process_dump, Erlang shell break menu and a crashdump. Bug exist since OTP 21.0. OTP-15938 Application(s): erts Related Id(s): ERL-986 lists:subtract/2 would produce incorrect results for some inputs on 64-bit platforms. OTP-15939 Application(s): erts Fixed a bug in the loader that was similar to OTP-15938, yielding incorrect code for some inputs on 64-bit platforms. OTP-15941 Application(s): erts Related Id(s): PR-2313 Fixed bug causing scheduler threads in rare cases to block spinnning indefinitely. Bug exists since OTP 21.0. Full runtime dependencies of erts-10.3.5.4: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- ssl-9.2.3.4 ----------------------------------------------------- --------------------------------------------------------------------- The ssl-9.2.3.4 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15910 Application(s): ssl Hibernation now works as expected in all cases, was accidently broken by optimization efforts. Full runtime dependencies of ssl-9.2.3.4: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From otp@REDACTED Wed Jul 3 10:41:44 2019 From: otp@REDACTED (Erlang/OTP) Date: Wed, 3 Jul 2019 10:41:44 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.5 Released Message-ID: <20190703084143.GA63230@erix.ericsson.se> Patch Package: OTP 22.0.5 Git Tag: OTP-22.0.5 Date: 2019-07-03 Trouble Report Id: OTP-15900, OTP-15908, OTP-15909, OTP-15910, OTP-15913, OTP-15922, OTP-15930, OTP-15938, OTP-15939, OTP-15941 Seq num: ERL-949, ERL-969, ERL-979, ERL-980, ERL-986 System: OTP Release: 22 Application: dialyzer-4.0.2, erts-10.4.4, inets-7.0.9, ssl-9.3.4 Predecessor: OTP 22.0.4 Check out the git tag OTP-22.0.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. --------------------------------------------------------------------- --- dialyzer-4.0.2 -------------------------------------------------- --------------------------------------------------------------------- The dialyzer-4.0.2 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-15922 Application(s): dialyzer Related Id(s): ERL-949, PR-2240 Make sure Dialyzer does not crash if the formatting of results fails. Instead of crashing, an unformatted version of the results is returned. Full runtime dependencies of dialyzer-4.0.2: compiler-7.0, erts-9.0, hipe-3.16.1, kernel-5.3, stdlib-3.4, syntax_tools-2.0, wx-1.2 --------------------------------------------------------------------- --- erts-10.4.4 ----------------------------------------------------- --------------------------------------------------------------------- The erts-10.4.4 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-15908 Application(s): erts Related Id(s): ERL-980 An invalid value test caused the socket:setopt(Socket, ip, add_membership, ip_mreq()) to fail with badarg. The same for drop_membership. OTP-15909 Application(s): erts Related Id(s): ERL-979 Fixed bug causing VM crash when doing textual dump of a process containing an unhandled monitor down signal. Textual process dumps can be done with erlang:system_info(procs), trace feature process_dump, Erlang shell break menu and a crashdump. Bug exist since OTP 21.0. OTP-15938 Application(s): erts Related Id(s): ERL-986 lists:subtract/2 would produce incorrect results for some inputs on 64-bit platforms. OTP-15939 Application(s): erts Fixed a bug in the loader that was similar to OTP-15938, yielding incorrect code for some inputs on 64-bit platforms. OTP-15941 Application(s): erts Related Id(s): PR-2313 Fixed bug causing scheduler threads in rare cases to block spinnning indefinitely. Bug exists since OTP 21.0. Full runtime dependencies of erts-10.4.4: kernel-6.1, sasl-3.3, stdlib-3.5 --------------------------------------------------------------------- --- inets-7.0.9 ----------------------------------------------------- --------------------------------------------------------------------- The inets-7.0.9 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-15930 Application(s): inets Related Id(s): ERL-969 Fix a regression in http client that causes a crash when request URI has no scheme. Full runtime dependencies of inets-7.0.9: erts-6.0, kernel-3.0, mnesia-4.12, runtime_tools-1.8.14, ssl-5.3.4, stdlib-3.5 --------------------------------------------------------------------- --- ssl-9.3.4 ------------------------------------------------------- --------------------------------------------------------------------- The ssl-9.3.4 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-15900 Application(s): ssl Fix handling of certificate decoding problems in TLS 1.3 similarly as in TLS 1.2. OTP-15910 Application(s): ssl Hibernation now works as expected in all cases, was accidently broken by optimization efforts. OTP-15913 Application(s): ssl Fix interoperability problems with openssl when the TLS 1.3 server is configured wirh the option signature_algs_cert. Full runtime dependencies of ssl-9.3.4: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From rickard@REDACTED Wed Jul 3 22:28:03 2019 From: rickard@REDACTED (Rickard Green) Date: Wed, 3 Jul 2019 22:28:03 +0200 Subject: [erlang-questions] crypto: priv/obj and OTP-4828 In-Reply-To: References: Message-ID: On Tue, Jul 2, 2019 at 7:45 PM Matwey V. Kornilov wrote: > > > Hi, > > I see the following in the changelog for the quite old version of crypto: > > """ > Fixed Bugs and Malfunctions > > It was not possible in R9 to relink the crypto driver. The object > file was missing as well as an example makefile. The crypto driver > object file is now released with the application (installed in > priv/obj). An example makefile has also been added to the priv/obj > directory. The makefile serves as an example of how to relink the driver > on Unix (crypto_drv.so) or Windows (crypto_drv.dll). > > Own Id: OTP-4828 Aux Id: seq8193 > """ > > priv/obj is still there. I would like to have more details on this > issue. Could somebody give an example when one needs to relink > crypto_drv.so? > We used to deliver a pre-built binary release of OTP for licensed customers. The object file and example makefile were there in order for customers to be able link the crypto driver against an alternative openssl library. Nowadays the driver has be replaced by a NIF and we only deliver OTP as source. Since everyone builds from source, there is no need for this relink procedure. -- Rickard Green, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From matwey.kornilov@REDACTED Thu Jul 4 10:52:37 2019 From: matwey.kornilov@REDACTED (Matwey V. Kornilov) Date: Thu, 4 Jul 2019 11:52:37 +0300 Subject: [erlang-questions] crypto: priv/obj and OTP-4828 In-Reply-To: References: Message-ID: ??, 3 ???. 2019 ?. ? 23:28, Rickard Green : > > > > On Tue, Jul 2, 2019 at 7:45 PM Matwey V. Kornilov wrote: > > > > > > Hi, > > > > I see the following in the changelog for the quite old version of crypto: > > > > """ > > Fixed Bugs and Malfunctions > > > > It was not possible in R9 to relink the crypto driver. The object > > file was missing as well as an example makefile. The crypto driver > > object file is now released with the application (installed in > > priv/obj). An example makefile has also been added to the priv/obj > > directory. The makefile serves as an example of how to relink the driver > > on Unix (crypto_drv.so) or Windows (crypto_drv.dll). > > > > Own Id: OTP-4828 Aux Id: seq8193 > > """ > > > > priv/obj is still there. I would like to have more details on this > > issue. Could somebody give an example when one needs to relink > > crypto_drv.so? > > > > We used to deliver a pre-built binary release of OTP for licensed customers. The object file and example makefile were there in order for customers to be able link the crypto driver against an alternative openssl library. Nowadays the driver has be replaced by a NIF and we only deliver OTP as source. Since everyone builds from source, there is no need for this relink procedure. > -- > Rickard Green, Erlang/OTP, Ericsson AB Hi, Many thanks for your response. You say that relinking is not needed nowadays. Is it possible to drop this object files from "make install" rules in further releases? -- With best regards, Matwey V. Kornilov From rickard@REDACTED Thu Jul 4 13:48:55 2019 From: rickard@REDACTED (Rickard Green) Date: Thu, 4 Jul 2019 13:48:55 +0200 Subject: [erlang-questions] crypto: priv/obj and OTP-4828 In-Reply-To: References: Message-ID: On Thu, Jul 4, 2019 at 10:52 AM Matwey V. Kornilov < matwey.kornilov@REDACTED> wrote: > ??, 3 ???. 2019 ?. ? 23:28, Rickard Green : > > > > > > > > On Tue, Jul 2, 2019 at 7:45 PM Matwey V. Kornilov < > matwey.kornilov@REDACTED> wrote: > > > > > > > > > Hi, > > > > > > I see the following in the changelog for the quite old version of > crypto: > > > > > > """ > > > Fixed Bugs and Malfunctions > > > > > > It was not possible in R9 to relink the crypto driver. The object > > > file was missing as well as an example makefile. The crypto driver > > > object file is now released with the application (installed in > > > priv/obj). An example makefile has also been added to the priv/obj > > > directory. The makefile serves as an example of how to relink the > driver > > > on Unix (crypto_drv.so) or Windows (crypto_drv.dll). > > > > > > Own Id: OTP-4828 Aux Id: seq8193 > > > """ > > > > > > priv/obj is still there. I would like to have more details on this > > > issue. Could somebody give an example when one needs to relink > > > crypto_drv.so? > > > > > > > We used to deliver a pre-built binary release of OTP for licensed > customers. The object file and example makefile were there in order for > customers to be able link the crypto driver against an alternative openssl > library. Nowadays the driver has be replaced by a NIF and we only deliver > OTP as source. Since everyone builds from source, there is no need for this > relink procedure. > Let me take the last sentence back :-) > > -- > > Rickard Green, Erlang/OTP, Ericsson AB > > Hi, > > Many thanks for your response. You say that relinking is not needed > nowadays. Is it possible to drop this object files from "make install" > rules in further releases? > > -- > With best regards, > Matwey V. Kornilov > In case you deliver OTP as a pre-built binary package to your customers (as we previously did), it might be useful for your customers to be able to relink the crypto NIF library. That is, I don't think this feature should be removed. -- Rickard Green, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Jul 4 16:11:24 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 4 Jul 2019 17:11:24 +0300 Subject: [erlang-questions] enif_release_resource and enif_make_resource Message-ID: I have following code in nif: State *s = enif_alloc_resource(..) enif_self(env, &s->owner); ERL_NIF_TERM term = enif_make_resource(env, s); enif_release_resource(s); return term; Then later another thread (not written by me) is calling my callback function: void mycallback(void *obj) { State *s = obj; ErlNifEnv *msg_env = enif_alloc_env(); ERL_NIF_TERM term = enif_make_resource(msg_env, s); enif_send(NULL, &s->owner, msg_env, term); enif_free_env(msg_env); } Is this code correct? Should I put release_resource for each make_resource or only for release_resource? Is this calling of enif_send correct? I'm afraid that I miss these answers in documentation or cannot find them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me@REDACTED Fri Jul 5 18:26:09 2019 From: me@REDACTED (Nato) Date: Fri, 05 Jul 2019 09:26:09 -0700 Subject: [erlang-questions] releases + warning for application resource file Message-ID: <16bc2f50f6d.6d04a745-1005231713.3369086852325144010@zoho.com> Is there a heuristic or tactic for ensuring that one's application includes all the necessary OTP applications (listed in the application resource file's list of `applications')? I've had it happen a couple times where I'll use a module belonging to, say `inets,' compiling is just fine, code works locally, and release-building is all good too. However, I'll ship the release and since `inets' wasn't listed in the application resource file, at runtime, calling, say `httpd_util' module, falls over. I suppose I'm looking to toggle on something in `relx' or even better, `erlc' to Error-out when my code calls modules that won't be accessible in a release. -- Nato From t@REDACTED Fri Jul 5 19:01:41 2019 From: t@REDACTED (Tristan Sloughter) Date: Fri, 05 Jul 2019 11:01:41 -0600 Subject: [erlang-questions] =?utf-8?q?releases_+_warning_for_application_r?= =?utf-8?q?esource_file?= In-Reply-To: <16bc2f50f6d.6d04a745-1005231713.3369086852325144010@zoho.com> References: <16bc2f50f6d.6d04a745-1005231713.3369086852325144010@zoho.com> Message-ID: Sadly there is a way to tell systools to run an xref check before generating the boot script based on what will be in the release, but it is not possible to add it to the options through relx at this time, http://erlang.org/doc/man/systools.html#make_script-2 My plan is for exref to be a default option used by relx in the next major release, discussed here https://github.com/erlware/relx/issues/729 I've been meaning to check if 'rebar3 xref' can catch stuff like this or if it needs to change to work properly on only the runtime dependencies specified by an application. I'll take a look at that today and also open an issue for rebar3 if that is the case. Tristan On Fri, Jul 5, 2019, at 10:26, Nato wrote: > Is there a heuristic or tactic for ensuring that > one's application includes all the necessary OTP > applications (listed in the application resource > file's list of `applications')? > > I've had it happen a couple times where > I'll use a module belonging to, say `inets,' > compiling is just fine, code works locally, > and release-building is all good too. > However, I'll ship the release and since > `inets' wasn't listed in the application > resource file, at runtime, calling, say > `httpd_util' module, falls over. > > I suppose I'm looking to toggle on something > in `relx' or even better, `erlc' to Error-out > when my code calls modules that won't be > accessible in a release. > > -- > Nato > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From t@REDACTED Fri Jul 5 19:09:59 2019 From: t@REDACTED (Tristan Sloughter) Date: Fri, 05 Jul 2019 11:09:59 -0600 Subject: [erlang-questions] =?utf-8?q?releases_+_warning_for_application_r?= =?utf-8?q?esource_file?= In-Reply-To: References: <16bc2f50f6d.6d04a745-1005231713.3369086852325144010@zoho.com> Message-ID: <337fc470-6d8c-4424-92a0-ecae57edac50@www.fastmail.com> Verified and created a rebar3 ticket https://github.com/erlang/rebar3/issues/2119 On Fri, Jul 5, 2019, at 11:02, Tristan Sloughter wrote: > Sadly there is a way to tell systools to run an xref check before > generating the boot script based on what will be in the release, but it > is not possible to add it to the options through relx at this time, > http://erlang.org/doc/man/systools.html#make_script-2 > > My plan is for exref to be a default option used by relx in the next > major release, discussed here https://github.com/erlware/relx/issues/729 > > I've been meaning to check if 'rebar3 xref' can catch stuff like this > or if it needs to change to work properly on only the runtime > dependencies specified by an application. I'll take a look at that > today and also open an issue for rebar3 if that is the case. > > Tristan > > On Fri, Jul 5, 2019, at 10:26, Nato wrote: > > Is there a heuristic or tactic for ensuring that > > one's application includes all the necessary OTP > > applications (listed in the application resource > > file's list of `applications')? > > > > I've had it happen a couple times where > > I'll use a module belonging to, say `inets,' > > compiling is just fine, code works locally, > > and release-building is all good too. > > However, I'll ship the release and since > > `inets' wasn't listed in the application > > resource file, at runtime, calling, say > > `httpd_util' module, falls over. > > > > I suppose I'm looking to toggle on something > > in `relx' or even better, `erlc' to Error-out > > when my code calls modules that won't be > > accessible in a release. > > > > -- > > Nato > > > > _______________________________________________ > > 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 me@REDACTED Mon Jul 8 01:32:11 2019 From: me@REDACTED (Nato) Date: Sun, 07 Jul 2019 16:32:11 -0700 Subject: [erlang-questions] releases + warning for application resource file In-Reply-To: <337fc470-6d8c-4424-92a0-ecae57edac50@www.fastmail.com> References: <16bc2f50f6d.6d04a745-1005231713.3369086852325144010@zoho.com> <337fc470-6d8c-4424-92a0-ecae57edac50@www.fastmail.com> Message-ID: <16bcec7dbdf.361e666556859486.-1073721582744673214@zoho.com> Thanks for taking the time to look at this, Tristan. -- Nato From rtrlists@REDACTED Mon Jul 8 18:10:55 2019 From: rtrlists@REDACTED (Robert Raschke) Date: Mon, 8 Jul 2019 18:10:55 +0200 Subject: [erlang-questions] ftp lib behaviour has changed between ftp-1.0.1 and ftp-1.0.2 Message-ID: Hi, I have code that matches on {ok, Result} and {error, Reason} tuples coming from calls to ftp:ls/2 and ftp:recv_bin/2 (on 21.1, ftp-1.0.1) and upgrading to 21.3 (ftp-1.0.2) sometimes returns a simple ok on those calls. This is surprising. 15> f(). ok 16> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), ftp:close(FTP), R. {ok,"-rw-r--r-- 1 2001 2001 174993 Jul 8 17:16 ..."} 17> f(). ok 18> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), ftp:close(FTP), R. ok 19> What might be the reason for this? And is this expected? Cheers, Robby -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlsson.rm@REDACTED Mon Jul 8 22:50:24 2019 From: karlsson.rm@REDACTED (Mikael Karlsson) Date: Mon, 8 Jul 2019 22:50:24 +0200 Subject: [erlang-questions] enif_release_resource and enif_make_resource In-Reply-To: References: Message-ID: Thu 4 juli 2019 16:11 Max Lapshin wrote: > > > I have following code in nif: > > State *s = enif_alloc_resource(..) > enif_self(env, &s->owner); > ERL_NIF_TERM term = enif_make_resource(env, s); > enif_release_resource(s); > return term; > > > Then later another thread (not written by me) is calling my callback > function: > > > void mycallback(void *obj) > { > State *s = obj; > ErlNifEnv *msg_env = enif_alloc_env(); > ERL_NIF_TERM term = enif_make_resource(msg_env, s); > enif_send(NULL, &s->owner, msg_env, term); > enif_free_env(msg_env); > } > > > Is this code correct? > > Should I put release_resource for each make_resource or only for > release_resource? > > Is this calling of enif_send correct? > > I'm afraid that I miss these answers in documentation or cannot find them. > > Your code looks good to me. I only call enif_release_resource for references obtained by enif_alloc_resource. If you check the documentation for enif_release_resource I think it is pretty clear about this. And enif_send looks ok too. Maybe you will have a problem if the pid used in the callback is from the same object you allocated in the previous statement, then I do not think that you shall call enif_release_resource at all. And if you only wan't to keep the pid for a callback maybe enif_alloc is enough too? ErlNifPid* pid = (ErlNifPid*) enif_alloc(sizeof(ErlNifPid)); enif_self(env, pid); ...code to add pid to callback handler.. and do not call enif_free -------------- next part -------------- An HTML attachment was scrubbed... URL: From fchschneider@REDACTED Tue Jul 9 12:51:39 2019 From: fchschneider@REDACTED (Frans Schneider) Date: Tue, 9 Jul 2019 12:51:39 +0200 Subject: [erlang-questions] Any reserved Mnesia table names? Message-ID: <8a475c25-5dde-0647-8a46-1a3c52bd39a1@gmail.com> Hi list, A Mnesia table with the name `user' does only show up in the observer after selecting menu option 'View system tables'. Two questions: - which reserved table names exist and where to find them in the docs? - any harm done when I use a table name like `user'? Thanks, Frans From dszoboszlay@REDACTED Tue Jul 9 15:45:18 2019 From: dszoboszlay@REDACTED (=?UTF-8?Q?D=C3=A1niel_Szoboszlay?=) Date: Tue, 9 Jul 2019 15:45:18 +0200 Subject: [erlang-questions] Any reserved Mnesia table names? In-Reply-To: <8a475c25-5dde-0647-8a46-1a3c52bd39a1@gmail.com> References: <8a475c25-5dde-0647-8a46-1a3c52bd39a1@gmail.com> Message-ID: Hi, Mnesia ram_copies and disc_copies tables are implemented as ETS tables, and therefore share the same namespace with all other ETS tables on the node. Unfortunately, the ETS table names used by applications are typically not documented. Observer has a built-in list of table names used in OTP, but that won't cover table names in in your own/third party applications running on your node of course. Regarding the table name user in particular, I don't think OTP would use this name, so it's safe to use in your Mnesia db. (I don't understand why is the user table on Observer's list, there's a system process called user, but no table with the same name, as far as I know.) If you want to be sure though, try prefixing all your table names with something unique (e.g. myapp_user). Cheers, Daniel On Tue, 9 Jul 2019 at 12:51, Frans Schneider wrote: > Hi list, > > A Mnesia table with the name `user' does only show up in the observer > after selecting menu option 'View system tables'. Two questions: > - which reserved table names exist and where to find them in the docs? > - any harm done when I use a table name like `user'? > Thanks, > > Frans > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fchschneider@REDACTED Tue Jul 9 16:17:45 2019 From: fchschneider@REDACTED (Schneider) Date: Tue, 9 Jul 2019 16:17:45 +0200 Subject: [erlang-questions] Any reserved Mnesia table names? In-Reply-To: References: <8a475c25-5dde-0647-8a46-1a3c52bd39a1@gmail.com> Message-ID: Thanks for the info, especially the list with namens from observer. Frans > Op 9 jul. 2019 om 15:45 heeft D?niel Szoboszlay het volgende geschreven: > > Hi, > > Mnesia ram_copies and disc_copies tables are implemented as ETS tables, and therefore share the same namespace with all other ETS tables on the node. Unfortunately, the ETS table names used by applications are typically not documented. > > Observer has a built-in list of table names used in OTP, but that won't cover table names in in your own/third party applications running on your node of course. > > Regarding the table name user in particular, I don't think OTP would use this name, so it's safe to use in your Mnesia db. (I don't understand why is the user table on Observer's list, there's a system process called user, but no table with the same name, as far as I know.) If you want to be sure though, try prefixing all your table names with something unique (e.g. myapp_user). > > Cheers, > Daniel > >> On Tue, 9 Jul 2019 at 12:51, Frans Schneider wrote: >> Hi list, >> >> A Mnesia table with the name `user' does only show up in the observer >> after selecting menu option 'View system tables'. Two questions: >> - which reserved table names exist and where to find them in the docs? >> - any harm done when I use a table name like `user'? >> Thanks, >> >> Frans >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Tue Jul 9 20:49:38 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 9 Jul 2019 20:49:38 +0200 Subject: [erlang-questions] ftp lib behaviour has changed between ftp-1.0.1 and ftp-1.0.2 In-Reply-To: References: Message-ID: Hi Robert! Well it somewhat unexpected that it returns an undocumented value. It might be that the correction made to fix a timing bug in the FTP application, that was exposed by TLS optimizations when running FTP over TLS, uncovered some other timing bug. Most of the FTP code is very old and I wished for the gen_statem behavior while fixing the bug I just mentioned, so I would not be very surprised if there are more race conditions in that code. Regards Ingela Erlang/OTP team Den m?n 8 juli 2019 kl 18:11 skrev Robert Raschke : > Hi, > > I have code that matches on {ok, Result} and {error, Reason} tuples coming > from calls to ftp:ls/2 and ftp:recv_bin/2 (on 21.1, ftp-1.0.1) and > upgrading to 21.3 (ftp-1.0.2) sometimes returns a simple ok on those calls. > This is surprising. > > 15> f(). > > ok > > 16> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", > "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), > ftp:close(FTP), R. > > {ok,"-rw-r--r-- 1 2001 2001 174993 Jul 8 17:16 ..."} > > 17> f(). > > ok > > 18> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", > "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), > ftp:close(FTP), R. > > ok > > 19> > > > What might be the reason for this? And is this expected? > > > Cheers, > > Robby > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From otp@REDACTED Wed Jul 10 10:18:08 2019 From: otp@REDACTED (Erlang/OTP) Date: Wed, 10 Jul 2019 10:18:08 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released Message-ID: <20190710081807.GA18425@erix.ericsson.se> Patch Package: OTP 22.0.6 Git Tag: OTP-22.0.6 Date: 2019-07-10 Trouble Report Id: OTP-15943, OTP-15945, OTP-15946, OTP-15949, OTP-15952 Seq num: System: OTP Release: 22 Application: compiler-7.4.3, dialyzer-4.0.3, hipe-3.19.1, ssl-9.3.5 Predecessor: OTP 22.0.5 Check out the git tag OTP-22.0.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. --------------------------------------------------------------------- --- POTENTIAL INCOMPATIBILITIES ------------------------------------- --------------------------------------------------------------------- OTP-15949 Application(s): dialyzer, hipe The HiPE compiler would badly miscompile certain try/catch expressions, so it will now refuse to compile modules containing try or catch. As a consequence of this, dialyzer will no longer compile key modules to native code. --------------------------------------------------------------------- --- compiler-7.4.3 -------------------------------------------------- --------------------------------------------------------------------- The compiler-7.4.3 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-15945 Application(s): compiler Fixed an unsafe optimization when matching tuple_size/1 outside of guards, which could crash the emulator if the argument was not a tuple. OTP-15946 Application(s): compiler Fixed a rare bug that could cause the wrong kind of exception to be thrown when a BIF failed in a function that matched bitstrings. OTP-15952 Application(s): compiler Fixed a bug where receive statements inside try/catch blocks could return incorrect results. Full runtime dependencies of compiler-7.4.3: crypto-3.6, erts-9.0, hipe-3.12, kernel-4.0, stdlib-2.5 --------------------------------------------------------------------- --- dialyzer-4.0.3 -------------------------------------------------- --------------------------------------------------------------------- The dialyzer-4.0.3 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-15949 Application(s): dialyzer, hipe *** POTENTIAL INCOMPATIBILITY *** The HiPE compiler would badly miscompile certain try/catch expressions, so it will now refuse to compile modules containing try or catch. As a consequence of this, dialyzer will no longer compile key modules to native code. Full runtime dependencies of dialyzer-4.0.3: compiler-7.0, erts-9.0, hipe-3.16.1, kernel-5.3, stdlib-3.4, syntax_tools-2.0, wx-1.2 --------------------------------------------------------------------- --- hipe-3.19.1 ----------------------------------------------------- --------------------------------------------------------------------- The hipe-3.19.1 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-15949 Application(s): dialyzer, hipe *** POTENTIAL INCOMPATIBILITY *** The HiPE compiler would badly miscompile certain try/catch expressions, so it will now refuse to compile modules containing try or catch. As a consequence of this, dialyzer will no longer compile key modules to native code. Full runtime dependencies of hipe-3.19.1: compiler-5.0, erts-9.3, kernel-5.3, stdlib-3.4, syntax_tools-1.6.14 --------------------------------------------------------------------- --- ssl-9.3.5 ------------------------------------------------------- --------------------------------------------------------------------- The ssl-9.3.5 application can be applied independently of other applications on a full OTP 22 installation. --- Improvements and New Features --- OTP-15943 Application(s): ssl Enhance error handling for erroneous alerts from the peer. Full runtime dependencies of ssl-9.3.5: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From lawrence.ansell@REDACTED Wed Jul 10 12:44:11 2019 From: lawrence.ansell@REDACTED (Lawrence Ansell) Date: Wed, 10 Jul 2019 11:44:11 +0100 Subject: [erlang-questions] Code Elixir LDN Message-ID: Code Elixir LDN is on 18 July. 12 talks and 3 training courses available. Please visit: https://codesync.global/conferences/code-elixir-ldn-2019/ -- Lawrence Ansell Conference Marketing Co-ordinator W: www.codesync.global E: lawrence.ansell@REDACTED -- Code Sync & Erlang Solutions Conferences Code Elixir LDN - London: 18 July 2019 Code BEAM Lite BD - Budapest: 20 September 2019 Code BEAM Lite NYC - NYC: 01 October 2019 RabbitMQ Summit - London: 4 November 2019 Code Mesh LDN - London: 7-8 November 2019 Code BEAM Lite India - Bangalore: 14 November 2019 Code BEAM Lite AMS - Amsterdam: 29 November 2019 Lambda Days - Krak?w: 13-14 February 2020 Code BEAM SF - San Francisco: 5-6 March 2020 *Erlang Solutions cares about your data and privacy; please find all details about the basis for communicating with you and the way we process your data in our?**Privacy Policy* *.You can update your email preferences or opt-out from receiving Marketing emails?here .* -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessvegas@REDACTED Wed Jul 10 16:27:56 2019 From: chessvegas@REDACTED (DOBRO Sergei) Date: Wed, 10 Jul 2019 17:27:56 +0300 Subject: [erlang-questions] Erlang, Chess and Bitboards. Done Message-ID: <9762261562768876@iva1-44bdf084ee9e.qloud-c.yandex.net> Hi all, I found that there was no pure representation of Chess written in Erlang/OTP. So, now I would like to announce my implementation... Binbo. It's available on Github: https://github.com/DOBRO/binbo Binbo is a Chess representation written in pure Erlang using Bitboards. It is basically aimed to be used on game servers where people play chess online. It?s called Binbo because its ground is a binary board containing only zeros and ones (0 and 1) since this is the main meaning of Bitboards as an internal chessboard representation. Binbo also uses the Magic Bitboards approach for a blazing fast move generation of sliding pieces (rook, bishop, and queen). Note: it?s not a chess engine but it could be a good starting point for it. It can play the role of a core (regarding move generation and validation) for multiple chess engines running on distributed Erlang nodes, since Binbo is an OTP application itself. Features: - Blazing fast move generation and validation. - No bottlenecks. Every game is an Erlang process (gen_server) with its own game state. - Ability to create as many concurrent games as many Erlang processes allowed in VM. - Unicode chess symbols support for the board visualization right in Erlang shell. - Ready for use on game servers. Links. ---------- Bitboards: https://www.chessprogramming.org/Bitboards Magic Bitboards: https://www.chessprogramming.org/Magic_Bitboards From essen@REDACTED Wed Jul 10 18:08:28 2019 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Wed, 10 Jul 2019 18:08:28 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: <20190710081807.GA18425@erix.ericsson.se> References: <20190710081807.GA18425@erix.ericsson.se> Message-ID: <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Hello, On 10/07/2019 10:18, Erlang/OTP wrote: > --------------------------------------------------------------------- > --- POTENTIAL INCOMPATIBILITIES ------------------------------------- > --------------------------------------------------------------------- > > OTP-15949 Application(s): dialyzer, hipe > > The HiPE compiler would badly miscompile certain > try/catch expressions, so it will now refuse to compile > modules containing try or catch. > > As a consequence of this, dialyzer will no longer > compile key modules to native code. This means --enable-native-libs is now broken. Results in: hipe.erl: native-code compilation failed because of an unimplemented instruction (catch). That's a bit rough. Is HiPE just going to slowly rot or are there plans to revive it somehow (official or not)? Wondering if I should just give up on testing against it. Cheers, -- Lo?c Hoguin https://ninenines.eu From frank.muller.erl@REDACTED Wed Jul 10 18:23:39 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Wed, 10 Jul 2019 18:23:39 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: Same issue here. With or without HIPE I?m getting this error (Ubuntu 16.04/18.04 and CentOs7): Build failed. make[3]: *** [../ebin/hipe.beam] Error 1 make[3]: Leaving directory '/home/frankm/.kerl/builds/22. 0.6/otp_src_git/lib/hipe/main' /home/frankm/.kerl/builds/22.0.6/otp_src_git/make/otp_subdir.mk:29: recipe for target 'opt' failed make[2]: *** [opt] Error 2 make[2]: Leaving directory '/home/frankm/.kerl/builds/22. 0.6/otp_src_git/lib/hipe' /home/frankm/.kerl/builds/22.0.6/otp_src_git/make/otp_subdir.mk:29: recipe for target 'opt' failed make[1]: *** [opt] Error 2 make[1]: Leaving directory '/home/frankm/.kerl/builds/22. 0.6/otp_src_git/lib' Makefile:490: recipe for target 'libs' failed make: *** [libs] Error 2 Please see /home/frankm/.kerl/builds/22.0.6/otp_build_git.log for full details. while 22.0.5 compiles perfectly. /Frank Hello, > > On 10/07/2019 10:18, Erlang/OTP wrote: > > --------------------------------------------------------------------- > > --- POTENTIAL INCOMPATIBILITIES ------------------------------------- > > --------------------------------------------------------------------- > > > > OTP-15949 Application(s): dialyzer, hipe > > > > The HiPE compiler would badly miscompile certain > > try/catch expressions, so it will now refuse to compile > > modules containing try or catch. > > > > As a consequence of this, dialyzer will no longer > > compile key modules to native code. > > This means --enable-native-libs is now broken. Results in: > > hipe.erl: native-code compilation failed because of an unimplemented > instruction (catch). > > That's a bit rough. > > Is HiPE just going to slowly rot or are there plans to revive it somehow > (official or not)? Wondering if I should just give up on testing against > it. > > Cheers, > > -- > Lo?c Hoguin > https://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Thu Jul 11 00:00:35 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 11 Jul 2019 00:00:35 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On Wed, Jul 10, 2019 at 6:08 PM Lo?c Hoguin wrote: > > OTP-15949 Application(s): dialyzer, hipe > > > > The HiPE compiler would badly miscompile certain > > try/catch expressions, so it will now refuse to compile > > modules containing try or catch. > > > > As a consequence of this, dialyzer will no longer > > compile key modules to native code. > > This means --enable-native-libs is now broken. Results in: > > hipe.erl: native-code compilation failed because of an unimplemented > instruction (catch). > > That's a bit rough. > > Is HiPE just going to slowly rot or are there plans to revive it somehow I had this discussion with Bj?rn from the OTP team at the latest EUC (er, "Code BEAM Sto"). The issue is that the original implementers of HiPE have long since moved on to other things and can't spend time on it any more. At the same time the OTP team is only able to support things their customers care about and pay for. HiPE isn't one of those things. So it's up to the community as a whole to support HiPE, if it wants it. This could take the form of one or more dedicated individuals taking on maintenance of HiPE and fixing issues as they are discovered. (There's at least one such individual working on the bit syntax compilation issue in OTP-22 right now.) Another solution could be for interested parties to fund maintenance via the Erlang Ecosystem Foundation. The try/catch issue is news to me, but since the bit syntax compilation issue was known as OTP-22.0 was released, my view is that OTP should have deprecated HiPE at that point with the understanding that OTP-23 would delete HiPE unless the community stepped up and fixed the issues. (And by that I don't mean "silently don't compile things we can't handle any more".) /Mikael, ex-HiPE developer From mikpelinux@REDACTED Thu Jul 11 00:51:01 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 11 Jul 2019 00:51:01 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On Wed, Jul 10, 2019 at 6:23 PM Frank Muller wrote: > > Same issue here. With or without HIPE I?m getting this error (Ubuntu 16.04/18.04 and CentOs7): > > Build failed. > make[3]: *** [../ebin/hipe.beam] Error 1 > make[3]: Leaving directory '/home/frankm/.kerl/builds/22.0.6/otp_src_git/lib/hipe/main' > /home/frankm/.kerl/builds/22.0.6/otp_src_git/make/otp_subdir.mk:29: recipe for target 'opt' failed > make[2]: *** [opt] Error 2 > make[2]: Leaving directory '/home/frankm/.kerl/builds/22.0.6/otp_src_git/lib/hipe' > /home/frankm/.kerl/builds/22.0.6/otp_src_git/make/otp_subdir.mk:29: recipe for target 'opt' failed > make[1]: *** [opt] Error 2 > make[1]: Leaving directory '/home/frankm/.kerl/builds/22.0.6/otp_src_git/lib' > Makefile:490: recipe for target 'libs' failed > make: *** [libs] Error 2 OTP-22.0.6 builds fine for me, with or without --enable-hipe, only --enable-native-libs doesn't work so don't do that. From petergi@REDACTED Thu Jul 11 07:38:26 2019 From: petergi@REDACTED (Peter J Etheridge) Date: Thu, 11 Jul 2019 15:38:26 +1000 Subject: [erlang-questions] Mnesia folder Message-ID: dear list,having recently discovered that nonode@REDACTED is an error, i now find a folder; Mnesia.nonode@REDACTED containing files; DECISION_TAB.LOGLATEST.LOGetc could this be because i did not name my node? thank you in advance,peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Jul 11 08:12:21 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 11 Jul 2019 08:12:21 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: Mickael What ?-enable-native-libs helps for? /Frank On Wed, Jul 10, 2019 at 6:23 PM Frank Muller > wrote: > > > > Same issue here. With or without HIPE I?m getting this error (Ubuntu > 16.04/18.04 and CentOs7): > > > > Build failed. > > make[3]: *** [../ebin/hipe.beam] Error 1 > > make[3]: Leaving directory > '/home/frankm/.kerl/builds/22.0.6/otp_src_git/lib/hipe/main' > > /home/frankm/.kerl/builds/22.0.6/otp_src_git/make/otp_subdir.mk:29: > recipe for target 'opt' failed > > make[2]: *** [opt] Error 2 > > make[2]: Leaving directory > '/home/frankm/.kerl/builds/22.0.6/otp_src_git/lib/hipe' > > /home/frankm/.kerl/builds/22.0.6/otp_src_git/make/otp_subdir.mk:29: > recipe for target 'opt' failed > > make[1]: *** [opt] Error 2 > > make[1]: Leaving directory > '/home/frankm/.kerl/builds/22.0.6/otp_src_git/lib' > > Makefile:490: recipe for target 'libs' failed > > make: *** [libs] Error 2 > > OTP-22.0.6 builds fine for me, with or without --enable-hipe, only > --enable-native-libs doesn't work so don't do that. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Thu Jul 11 09:43:59 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 11 Jul 2019 09:43:59 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On Thu, Jul 11, 2019 at 8:12 AM Frank Muller wrote: > > Mickael > > What ?-enable-native-libs helps for? If you have HiPE enabled in the VM, this option also compiles (most of) the standard Erlang libraries to native code. From otp@REDACTED Thu Jul 11 11:45:35 2019 From: otp@REDACTED (Erlang/OTP) Date: Thu, 11 Jul 2019 11:45:35 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.7 Released Message-ID: <20190711094535.GA17314@erix.ericsson.se> Patch Package: OTP 22.0.7 Git Tag: OTP-22.0.7 Date: 2019-07-11 Trouble Report Id: OTP-15953 Seq num: ERL-999 System: OTP Release: 22 Application: compiler-7.4.4 Predecessor: OTP 22.0.6 Check out the git tag OTP-22.0.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. --------------------------------------------------------------------- --- compiler-7.4.4 -------------------------------------------------- --------------------------------------------------------------------- The compiler-7.4.4 application can be applied independently of other applications on a full OTP 22 installation. --- Fixed Bugs and Malfunctions --- OTP-15953 Application(s): compiler Related Id(s): ERL-999 Fixed a compiler crash introduced in 22.0.6 (OTP-15952). Full runtime dependencies of compiler-7.4.4: crypto-3.6, erts-9.0, hipe-3.12, kernel-4.0, stdlib-2.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From frank.muller.erl@REDACTED Thu Jul 11 13:21:06 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 11 Jul 2019 13:21:06 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: Even after disabling native-libs it still won?t compile on Ubuntu 16.04/18.04LTS. I tried to disable HIPE as well but without luck. And I?m facing the same problem with 22.0.7 Strange that the compilation broke after 22.0.5 /Frank On Thu, Jul 11, 2019 at 8:12 AM wrote: > > > > Mickael > > > > What ?-enable-native-libs helps for? > > If you have HiPE enabled in the VM, this option also compiles (most > of) the standard Erlang libraries to native code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Jul 11 13:28:19 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 11 Jul 2019 13:28:19 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.7 Released In-Reply-To: <20190711094535.GA17314@erix.ericsson.se> References: <20190711094535.GA17314@erix.ericsson.se> Message-ID: Won?t compile on Ubuntu 16.04/18.04LTS after disabling native-libs and even HIPE /Frank Le jeu. 11 juil. 2019 ? 11:45, Erlang/OTP a ?crit : > Patch Package: OTP 22.0.7 > Git Tag: OTP-22.0.7 > Date: 2019-07-11 > Trouble Report Id: OTP-15953 > Seq num: ERL-999 > System: OTP > Release: 22 > Application: compiler-7.4.4 > Predecessor: OTP 22.0.6 > > Check out the git tag OTP-22.0.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. > > --------------------------------------------------------------------- > --- compiler-7.4.4 -------------------------------------------------- > --------------------------------------------------------------------- > > The compiler-7.4.4 application can be applied independently of other > applications on a full OTP 22 installation. > > --- Fixed Bugs and Malfunctions --- > > OTP-15953 Application(s): compiler > Related Id(s): ERL-999 > > Fixed a compiler crash introduced in 22.0.6 > (OTP-15952). > > > Full runtime dependencies of compiler-7.4.4: crypto-3.6, erts-9.0, > hipe-3.12, kernel-4.0, stdlib-2.5 > > > --------------------------------------------------------------------- > --------------------------------------------------------------------- > --------------------------------------------------------------------- > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Thu Jul 11 15:36:10 2019 From: john@REDACTED (John =?ISO-8859-1?Q?H=F6gberg?=) Date: Thu, 11 Jul 2019 15:36:10 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.7 Released In-Reply-To: References: <20190711094535.GA17314@erix.ericsson.se> Message-ID: <481a43ec81eed4f61c5d781a2c016aca30d85100.camel@erlang.org> What commands do you use to build? What's the full error message? I hope there's more to it than "Build failed. Error 1." /John On Thu, 2019-07-11 at 13:28 +0200, Frank Muller wrote: > Won?t compile on Ubuntu 16.04/18.04LTS after disabling native-libs > and even HIPE > > > /Frank > > Le jeu. 11 juil. 2019 ? 11:45, Erlang/OTP a ?crit : > > Patch Package: OTP 22.0.7 > > > > Git Tag: OTP-22.0.7 > > > > Date: 2019-07-11 > > > > Trouble Report Id: OTP-15953 > > > > Seq num: ERL-999 > > > > System: OTP > > > > Release: 22 > > > > Application: compiler-7.4.4 > > > > Predecessor: OTP 22.0.6 > > > > > > > > Check out the git tag OTP-22.0.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. > > > > > > > > ---------------------------------------------------------------- > > ----- > > > > --- compiler-7.4.4 --------------------------------------------- > > ----- > > > > ---------------------------------------------------------------- > > ----- > > > > > > > > The compiler-7.4.4 application can be applied independently of > > other > > > > applications on a full OTP 22 installation. > > > > > > > > --- Fixed Bugs and Malfunctions --- > > > > > > > > OTP-15953 Application(s): compiler > > > > Related Id(s): ERL-999 > > > > > > > > Fixed a compiler crash introduced in 22.0.6 > > > > (OTP-15952). > > > > > > > > > > > > Full runtime dependencies of compiler-7.4.4: crypto-3.6, erts-9.0, > > > > hipe-3.12, kernel-4.0, stdlib-2.5 > > > > > > > > > > > > ---------------------------------------------------------------- > > ----- > > > > ---------------------------------------------------------------- > > ----- > > > > ---------------------------------------------------------------- > > ----- > > > > > > > > _______________________________________________ > > > > erlang-questions mailing list > > > > erlang-questions@REDACTED > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________erlang-questions > mailing listerlang-questions@REDACTED > https://protect2.fireeye.com/url?k=40394e45-1cb0e186-40390ede-0cc47ad93d36-e3578889b6566760&q=1&u=http%3A%2F%2Ferlang.org%2Fmailman%2Flistinfo%2Ferlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From markalanj@REDACTED Thu Jul 11 16:00:58 2019 From: markalanj@REDACTED (Mark Jones) Date: Thu, 11 Jul 2019 09:00:58 -0500 Subject: [erlang-questions] Patch Package OTP 22.0.7 Released In-Reply-To: References: <20190711094535.GA17314@erix.ericsson.se> Message-ID: I compiled both 22.0.6 and 22.0.7 without error on Ubuntu 18.04 LTS including a cross compile to my embedded ARM target. For the x86-64 Ubuntu build I use asdf and the Erlang plugin with all default options. I don't use HIPE but my when I run erl I can see HIPE is available. My embedded ARM target which runs a customized Linux build I use the otp_build script with a customized configuration file. /Mark On Thu, Jul 11, 2019 at 6:28 AM Frank Muller wrote: > Won?t compile on Ubuntu 16.04/18.04LTS after disabling native-libs and > even HIPE > > /Frank > > Le jeu. 11 juil. 2019 ? 11:45, Erlang/OTP a ?crit : > >> Patch Package: OTP 22.0.7 >> Git Tag: OTP-22.0.7 >> Date: 2019-07-11 >> Trouble Report Id: OTP-15953 >> Seq num: ERL-999 >> System: OTP >> Release: 22 >> Application: compiler-7.4.4 >> Predecessor: OTP 22.0.6 >> >> Check out the git tag OTP-22.0.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. >> >> --------------------------------------------------------------------- >> --- compiler-7.4.4 -------------------------------------------------- >> --------------------------------------------------------------------- >> >> The compiler-7.4.4 application can be applied independently of other >> applications on a full OTP 22 installation. >> >> --- Fixed Bugs and Malfunctions --- >> >> OTP-15953 Application(s): compiler >> Related Id(s): ERL-999 >> >> Fixed a compiler crash introduced in 22.0.6 >> (OTP-15952). >> >> >> Full runtime dependencies of compiler-7.4.4: crypto-3.6, erts-9.0, >> hipe-3.12, kernel-4.0, stdlib-2.5 >> >> >> --------------------------------------------------------------------- >> --------------------------------------------------------------------- >> --------------------------------------------------------------------- >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Jul 11 19:50:01 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 11 Jul 2019 19:50:01 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.7 Released In-Reply-To: References: <20190711094535.GA17314@erix.ericsson.se> Message-ID: The issue was when you ?enable-threads. This option automatically set ?enable-native-threads. Everything works now as expected. Can someone please confirms this behaviour when setting ?enable-threads? /Frank I compiled both 22.0.6 and 22.0.7 without error on Ubuntu 18.04 LTS > including a cross compile to my embedded ARM target. For the x86-64 Ubuntu > build I use asdf and the Erlang plugin with all default options. I don't > use HIPE but my when I run erl I can see HIPE is available. My embedded ARM > target which runs a customized Linux build I use the otp_build script with > a customized configuration file. > > /Mark > > On Thu, Jul 11, 2019 at 6:28 AM Frank Muller > wrote: > >> Won?t compile on Ubuntu 16.04/18.04LTS after disabling native-libs and >> even HIPE >> >> /Frank >> >> Le jeu. 11 juil. 2019 ? 11:45, Erlang/OTP a ?crit : >> >>> Patch Package: OTP 22.0.7 >>> Git Tag: OTP-22.0.7 >>> Date: 2019-07-11 >>> Trouble Report Id: OTP-15953 >>> Seq num: ERL-999 >>> System: OTP >>> Release: 22 >>> Application: compiler-7.4.4 >>> Predecessor: OTP 22.0.6 >>> >>> Check out the git tag OTP-22.0.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. >>> >>> --------------------------------------------------------------------- >>> --- compiler-7.4.4 -------------------------------------------------- >>> --------------------------------------------------------------------- >>> >>> The compiler-7.4.4 application can be applied independently of other >>> applications on a full OTP 22 installation. >>> >>> --- Fixed Bugs and Malfunctions --- >>> >>> OTP-15953 Application(s): compiler >>> Related Id(s): ERL-999 >>> >>> Fixed a compiler crash introduced in 22.0.6 >>> (OTP-15952). >>> >>> >>> Full runtime dependencies of compiler-7.4.4: crypto-3.6, erts-9.0, >>> hipe-3.12, kernel-4.0, stdlib-2.5 >>> >>> >>> --------------------------------------------------------------------- >>> --------------------------------------------------------------------- >>> --------------------------------------------------------------------- >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Jul 11 19:53:22 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 11 Jul 2019 19:53:22 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: Mik?l I don?t use HIPE in my case. Can i disable it and set back ?enable-native-libs? It seems like ?enable-native-libs makes the VM faster and I don?t want to lose that. Am i right or wrong? /Frank Le jeu. 11 juil. 2019 ? 13:21, Frank Muller a ?crit : > Even after disabling native-libs it still won?t compile on Ubuntu > 16.04/18.04LTS. > > I tried to disable HIPE as well but without luck. > > And I?m facing the same problem with 22.0.7 > > Strange that the compilation broke after 22.0.5 > > /Frank > > > On Thu, Jul 11, 2019 at 8:12 AM wrote: >> > >> > Mickael >> > >> > What ?-enable-native-libs helps for? >> >> If you have HiPE enabled in the VM, this option also compiles (most >> of) the standard Erlang libraries to native code. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Thu Jul 11 20:07:48 2019 From: rickard@REDACTED (Rickard Green) Date: Thu, 11 Jul 2019 20:07:48 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.7 Released In-Reply-To: References: <20190711094535.GA17314@erix.ericsson.se> Message-ID: On Thu, Jul 11, 2019 at 7:50 PM Frank Muller wrote: > The issue was when you ?enable-threads. > This option automatically set ?enable-native-threads. > > Everything works now as expected. > > Can someone please confirms this behaviour when setting ?enable-threads? > > No --enable-threads does not imply --enable-native-threads. -- Rickard Green, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Thu Jul 11 20:10:42 2019 From: rickard@REDACTED (Rickard Green) Date: Thu, 11 Jul 2019 20:10:42 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On Thu, Jul 11, 2019 at 7:53 PM Frank Muller wrote: > Mik?l > > I don?t use HIPE in my case. Can i disable it and set back > ?enable-native-libs? > > --enable-native-libs needs hipe, and you don't want to use --enable-native-libs as it is now. -- Rickard Green, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Thu Jul 11 20:15:05 2019 From: rickard@REDACTED (Rickard Green) Date: Thu, 11 Jul 2019 20:15:05 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.7 Released In-Reply-To: References: <20190711094535.GA17314@erix.ericsson.se> Message-ID: On Thu, Jul 11, 2019 at 8:07 PM Rickard Green wrote: > > > On Thu, Jul 11, 2019 at 7:50 PM Frank Muller > wrote: > >> The issue was when you ?enable-threads. >> This option automatically set ?enable-native-threads. >> >> Everything works now as expected. >> >> Can someone please confirms this behaviour when setting ?enable-threads? >> >> > No --enable-threads does not imply --enable-native-threads. > > -- > Rickard Green, Erlang/OTP, Ericsson AB > Correction: No, --enable-threads does not imply --enable-native-libs --enable-native-threads does not exit :-p -- Rickard Green, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Jul 11 20:27:33 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 11 Jul 2019 20:27:33 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: Got it, thanks! > On Thu, Jul 11, 2019 at 7:53 PM Frank Muller > wrote: > >> Mik?l >> >> I don?t use HIPE in my case. Can i disable it and set back >> ?enable-native-libs? >> >> > --enable-native-libs needs hipe, and you don't want to use > --enable-native-libs as it is now. > > > -- > Rickard Green, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.muller.erl@REDACTED Thu Jul 11 20:33:24 2019 From: frank.muller.erl@REDACTED (Frank Muller) Date: Thu, 11 Jul 2019 20:33:24 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.7 Released In-Reply-To: References: <20190711094535.GA17314@erix.ericsson.se> Message-ID: i meant ?enable-native-libs Rickard > > On Thu, Jul 11, 2019 at 8:07 PM Rickard Green wrote: > >> >> >> On Thu, Jul 11, 2019 at 7:50 PM Frank Muller >> wrote: >> >>> The issue was when you ?enable-threads. >>> This option automatically set ?enable-native-threads. >>> >>> Everything works now as expected. >>> >>> Can someone please confirms this behaviour when setting ?enable-threads? >>> >>> >> No --enable-threads does not imply --enable-native-threads. >> >> -- >> Rickard Green, Erlang/OTP, Ericsson AB >> > > Correction: No, --enable-threads does not imply --enable-native-libs > > --enable-native-threads does not exit :-p > > > -- > Rickard Green, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dszoboszlay@REDACTED Thu Jul 11 23:30:44 2019 From: dszoboszlay@REDACTED (=?UTF-8?Q?D=C3=A1niel_Szoboszlay?=) Date: Thu, 11 Jul 2019 23:30:44 +0200 Subject: [erlang-questions] Mnesia folder In-Reply-To: References: Message-ID: This directory was created because you once called mnesia:create_schema/1 on a node called nonode@REDACTED (that is, on a non-distributed node). By the way, nonode@REDACTED is not really an error, per se. Every Erlang node has a name (see erlang:node/0 ). For distributed nodes the name is important, because other nodes can find and connect to it via its name. But there can be non-distributed nodes too. They don't listen to incoming connections and don't attempt to connect to other nodes either. So their name is completely irrelevant, and by definition they are always called nonode@REDACTED (It is also possible to stop and start distribution on a node without stopping it. If you do so, it will change its name.) Now, the documentation sometimes calls nodes where distribution is running " *alive*, and nodes where it is stopped "*not alive"*. These names may be a bit confusing. A "not alive" node is still alive in the sense that it is running and executing code. It is just not accessible to other nodes via the Erlang distribution protocol. Back to Mnesia: Mnesia allows you to create a distributed database, but it can work perfectly on a single node as well. So it's even valid to use Mnesia on a non-distributed node. If you do so, you will get the directory you found. Of course, if you no longer want to use non-distributed nodes and don't need this DB instance, you can just delete it now. Cheers, Daniel On Thu, 11 Jul 2019 at 07:39, Peter J Etheridge wrote: > dear list, > having recently discovered that nonode@REDACTED is an error, i now find a > folder; > > Mnesia.nonode@REDACTED > > containing files; > > DECISION_TAB.LOG > LATEST.LOG > etc > > could this be because i did not name my node? > > thank you in advance, > peter > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Fri Jul 12 10:43:33 2019 From: rtrlists@REDACTED (Robert Raschke) Date: Fri, 12 Jul 2019 10:43:33 +0200 Subject: [erlang-questions] ftp lib behaviour has changed between ftp-1.0.1 and ftp-1.0.2 In-Reply-To: References: Message-ID: Hi Ingela, I just had a case of ftp:recv_bin(FTP, "filename") repeatedly returned only 'ok'. That is, my hoped for workaround of simply retrying the operation fails. This makes version 1.0.2 of the ftp lib unusable, I'm afraid. I will have to revert to an earlier version. Cheers, Robby On Tue, 9 Jul 2019 at 20:49, Ingela Andin wrote: > Hi Robert! > > Well it somewhat unexpected that it returns an undocumented value. It > might be that the correction made to fix a timing bug in the FTP > application, that > was exposed by TLS optimizations when running FTP over TLS, uncovered some > other timing bug. Most of the FTP code is very old and I wished for the > gen_statem behavior while fixing the bug I just mentioned, so I would not > be very surprised if there are more race conditions in that code. > > Regards Ingela Erlang/OTP team > > Den m?n 8 juli 2019 kl 18:11 skrev Robert Raschke >: > >> Hi, >> >> I have code that matches on {ok, Result} and {error, Reason} tuples >> coming from calls to ftp:ls/2 and ftp:recv_bin/2 (on 21.1, ftp-1.0.1) and >> upgrading to 21.3 (ftp-1.0.2) sometimes returns a simple ok on those calls. >> This is surprising. >> >> 15> f(). >> >> ok >> >> 16> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", >> "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), >> ftp:close(FTP), R. >> >> {ok,"-rw-r--r-- 1 2001 2001 174993 Jul 8 17:16 ..."} >> >> 17> f(). >> >> ok >> >> 18> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", >> "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), >> ftp:close(FTP), R. >> >> ok >> >> 19> >> >> >> What might be the reason for this? And is this expected? >> >> >> Cheers, >> >> Robby >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Fri Jul 12 11:52:24 2019 From: ingela.andin@REDACTED (Ingela Andin) Date: Fri, 12 Jul 2019 11:52:24 +0200 Subject: [erlang-questions] ftp lib behaviour has changed between ftp-1.0.1 and ftp-1.0.2 In-Reply-To: References: Message-ID: Hi Robert! Can you provide a reliable way to reproduce the problem it will help getting it fixed. Have you tried to run our ftp test suite? It passes in our tests runs. The possible bug might be server dependent. Could you report it at https://bugs.erlang.org/ Regards Ingela Erlang/OTP Team - Ericsson AB Den fre 12 juli 2019 kl 10:43 skrev Robert Raschke : > Hi Ingela, > > I just had a case of ftp:recv_bin(FTP, "filename") repeatedly returned > only 'ok'. > That is, my hoped for workaround of simply retrying the operation fails. > > This makes version 1.0.2 of the ftp lib unusable, I'm afraid. > I will have to revert to an earlier version. > > Cheers, > Robby > > > On Tue, 9 Jul 2019 at 20:49, Ingela Andin wrote: > >> Hi Robert! >> >> Well it somewhat unexpected that it returns an undocumented value. It >> might be that the correction made to fix a timing bug in the FTP >> application, that >> was exposed by TLS optimizations when running FTP over TLS, uncovered >> some other timing bug. Most of the FTP code is very old and I wished for >> the gen_statem behavior while fixing the bug I just mentioned, so I would >> not be very surprised if there are more race conditions in that code. >> >> Regards Ingela Erlang/OTP team >> >> Den m?n 8 juli 2019 kl 18:11 skrev Robert Raschke < >> rtrlists@REDACTED>: >> >>> Hi, >>> >>> I have code that matches on {ok, Result} and {error, Reason} tuples >>> coming from calls to ftp:ls/2 and ftp:recv_bin/2 (on 21.1, ftp-1.0.1) and >>> upgrading to 21.3 (ftp-1.0.2) sometimes returns a simple ok on those calls. >>> This is surprising. >>> >>> 15> f(). >>> >>> ok >>> >>> 16> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", >>> "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), >>> ftp:close(FTP), R. >>> >>> {ok,"-rw-r--r-- 1 2001 2001 174993 Jul 8 17:16 ..."} >>> >>> 17> f(). >>> >>> ok >>> >>> 18> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", >>> "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), >>> ftp:close(FTP), R. >>> >>> ok >>> >>> 19> >>> >>> >>> What might be the reason for this? And is this expected? >>> >>> >>> Cheers, >>> >>> Robby >>> >>> >>> _______________________________________________ >>> 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 Fri Jul 12 11:57:47 2019 From: otp@REDACTED (Erlang/OTP) Date: Fri, 12 Jul 2019 11:57:47 +0200 Subject: [erlang-questions] Patch Package OTP 21.3.8.6 Released Message-ID: <20190712095747.GA51830@erix.ericsson.se> Patch Package: OTP 21.3.8.6 Git Tag: OTP-21.3.8.6 Date: 2019-07-12 Trouble Report Id: OTP-15328 Seq num: ERIERL-379 System: OTP Release: 21 Application: ssl-9.2.3.5 Predecessor: OTP 21.3.8.5 Check out the git tag OTP-21.3.8.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.3.5 ----------------------------------------------------- --------------------------------------------------------------------- The ssl-9.2.3.5 application can be applied independently of other applications on a full OTP 21 installation. --- Fixed Bugs and Malfunctions --- OTP-15328 Application(s): ssl Related Id(s): ERIERL-379 Handling of zero size fragments in TLS could cause an infinite loop. This has now been corrected. Full runtime dependencies of ssl-9.2.3.5: crypto-4.2, erts-10.0, inets-5.10.7, kernel-6.0, public_key-1.5, stdlib-3.5 --------------------------------------------------------------------- --------------------------------------------------------------------- --------------------------------------------------------------------- From list1@REDACTED Fri Jul 12 12:57:19 2019 From: list1@REDACTED (Grzegorz Junka) Date: Fri, 12 Jul 2019 10:57:19 +0000 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On 10/07/2019 22:00, Mikael Pettersson wrote: > On Wed, Jul 10, 2019 at 6:08 PM Lo?c Hoguin wrote: >>> OTP-15949 Application(s): dialyzer, hipe >>> >>> The HiPE compiler would badly miscompile certain >>> try/catch expressions, so it will now refuse to compile >>> modules containing try or catch. >>> >>> As a consequence of this, dialyzer will no longer >>> compile key modules to native code. >> This means --enable-native-libs is now broken. Results in: >> >> hipe.erl: native-code compilation failed because of an unimplemented >> instruction (catch). >> >> That's a bit rough. >> >> Is HiPE just going to slowly rot or are there plans to revive it somehow > I had this discussion with Bj?rn from the OTP team at the latest EUC > (er, "Code BEAM Sto"). > > The issue is that the original implementers of HiPE have long since > moved on to other things > and can't spend time on it any more. At the same time the OTP team is only able > to support things their customers care about and pay for. HiPE isn't > one of those things. > > So it's up to the community as a whole to support HiPE, if it wants > it. This could take the > form of one or more dedicated individuals taking on maintenance of > HiPE and fixing issues > as they are discovered. (There's at least one such individual working > on the bit syntax > compilation issue in OTP-22 right now.) Another solution could be for > interested parties to > fund maintenance via the Erlang Ecosystem Foundation. > > The try/catch issue is news to me, but since the bit syntax > compilation issue was known > as OTP-22.0 was released, my view is that OTP should have deprecated > HiPE at that point > with the understanding that OTP-23 would delete HiPE unless the > community stepped up > and fixed the issues. (And by that I don't mean "silently don't > compile things we can't handle > any more".) > > /Mikael, ex-HiPE developer Mikael, would it be possible for you or someone else from the OTP team to provide more details about the minimal amount of work required to bring HiPE back to the working order? I am looking for things like: 1. Any test suites available for HiPE (I would expect some tests not passing due to recent changes) 2. Documentation detailing the HiPE implementation (if available) 3. New features that the new compiler no longer compiles for HiPE 4. Planned features that will require support in the compiler in the foreseeable future Also, is the HiPE code tightly integrated with OTP and its compiler or it could be extracted into a separate repo and maintained at its own peace? Thanks GrzegorzJ From okaprinarjaya@REDACTED Sat Jul 13 00:21:56 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sat, 13 Jul 2019 05:21:56 +0700 Subject: [erlang-questions] nonode@nohost In-Reply-To: References: Message-ID: Hi, You need to start erlang shell as a named node by using this command: erl -sname any_node_name Then you can read http://erlang.org/doc/design_principles/distributed_applications.html for more details Hope it helps Pada tanggal Sen, 1 Jul 2019 pukul 15.36 Peter J Etheridge < petergi@REDACTED> menulis: > dear friends, > i am trying to send a record from my wx module to mnesia module. > > the error message i receive is; > > node_not_started, nonode@REDACTED > > some reading of the manual mentions that nonode@REDACTED is an error > message. > (self explanatory in hindsight.) > > which module of the manual (or other resource) should a beginner read for > instructions to correctly set up a node? > > thank you in advance, > peter > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petergi@REDACTED Sat Jul 13 09:07:51 2019 From: petergi@REDACTED (Peter J Etheridge) Date: Sat, 13 Jul 2019 17:07:51 +1000 Subject: [erlang-questions] Mnesia folder In-Reply-To: Message-ID: <34a78ad75811bcbfe696b0556cbc8d041e157b12@mail.iinet.net.au> Dear Daniel, Noticing references in the manual without explanation, I had spent quite some time on search engines trying to understand nonode@REDACTED It is starting to make sense now i have read your answer Thank you, Daniel ! Happy coding,Peter ----- Original Message ----- From: "D?niel Szoboszlay" To:"Peter J Etheridge" Cc:"erlang-questions" Sent:Thu, 11 Jul 2019 23:30:44 +0200 Subject:Re: [erlang-questions] Mnesia folder This directory was created because you once called mnesia:create_schema/1 on a node called nonode@REDACTED (that is, on a non-distributed node). By the way,?nonode@REDACTED?is not really an error, per se. Every Erlang node has a name (see erlang:node/0 [1]). For distributed nodes the name is important, because other nodes can find and connect to it via its name. But there can be non-distributed nodes too. They don't listen to incoming connections and don't attempt to connect to other nodes either. So their name is completely irrelevant, and by definition they are always called?nonode@REDACTED (It is also possible to stop [2] and start [3] distribution on a node without stopping it. If you do so, it will change its name.) Now, the documentation sometimes calls nodes where distribution is running "_alive_, and nodes where it is stopped "_not alive"_ These names may be a bit confusing. A "not alive" node is still alive in the sense that it is running and executing code. It is just not accessible to other nodes via the Erlang distribution protocol. Back to Mnesia: Mnesia allows you to create a distributed database, but it can work perfectly on a single node as well. So it's even valid to use Mnesia on a non-distributed node. If you do so, you will get the directory you found. Of course, if you no longer want to use non-distributed nodes and don't need this DB instance, you can just delete it now. Cheers,Daniel On Thu, 11 Jul 2019 at 07:39, Peter J Etheridge wrote: dear list,having recently discovered that nonode@REDACTED is an error, i now find a folder; Mnesia.nonode@REDACTED containing files; DECISION_TAB.LOGLATEST.LOGetc could this be because i did not name my node? thank you in advance,peter _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED [5] http://erlang.org/mailman/listinfo/erlang-questions [6] Links: ------ [1] http://erlang.org/doc/man/erlang.html#node-0 [2] http://erlang.org/doc/man/net_kernel.html#stop-0 [3] http://erlang.org/doc/man/net_kernel.html#start-1 [4] mailto:petergi@REDACTED [5] mailto:erlang-questions@REDACTED [6] http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From okaprinarjaya@REDACTED Sat Jul 13 10:46:39 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sat, 13 Jul 2019 15:46:39 +0700 Subject: [erlang-questions] How to quick calculation max Erlang's processes and scheduler can alive based on machine specs Message-ID: Hi, I'm a super newbie, I had done very very simple parallel processing using erlang. I experimenting with my database containing about hundreds of thousands rows. I split the rows into different offsets then assign each worker-processes different rows based on offsets. For each row i doing simple similar text calculation using binary:longest_common_prefix/1 Let's assume my total rows is 200,000 rows of data. At first, i try to create 10 worker-processes, i assign 20,000 rows at each worker-process. Second, i try to create 20 worker-processes, i assign 10,000 rows at each worker-process. Third, i try to create 40 worker-processes, i assign 5000 rows at each worker-process. My machine specs: - MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports) - Processor 3,1 GHz Intel Core i5 ( 2 physical cores, with HT ) - RAM 8 GB 2133 MHz LPDDR3 My questions is 1. How to quick calculation / dumb / simple calculation max Erlang's processes based on above machine specs? 2. The running time when doing similar text processing with 10 worker, or 20 worker or 40 worker was very blazingly fast. So i cannot feel, i cannot see the difference. How to measure or something like printing total minutes out? So i can see the difference. 3. How many scheduler need to active / available when i create 10 processes? or 20 processes? 40 processes? and so on.. Please enlightenment Thank you super much -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Sat Jul 13 14:36:31 2019 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sat, 13 Jul 2019 22:36:31 +1000 Subject: [erlang-questions] CutEr maps Message-ID: Hello all, I've been experimenting with the wonderful concolic testing tool CutEr [1]. Unless I'm using it wrong, it would appear that CutEr does not yet support maps. When it was first released, it was said that this feature was in the works. Is there a roadmap for this? CutEr contributers? Thanks in advance. [1] https://github.com/cuter-testing/cuter - Edmond - -- Using Opera's mail client: http://www.opera.com/mail/ From tty.erlang@REDACTED Sat Jul 13 19:17:39 2019 From: tty.erlang@REDACTED (T Ty) Date: Sat, 13 Jul 2019 18:17:39 +0100 Subject: [erlang-questions] How to quick calculation max Erlang's processes and scheduler can alive based on machine specs In-Reply-To: References: Message-ID: The only suggestion I have is to also run a test where you use 200,000 workers i.e. a worker per row by spawning a process per row instead of managing the partitioning. For measuring running times you can use timer:tc/3 On Sat, Jul 13, 2019 at 9:47 AM I Gusti Ngurah Oka Prinarjaya < okaprinarjaya@REDACTED> wrote: > Hi, > > I'm a super newbie, I had done very very simple parallel processing using > erlang. I experimenting with my database containing about hundreds of > thousands rows. I split the rows into different offsets then assign each > worker-processes different rows based on offsets. For each row i doing > simple similar text calculation using binary:longest_common_prefix/1 > > Let's assume my total rows is 200,000 rows of data. > At first, i try to create 10 worker-processes, i assign 20,000 rows at > each worker-process. > Second, i try to create 20 worker-processes, i assign 10,000 rows at each > worker-process. > Third, i try to create 40 worker-processes, i assign 5000 rows at each > worker-process. > > My machine specs: > - MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports) > - Processor 3,1 GHz Intel Core i5 ( 2 physical cores, with HT ) > - RAM 8 GB 2133 MHz LPDDR3 > > My questions is > > 1. How to quick calculation / dumb / simple calculation max Erlang's > processes based on above machine specs? > > 2. The running time when doing similar text processing with 10 worker, or > 20 worker or 40 worker was very blazingly fast. So i cannot feel, i cannot > see the difference. How to measure or something like printing total minutes > out? So i can see the difference. > > 3. How many scheduler need to active / available when i create 10 > processes? or 20 processes? 40 processes? and so on.. > > Please enlightenment > > Thank you super much > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dszoboszlay@REDACTED Sat Jul 13 22:36:09 2019 From: dszoboszlay@REDACTED (=?UTF-8?Q?D=C3=A1niel_Szoboszlay?=) Date: Sat, 13 Jul 2019 22:36:09 +0200 Subject: [erlang-questions] How to quick calculation max Erlang's processes and scheduler can alive based on machine specs In-Reply-To: References: Message-ID: Your second and third questions are easy to answer: measure the execution time of functions with timer:tc and even with a single scheduler you can run as many processes as you want. They will compete for a single core though, and will have to wait a long time to get some CPU time once scheduled out. So just stick to the default, and use as many schedulers as many cores you have. Now, finding the maximum (or rather: optimal) number of processes to perform this particular task on your particular machine is hard. A very dumb calculation would be that because all of the processes will be doing the same, CPU-bound task, they will all compete for the same HW resources, so you won't gain much by having more processes than CPU cores (4 in your case). If accessing the rows involves some I/O, than you should use more processes, so some processes can run the CPU-bound text calculations while others wait for I/O. Try experimenting with different number of processes while monitoring the scheduler utilisation (e.g. with observer): if you're much below 100% utilisation (across all schedulers), you have too few, If, on the other hand, you see the run queue going up (the number of runnable processes that are waiting for a CPU slice to run), you have too many. But you can safely use a bit more processes than the minimum needed to saturate the CPU. It can even speed up the whole job a bit if not all rows take equal time to process (consider one process getting a chunk of super slow to process rows: at the end of all other processes will have finished and you'll have to wait for this big worker to do its work on a single core; having twice as many processes would cut the chunk into two halves, also halving the time to wait at the end). However, after one (hard to find) point adding more processes would hurt performance: more processes means more cache misses and more synchronisation overhead at the beginning and end of the job. The theoretical maximum number of processes is probably constrained by your RAM: measure how much memory one process needs, and divide 8 GB (minus some for the OS and other programs) with this number. You won't be able to fit more processes in RAM, and swapping will only slow down your computation. But this limit is probably in the thousands of processes range. Hope this helps, Daniel On Sat, 13 Jul 2019 at 10:47, I Gusti Ngurah Oka Prinarjaya < okaprinarjaya@REDACTED> wrote: > Hi, > > I'm a super newbie, I had done very very simple parallel processing using > erlang. I experimenting with my database containing about hundreds of > thousands rows. I split the rows into different offsets then assign each > worker-processes different rows based on offsets. For each row i doing > simple similar text calculation using binary:longest_common_prefix/1 > > Let's assume my total rows is 200,000 rows of data. > At first, i try to create 10 worker-processes, i assign 20,000 rows at > each worker-process. > Second, i try to create 20 worker-processes, i assign 10,000 rows at each > worker-process. > Third, i try to create 40 worker-processes, i assign 5000 rows at each > worker-process. > > My machine specs: > - MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports) > - Processor 3,1 GHz Intel Core i5 ( 2 physical cores, with HT ) > - RAM 8 GB 2133 MHz LPDDR3 > > My questions is > > 1. How to quick calculation / dumb / simple calculation max Erlang's > processes based on above machine specs? > > 2. The running time when doing similar text processing with 10 worker, or > 20 worker or 40 worker was very blazingly fast. So i cannot feel, i cannot > see the difference. How to measure or something like printing total minutes > out? So i can see the difference. > > 3. How many scheduler need to active / available when i create 10 > processes? or 20 processes? 40 processes? and so on.. > > Please enlightenment > > Thank you super much > > > > > > _______________________________________________ > 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 Jul 14 08:24:30 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Sun, 14 Jul 2019 13:24:30 +0700 Subject: [erlang-questions] How to quick calculation max Erlang's processes and scheduler can alive based on machine specs In-Reply-To: References: Message-ID: Hi D?niel, >> Try experimenting with different number of processes while monitoring the scheduler utilisation (e.g. with observer): if you're much below 100% utilisation (across all >> schedulers), you have too few I am lucky, i always get 100% utilisation >> If, on the other hand, you see the run queue going up (the number of runnable processes that are waiting for a CPU slice to run), you have too many. Where to see this? Thank you :) Pada tanggal Min, 14 Jul 2019 pukul 03.36 D?niel Szoboszlay < dszoboszlay@REDACTED> menulis: > Your second and third questions are easy to answer: measure the execution > time of functions with timer:tc and even with a single scheduler you can > run as many processes as you want. They will compete for a single core > though, and will have to wait a long time to get some CPU time once > scheduled out. So just stick to the default, and use as many schedulers as > many cores you have. > > Now, finding the maximum (or rather: optimal) number of processes to > perform this particular task on your particular machine is hard. A very > dumb calculation would be that because all of the processes will be doing > the same, CPU-bound task, they will all compete for the same HW resources, > so you won't gain much by having more processes than CPU cores (4 in your > case). If accessing the rows involves some I/O, than you should use more > processes, so some processes can run the CPU-bound text calculations while > others wait for I/O. Try experimenting with different number of processes > while monitoring the scheduler utilisation (e.g. with observer): if you're > much below 100% utilisation (across all schedulers), you have too few, If, > on the other hand, you see the run queue going up (the number of runnable > processes that are waiting for a CPU slice to run), you have too many. > > But you can safely use a bit more processes than the minimum needed to > saturate the CPU. It can even speed up the whole job a bit if not all rows > take equal time to process (consider one process getting a chunk of super > slow to process rows: at the end of all other processes will have finished > and you'll have to wait for this big worker to do its work on a single > core; having twice as many processes would cut the chunk into two halves, > also halving the time to wait at the end). However, after one (hard to > find) point adding more processes would hurt performance: more processes > means more cache misses and more synchronisation overhead at the beginning > and end of the job. > > The theoretical maximum number of processes is probably constrained by > your RAM: measure how much memory one process needs, and divide 8 GB (minus > some for the OS and other programs) with this number. You won't be able to > fit more processes in RAM, and swapping will only slow down your > computation. But this limit is probably in the thousands of processes range. > > Hope this helps, > Daniel > > > On Sat, 13 Jul 2019 at 10:47, I Gusti Ngurah Oka Prinarjaya < > okaprinarjaya@REDACTED> wrote: > >> Hi, >> >> I'm a super newbie, I had done very very simple parallel processing using >> erlang. I experimenting with my database containing about hundreds of >> thousands rows. I split the rows into different offsets then assign each >> worker-processes different rows based on offsets. For each row i doing >> simple similar text calculation using binary:longest_common_prefix/1 >> >> Let's assume my total rows is 200,000 rows of data. >> At first, i try to create 10 worker-processes, i assign 20,000 rows at >> each worker-process. >> Second, i try to create 20 worker-processes, i assign 10,000 rows at each >> worker-process. >> Third, i try to create 40 worker-processes, i assign 5000 rows at each >> worker-process. >> >> My machine specs: >> - MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports) >> - Processor 3,1 GHz Intel Core i5 ( 2 physical cores, with HT ) >> - RAM 8 GB 2133 MHz LPDDR3 >> >> My questions is >> >> 1. How to quick calculation / dumb / simple calculation max Erlang's >> processes based on above machine specs? >> >> 2. The running time when doing similar text processing with 10 worker, or >> 20 worker or 40 worker was very blazingly fast. So i cannot feel, i cannot >> see the difference. How to measure or something like printing total minutes >> out? So i can see the difference. >> >> 3. How many scheduler need to active / available when i create 10 >> processes? or 20 processes? 40 processes? and so on.. >> >> Please enlightenment >> >> Thank you super much >> >> >> >> >> >> _______________________________________________ >> 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 Jul 14 10:48:06 2019 From: roger@REDACTED (Roger Lipscombe) Date: Sun, 14 Jul 2019 09:48:06 +0100 Subject: [erlang-questions] How to quick calculation max Erlang's processes and scheduler can alive based on machine specs In-Reply-To: References: Message-ID: On Sun, 14 Jul 2019 at 07:24, I Gusti Ngurah Oka Prinarjaya wrote: > >> If, on the other hand, you see the run queue going up (the number of runnable processes that are waiting for a CPU slice to run), you have too many. > Where to see this? http://erlang.org/doc/man/erlang.html#statistics_run_queue_lengths From mikpelinux@REDACTED Sun Jul 14 16:48:01 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 14 Jul 2019 16:48:01 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On Fri, Jul 12, 2019 at 12:57 PM Grzegorz Junka wrote: > > On 10/07/2019 22:00, Mikael Pettersson wrote: > > On Wed, Jul 10, 2019 at 6:08 PM Lo?c Hoguin wrote: > >>> OTP-15949 Application(s): dialyzer, hipe > >>> > >>> The HiPE compiler would badly miscompile certain > >>> try/catch expressions, so it will now refuse to compile > >>> modules containing try or catch. > >>> > >>> As a consequence of this, dialyzer will no longer > >>> compile key modules to native code. > >> This means --enable-native-libs is now broken. Results in: > >> > >> hipe.erl: native-code compilation failed because of an unimplemented > >> instruction (catch). > >> > >> That's a bit rough. > >> > >> Is HiPE just going to slowly rot or are there plans to revive it somehow > > I had this discussion with Bj?rn from the OTP team at the latest EUC > > (er, "Code BEAM Sto"). > > > > The issue is that the original implementers of HiPE have long since > > moved on to other things > > and can't spend time on it any more. At the same time the OTP team is only able > > to support things their customers care about and pay for. HiPE isn't > > one of those things. > > > > So it's up to the community as a whole to support HiPE, if it wants > > it. This could take the > > form of one or more dedicated individuals taking on maintenance of > > HiPE and fixing issues > > as they are discovered. (There's at least one such individual working > > on the bit syntax > > compilation issue in OTP-22 right now.) Another solution could be for > > interested parties to > > fund maintenance via the Erlang Ecosystem Foundation. > > > > The try/catch issue is news to me, but since the bit syntax > > compilation issue was known > > as OTP-22.0 was released, my view is that OTP should have deprecated > > HiPE at that point > > with the understanding that OTP-23 would delete HiPE unless the > > community stepped up > > and fixed the issues. (And by that I don't mean "silently don't > > compile things we can't handle > > any more".) > > > > /Mikael, ex-HiPE developer > > > Mikael, would it be possible for you or someone else from the OTP team Note: drop "else", I'm not in the OTP team, just a long-time contributor to Erlang/OTP. > to provide more details about the minimal amount of work required to > bring HiPE back to the working order? I am looking for things like: > > 1. Any test suites available for HiPE (I would expect some tests not > passing due to recent changes) HiPE used to maintain its own internal test suite. The HiPE compiler application in OTP includes some tests, but I have no idea how complete it is; a quick look indicates it doesn't include everything from the old internal test suite. A snapshot of that test suite as of early 2011 is available in , but there are a few later additions that AFAIK are only available in a 2014 CVS snapshot I have locally. > 2. Documentation detailing the HiPE implementation (if available) Go to and read the various publications. Those and the source code (erts/emulator/hipe/, other parts of erts/ under #ifdef HIPE, lib/hipe/ (the compiler), and a few other bits under lib/) are the documentation. > 3. New features that the new compiler no longer compiles for HiPE > 4. Planned features that will require support in the compiler in the > foreseeable future > > Also, is the HiPE code tightly integrated with OTP and its compiler or > it could be extracted into a separate repo and maintained at its own peace? HiPE and OTP are mutually dependent: - the HiPE compiler's input is the BEAM code output by the OTP compiler, so whenever BEAM instructions are added or the OTP compiler changes drastically, the HiPE compiler needs to be updated - the OTP compiler dispatches to the HiPE compiler if you compile with the native flag enabled - the OTP code loader dispatches to the HiPE code loader for modules compiled to native code - the OTP VM (aka runtime system) has extensions to + load native code + allow Erlang processes to call native code from BEAM and vice versa + likewise handle throwing exceptions across the two execution modes + garbage collection of the native code's stack + handling dynamic (re-)loading of modules containing native code You can't distribute this as just another "application". As for the concrete problems right now: 1. The binary compilation issue is documented in both the bug tracker and as a PR on github, so I won't expand on that. 2. The "try/catch miscompilation" issue is mentioned in the OTP-22.0.6 release notes, but the only reference is to an OTP-internal bug entry (OTP-15949) and there's no test case added, making it difficult to understand what the issue is or how to fix it. Finally, a major part of the problem is that OTP is a moving target. The VM keeps changing (new BEAM instructions, new conventions for memory management or BIF calls), and the OTP compiler also changes, and each such change has the potential for breaking HiPE. /Mikael From dszoboszlay@REDACTED Sun Jul 14 19:18:40 2019 From: dszoboszlay@REDACTED (=?UTF-8?Q?D=C3=A1niel_Szoboszlay?=) Date: Sun, 14 Jul 2019 19:18:40 +0200 Subject: [erlang-questions] How to quick calculation max Erlang's processes and scheduler can alive based on machine specs In-Reply-To: References: Message-ID: The run queue is also shown on the System tab of Observer (Statistics box). Not a time chart though, just the current value. On Sun, 14 Jul 2019 at 10:48, Roger Lipscombe wrote: > On Sun, 14 Jul 2019 at 07:24, I Gusti Ngurah Oka Prinarjaya > wrote: > > >> If, on the other hand, you see the run queue going up (the number of > runnable processes that are waiting for a CPU slice to run), you have too > many. > > Where to see this? > > http://erlang.org/doc/man/erlang.html#statistics_run_queue_lengths > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sperber@REDACTED Sun Jul 14 17:22:45 2019 From: sperber@REDACTED (Michael Sperber) Date: Sun, 14 Jul 2019 17:22:45 +0200 Subject: [erlang-questions] Summer BOB 2019 2nd Call for Participation (Aug 21, Berlin, early reg until Jul 18) Message-ID: Come for BOB, stay for the Erlang Workshop! ================================================================================ Summer BOB 2019 Conference ?What happens if we simply use what?s best?? August 21, 2019, Berlin co-located with ICFP 2019 http://bobkonf.de/2019-summer/ Program: http://bobkonf.de/2019-summer/program.html Registration: http://bobkonf.de/2019-summer/registration.html ================================================================================ Are you interested in technologies beyond the mainstream, that are a pleasure to use, and effective at getting the job done? BOB is the forum for developers, architects and builders to explore and discover the best tools available today for building software. Our goal is for all participants to leave the conference with new ideas to improve development back at the ranch. 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. BOB features two tracks of seven talk each: One research track with invited talks, and one track by practitioners, designed to cross-pollinate and inspire. http://bobkonf.de/2019-summer/program.html Topics include distributed programming, testing, linear algebra, functional design patterns, type systems, formal methods, and interactive development. We are committed to diversity: We aim at exploring a wide range of tools in a welcoming and friendly crowd of diverse people. To that end, a number of support options for participants from groups under-represented in tech are available. http://bobkonf.de/2019-summer/registration.html NOTE: The early-bird rates expire on July 18, 2019! From toddg@REDACTED Sun Jul 14 18:04:44 2019 From: toddg@REDACTED (Todd) Date: Sun, 14 Jul 2019 16:04:44 +0000 Subject: [erlang-questions] Where is the Golden Path? Message-ID: From http://zwrob.com/posts/erlang-01/ I'm slowly learning [Erlang][0]. It's taken me more than 10 years to get to where I am now...which, frankly, isn't very far. I thought I'd share some newbie thoughts from a veteran software developer with over 25 years of experience in the industry. # History From 2009 to 2019... * read books [(Joe, Fred, etc.)][4] * write little code snippets * post little [how-to-tutorials][3] showing how little I understand about Erlang * wander away as I lose focus and time * repeat. This year, after Joe died, I thought...I'm not getting any younger either. I decided to take the summer off and really study Erlang. So far the process has been: * read the [same books][4], but only as references * have a real problem to solve (I'm basing a business on it) * write little code snippets (escripts) to POC business components * document what I am learning on my [personal website][5] * design the full scale app * implement ... oops hitting the road blocks... ## Road blocks ### Erlang installation and tools I wish I'd known about [asdf][6] much earlier. That's really simplified my dev box configuration. I wish that [rebar3][7] and [kerl][8] and other docs just pointed this out. In fact, I wish there was a `golden` path published that just says, look, here's the common accepted tool chain you are going to want to use. Stay on this path, and life will be easy. [rebar3][7] is a big part of this story, but not the whole thing. ### Migrating from escripts to `real` apps $ rebar3 new escript myfooscript I started with escripts because I didn't want the hassle of understanding OTP or anything else as I was writing POC snippets to understand the basic Erlang libraries. So I'd write an escript to shell out and curl some resource and gradually build up an application that ingests data and writes into a database, blah blah. But along the way I could learn about `xmerl` and other useful libraries. Oh, and I could run the app and see STDOUT. Cool! Just like any other language I'm familiar with. So I roll up my sleeves and decide to create an app... ### Naming things is hard $ rebar3 new release|umbrella myfooapp Um, why does 'umbrella' exist as an option here? Is it the same thing as a 'release'? Is it necessary? Why is 'release' called 'release'? This is an overloaded term, as there are 'releases' which is a thing, and there's a 'release' command, and there's a 'release' target in the rebar3 command. And there's an 'umbrella' in there, too. OK, release == umbrella, so I pick one. $ rebar3 new release myfooapp ### Where is STDOUT? So, let me say, `rebar3` is great. I barely remember what it was like to use `sinan` or `faxien`. (And while Loic's Makefiles look amazing, I'm nowhere near smart enough to use them.) But here's the thing, I had to watch a number of videos before I found out what the `shell` command was. This is important to me because the next block I had was... how do I start my application _and_ see the output from it? I want to watch STDOUT, right? I was watching some conference video when someone mentioned that 'shell' was the coolest part of rebar3 and I'm like, 'what is that'? And voila! It's what I needed. This should be on the golden path. $ cd myfooapp $ rebar3 shell myfooapp ### Where is the golden path? It's weird that there is no golden path. [In this talk][2], at 14:50, Fred talks about how it's only far into various Erlang books that authors start talking about running code outside the shell, in contrast to K&R C where it's discussed on page 6. In fact, the entire (excellent) presentation is on the terrible state of tooling in the Erlang ecosystem. *begin rant* #### Here's what's weird about Erlang : Books are out of date * The books are already out of date. Even [LYSEFGG][9] still talks about [systools][11] and [reltool][12] even though [rebar3][7] and [relx][10] have supplanted them? What's weird about this is to be reading the rebar3 documentation, then cross-referencing with relx, and reading the various books that describe the old ways of building releases and relups, etc. #### Docs are hard to follow * [relx][10] documentation is pretty hard to follow * Community support seems fragmented * [Github shows relx][14] has 41 open issues and 6 open pull requests, with 89 contributors * [Github shows rebar3][13] has 107 open issues and 11 open pull requests, with 239 contributors #### Who's maintaining these tools? If I were Tristan or Fred, boy I'd be tired of supporting this stuff. #### Where are the videos? Here's another thing that's weird... I cannot find videos on how to use the Erlang shell. So on top of that weird fact, I'm finding out about erlang by watching Elixir videos. I was watching an Elixir video on 'wobserver' and realized, 'Hey! I bet that's just a web interface on some Erlang thingy called "observer"'. So then I find out about 'observer' and how useful that is. Great! But things like, how to I do basic stuff like navigate from one process to another, what do I do when everything seems hung and broken, what do real live seasoned Erlang devs do when '_stuff_ hit's the fan'? How do they go about examining a running system? The web seems to have nothing on this. But that's just weird, b/c Erlang has been around for over 25 years, and any other language / framework/ runtime whatever has zillions of youtube videos. *end rant* ## Culture of Quick Fixes OK, so enough ranting. Let me get into [Fred's mention of the 'Culture of Quick Fixes'][2] (at about 21:00) by introducing my own steaming pile of a quick fix. So here's the deal. I'm trying to build a [company][15]. I have limited $$$, I can't screw around learning stuff forever. At some point I have to build a real live app and try to generate some buzz. I'll roughly describe my first app/service and run through my decision points... ### App The app basically pulls data from publicly available but disparate data sets, ingests them, normalizes them into a common data store, and then surfaces the data store for analysis, reporting, AI/ML, etc, etc. In a nutshell, take data, add magic, produce pretty pictures. ### Process * prototype in bash (or python, or whatever...) Seriously, with just `bash` and I can query for my data, extract in, play around with it, etc. If I wanted I could hook it up to `cron` and probably move on to actually using the data rather than learning Erlang and how to build 'proper' infrastructure. ### Prototype in escript Here's where I take small tasks and learn the Erlang libraries to accomplish what I'm trying to do. It takes about as much time to do this as the previous prototyping step. I find this to be a great way to both decompose a problem and learn a new language. ### Start building industrial grade services So now, rather than focusing on my business, finding customers, analyzing the data I've collected, or in any other way providing value that could bring in revenue and allow me to purchase more Erlang books... I'm veering off into the weeds and learning how to: * build erlang apps for real * build erlang releases * wire all this into docker containers * wire in monitoring and all the 'industrial grade goodies' Along the way I tend to post about what I learn [here][5]. * Is any of this worthwhile? * Am I just engaged in endless pencil sharpening? * I dunno. I'm too close to the fire. I'm having fun though. And it's incredibly useful to my brain in some way I cannot describe. ### The Problem So back to "The Culture of Quick Fixes". As I'm building my first set of components and learning about rebar.config and config/sys.config and more groovy stuff, I run into the issue of how to deploy Erlang to docker containers. The answer is, run the release with the `foreground` command. But this wasn't obvious to me at first and took a lot of digging around the 'net, [posting a question on the rebar3 discussion list][16], and just general noodling around. But, if I'm building industrial grade applications, then I need to solve for issues such as: * How do I emit metrics from my app? * How do I monitor my metrics (e.g. Prometheus)? * How do I hook up a visualization tool (e.g. Grafana)? Alarms? * And how do I wire all this up into a containerized solution so that it's re-usable and shareable? * Don't forget my "awesome" Makefiles! I like to have a common control plane for all my services, and common Makefiles are great for this. Now, if you watched the end of Fred's video, he was talking about many of these same things. *And I'll suggest that what I've built is an example of exactly what shouldn't be done:* * I ignored everything on hex. Why? Um, I don't really understand hex that well yet, I'd have to go read a bunch of code to understand what folks have done, and I'm still learning Erlang by building things myself. None of these is a good reason, BTW. * I only published my stuff to github, and not to hex. This may be a good thing as I'd just be duplicating other, probably better, efforts. * What I built should probably be a rebar3 plugin, and not a Makefile with dependencies on rebar3 etc. However, I'll show you what this is because I think it satisfies a need and perhaps we can all come up with a better implementation strategy. Or learn something. ## Erlang-Seed So, here we have 'yet-another-quick-fix' called [erlang-seed][17]. Let me be honest, this is a 'quick-fix' to satisfy my own personal needs... ### The Good What this does is create an erlang application, inject it into a Docker container, and then spin up a local Docker cluster that monitors the Erlang app and surfaces the metrics via Prometheus and Grafana. So with one command I can generate an OTP application, all the infrastructure necessary to monitor it with common tooling, _and_ spin it up and run it on my dev box. I find this to be really useful. YMMV. ### The Bad This is really crufty. It calls into rebar3 to generate the app. It should probably be a rebar3 plugin so that it can better evolve with the tooling. It could then more intelligently inject the necessary dependencies, instrument the code with metrics, etc. Right now it's gross, as it just overwrites files as necessary using mustache templates. ### The Ugly * Do I have time to maintain this? No. * Do I have time to make this a rebar3 plugin? Not right now. * Will this probably break over time due to either rebar3, docker, or some other dependency changing? Certainly, eventually, yes. ## Summary The reason I'm sharing this is to just widen the discussion on what the Erlang education and tooling could look like. I think that generating full stacks that allow developers to focus more on solving business domain issues rather than forcing them to understand all the arcane details of whatever is under the covers is the 'way to go (TM)'. There's got to be a way to allow developers to maintain velocity while increasing their depth and scope of knowledge as necessary. I've been studying Erlang intensely for at least a month now, read the books _countless_ times, and read the online docs and I still don't quite understand how this all fits together. I mean I get the big picture. But there's a _lot_ of details. Contrast this with Go. I was writing production code in 2 days. The quality was production quality after about a week. Back in the day it took me about a month to become proficient in Java, though it required reading Bloch's book "Java Concurrency In Practice" to be 'good'. Python was similar, it took about a week to ramp up, about a month to become comfortable. In all of these languages it was a relatively short and easy ramp up and then smooth sailing for years and years. With Erlang it's an incredibly steep ramp that goes on and on. I guess if I remember that I'm learning the equivalent of a language, an orchestration framework (like kubernetes), a database system, etc., then it starts to make sense. Anyway, for my part, I'll keep posting things as I figure them out. -Todd [0]:https://www.erlang.org/ [1]:https://ferd.ca/ten-years-of-erlang.html [2]:https://youtu.be/Z28SDd9bXcE?t=1260 [3]:https://github.com/ToddG/experimental/tree/master/erlang/wilderness [4]:https://github.com/ToddG/experimental/blob/master/erlang/resources/books.md [5]:http://zwrob.com/posts [6]:https://github.com/asdf-vm/asdf [7]:https://www.rebar3.org [8]:https://github.com/kerl/kerl [9]:https://learnyousomeerlang.com/ [10]:https://github.com/erlware/relx [11]:http://erlang.org/doc/man/systools.html [12]:http://erlang.org/doc/man/reltool.html [13]:https://github.com/erlang/rebar3 [14]:https://github.com/erlware/relx [15]:http://envirosoftwaresolutions.com [16]:https://www.rebar3.org/discuss/5d29172873e1ed00447cb362 [17]:https://github.com/ToddG/erlang-seed [18]:http://zwrob.com/posts/developer-automation/ -Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From list1@REDACTED Mon Jul 15 13:55:55 2019 From: list1@REDACTED (Grzegorz Junka) Date: Mon, 15 Jul 2019 12:55:55 +0100 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On 14/07/2019 15:48, Mikael Pettersson wrote: > On Fri, Jul 12, 2019 at 12:57 PM Grzegorz Junka wrote: >> On 10/07/2019 22:00, Mikael Pettersson wrote: >>> On Wed, Jul 10, 2019 at 6:08 PM Lo?c Hoguin wrote: >>>>> OTP-15949 Application(s): dialyzer, hipe >>>>> >>>>> The HiPE compiler would badly miscompile certain >>>>> try/catch expressions, so it will now refuse to compile >>>>> modules containing try or catch. >>>>> >>>>> As a consequence of this, dialyzer will no longer >>>>> compile key modules to native code. >>>> This means --enable-native-libs is now broken. Results in: >>>> >>>> hipe.erl: native-code compilation failed because of an unimplemented >>>> instruction (catch). >>>> >>>> That's a bit rough. >>>> >>>> Is HiPE just going to slowly rot or are there plans to revive it somehow >>> I had this discussion with Bj?rn from the OTP team at the latest EUC >>> (er, "Code BEAM Sto"). >>> >>> The issue is that the original implementers of HiPE have long since >>> moved on to other things >>> and can't spend time on it any more. At the same time the OTP team is only able >>> to support things their customers care about and pay for. HiPE isn't >>> one of those things. >>> >>> So it's up to the community as a whole to support HiPE, if it wants >>> it. This could take the >>> form of one or more dedicated individuals taking on maintenance of >>> HiPE and fixing issues >>> as they are discovered. (There's at least one such individual working >>> on the bit syntax >>> compilation issue in OTP-22 right now.) Another solution could be for >>> interested parties to >>> fund maintenance via the Erlang Ecosystem Foundation. >>> >>> The try/catch issue is news to me, but since the bit syntax >>> compilation issue was known >>> as OTP-22.0 was released, my view is that OTP should have deprecated >>> HiPE at that point >>> with the understanding that OTP-23 would delete HiPE unless the >>> community stepped up >>> and fixed the issues. (And by that I don't mean "silently don't >>> compile things we can't handle >>> any more".) >>> >>> /Mikael, ex-HiPE developer >> >> Mikael, would it be possible for you or someone else from the OTP team > Note: drop "else", I'm not in the OTP team, just a long-time contributor > to Erlang/OTP. > >> to provide more details about the minimal amount of work required to >> bring HiPE back to the working order? I am looking for things like: >> >> 1. Any test suites available for HiPE (I would expect some tests not >> passing due to recent changes) > HiPE used to maintain its own internal test suite. The HiPE compiler > application in OTP includes some tests, but I have no idea how > complete it is; a quick look indicates it doesn't include everything > from the old internal test suite. A snapshot of that test suite as of early > 2011 is available in , but there > are a few later additions that AFAIK are only available in a 2014 CVS > snapshot I have locally. Thanks for all the info. Is that CVS snapshot available anywhere apart from your local comp? Is it possible to upload it for example to Github? GrzegorzJ From list1@REDACTED Mon Jul 15 14:00:02 2019 From: list1@REDACTED (Grzegorz Junka) Date: Mon, 15 Jul 2019 13:00:02 +0100 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On 14/07/2019 15:48, Mikael Pettersson wrote: > On Fri, Jul 12, 2019 at 12:57 PM Grzegorz Junka wrote: >> On 10/07/2019 22:00, Mikael Pettersson wrote: >>> On Wed, Jul 10, 2019 at 6:08 PM Lo?c Hoguin wrote: >>>>> OTP-15949 Application(s): dialyzer, hipe >>>>> >>>>> The HiPE compiler would badly miscompile certain >>>>> try/catch expressions, so it will now refuse to compile >>>>> modules containing try or catch. >>>>> >>>>> As a consequence of this, dialyzer will no longer >>>>> compile key modules to native code. >>>> This means --enable-native-libs is now broken. Results in: >>>> >>>> hipe.erl: native-code compilation failed because of an unimplemented >>>> instruction (catch). >>>> >>>> That's a bit rough. >>>> >>>> Is HiPE just going to slowly rot or are there plans to revive it somehow >>> I had this discussion with Bj?rn from the OTP team at the latest EUC >>> (er, "Code BEAM Sto"). >>> >>> The issue is that the original implementers of HiPE have long since >>> moved on to other things >>> and can't spend time on it any more. At the same time the OTP team is only able >>> to support things their customers care about and pay for. HiPE isn't >>> one of those things. >>> >>> So it's up to the community as a whole to support HiPE, if it wants >>> it. This could take the >>> form of one or more dedicated individuals taking on maintenance of >>> HiPE and fixing issues >>> as they are discovered. (There's at least one such individual working >>> on the bit syntax >>> compilation issue in OTP-22 right now.) Another solution could be for >>> interested parties to >>> fund maintenance via the Erlang Ecosystem Foundation. >>> >>> The try/catch issue is news to me, but since the bit syntax >>> compilation issue was known >>> as OTP-22.0 was released, my view is that OTP should have deprecated >>> HiPE at that point >>> with the understanding that OTP-23 would delete HiPE unless the >>> community stepped up >>> and fixed the issues. (And by that I don't mean "silently don't >>> compile things we can't handle >>> any more".) >>> >>> /Mikael, ex-HiPE developer >> >> Mikael, would it be possible for you or someone else from the OTP team > Note: drop "else", I'm not in the OTP team, just a long-time contributor > to Erlang/OTP. > >> to provide more details about the minimal amount of work required to >> bring HiPE back to the working order? I am looking for things like: >> >> 1. Any test suites available for HiPE (I would expect some tests not >> passing due to recent changes) > HiPE used to maintain its own internal test suite. The HiPE compiler > application in OTP includes some tests, but I have no idea how > complete it is; a quick look indicates it doesn't include everything > from the old internal test suite. A snapshot of that test suite as of early > 2011 is available in , but there > are a few later additions that AFAIK are only available in a 2014 CVS > snapshot I have locally. > >> 2. Documentation detailing the HiPE implementation (if available) > Go to and read the > various publications. Those and the source code (erts/emulator/hipe/, > other parts of erts/ under #ifdef HIPE, lib/hipe/ (the compiler), and a > few other bits under lib/) are the documentation. > >> 3. New features that the new compiler no longer compiles for HiPE >> 4. Planned features that will require support in the compiler in the >> foreseeable future >> >> Also, is the HiPE code tightly integrated with OTP and its compiler or >> it could be extracted into a separate repo and maintained at its own peace? > HiPE and OTP are mutually dependent: > - the HiPE compiler's input is the BEAM code output by the OTP compiler, > so whenever BEAM instructions are added or the OTP compiler changes > drastically, the HiPE compiler needs to be updated > - the OTP compiler dispatches to the HiPE compiler if you compile with the > native flag enabled > - the OTP code loader dispatches to the HiPE code loader for modules > compiled to native code > - the OTP VM (aka runtime system) has extensions to > + load native code > + allow Erlang processes to call native code from BEAM and vice versa > + likewise handle throwing exceptions across the two execution modes > + garbage collection of the native code's stack > + handling dynamic (re-)loading of modules containing native code Sorry, forgot to ask one more question. If HiPE compiler's input is the BEAM code then I understand interested in HiPE may not only be the Erlang community but also other communities that use the BEAM VM, e.g. Elixir and some other listed here https://github.com/llaisdy/beam_languages ? GrzegorzJ From jesper.louis.andersen@REDACTED Mon Jul 15 15:22:33 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 15 Jul 2019 15:22:33 +0200 Subject: [erlang-questions] How to quick calculation max Erlang's processes and scheduler can alive based on machine specs In-Reply-To: References: Message-ID: On Sat, Jul 13, 2019 at 10:47 AM I Gusti Ngurah Oka Prinarjaya < okaprinarjaya@REDACTED> wrote: > Hi, > > I'm a super newbie, I had done very very simple parallel processing using > erlang. I experimenting with my database containing about hundreds of > thousands rows. I split the rows into different offsets then assign each > worker-processes different rows based on offsets. For each row i doing > simple similar text calculation using binary:longest_common_prefix/1 > > First, you need to recognize you have a parallelism problem, and not a concurrency problem. So you are interested in what speedup you can get by adding more cores, compared to a single-process solution. The key analysis parameters are work, span and cost[0]. On top of that, you want to look at the speedup factor (S = T_1 / T_p). > 1. How to quick calculation / dumb / simple calculation max Erlang's > processes based on above machine specs? > > This requires measurement. A single-core/process system have certain advantages: * It doesn't need to lock and latch. * It doesn't need to distribute data (scatter) and recombine data (gather). Adding more processes has an overhead and at a point, it will cease to provide speedup. In fact, speedup might go down. What I tend to do, is to napkin math the cost of a process. The PCB I usually set at 2048 bytes. It is probably lower in reality, but an upper bound is nice. If each process has to keep, say, 4096 bytes of data around, I set it at 2*4096 to account for the GC. So that is around 10 Kilobytes per process. If I have a million processes, that is 10 gigabytes of memory. If each process is also doing network I/O you need to account for the network buffers in the kernel as well, etc. However, since you are looking at parallelism, this has less importance since you don't want to keep a process per row (the overhead tends to be too big in that case, and the work is not concurrent anyway[1]). > 2. The running time when doing similar text processing with 10 worker, or > 20 worker or 40 worker was very blazingly fast. So i cannot feel, i cannot > see the difference. How to measure or something like printing total minutes > out? So i can see the difference. > > timer:tc/1 is a good start. eministat[2] is a shameless plug as well. > 3. How many scheduler need to active / available when i create 10 > processes? or 20 processes? 40 processes? and so on.. > > If your machine has 2 physical cores with two hyperthreads per core, a first good ballpark is either 2 or 4 schedulers. Adding more just makes them fight for the resources. The `+stbt` option might come in handy if supported by your environment. Depending on your workload, you can expect some -30 to 50% extra performance out of the additional hyperthread. In some cases it hurts performance: * Caches can be booted out by the additional hyperthread * If you don't have memory presssure to make a thread wait, there is little additional power in the hyperthread * In a laptop environment, the additonal hyperthread will generate more thermal heat. This might make the CPU clock down resulting in worse run times. This is especially important on MacBooks. They have really miserable thermals and add way too powerful CPUs in a bad thermal solution. It gives them good peak performance when "sprinting" for short bursts, but bad sustain performance, e.g., "marathons". Battery vs AC power also means a lot and will mess with runtimes. As for how many processes: you want to have enough to keep all your schedulers utilized, but not so many your work is broken into tiny pieces. This will mean more scatter/gather IO is necessary, impeding your performance. And if that IO is going across CPU cores, you are also looking at waiting on caches. If you are really interested in parallel processing, it is probably better to look at languages built for the problem space. Rust, with its rayon library. Or something like https://futhark-lang.org/ might be better suited. Or even look at TensorFlow. It has a really strong, optimized, numerical core. Erlang, being bytecode interpreted, pays an overhead which you have to balance out with either more productivity, ease of programming, faster prototyping or the like. Erlang tends to be stronger at MIMD style processing (and so does e.g., Go). [0] https://en.wikipedia.org/wiki/Analysis_of_parallel_algorithms [1] your work is classical SIMD rather than MIMD. [2] github.com/jlouis/eministat -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpelinux@REDACTED Mon Jul 15 16:43:44 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Mon, 15 Jul 2019 16:43:44 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On Mon, Jul 15, 2019 at 1:55 PM Grzegorz Junka wrote: > > > On 14/07/2019 15:48, Mikael Pettersson wrote: > > On Fri, Jul 12, 2019 at 12:57 PM Grzegorz Junka wrote: > >> On 10/07/2019 22:00, Mikael Pettersson wrote: > >>> On Wed, Jul 10, 2019 at 6:08 PM Lo?c Hoguin wrote: > >>>>> OTP-15949 Application(s): dialyzer, hipe > >>>>> > >>>>> The HiPE compiler would badly miscompile certain > >>>>> try/catch expressions, so it will now refuse to compile > >>>>> modules containing try or catch. > >>>>> > >>>>> As a consequence of this, dialyzer will no longer > >>>>> compile key modules to native code. > >>>> This means --enable-native-libs is now broken. Results in: > >>>> > >>>> hipe.erl: native-code compilation failed because of an unimplemented > >>>> instruction (catch). > >>>> > >>>> That's a bit rough. > >>>> > >>>> Is HiPE just going to slowly rot or are there plans to revive it somehow > >>> I had this discussion with Bj?rn from the OTP team at the latest EUC > >>> (er, "Code BEAM Sto"). > >>> > >>> The issue is that the original implementers of HiPE have long since > >>> moved on to other things > >>> and can't spend time on it any more. At the same time the OTP team is only able > >>> to support things their customers care about and pay for. HiPE isn't > >>> one of those things. > >>> > >>> So it's up to the community as a whole to support HiPE, if it wants > >>> it. This could take the > >>> form of one or more dedicated individuals taking on maintenance of > >>> HiPE and fixing issues > >>> as they are discovered. (There's at least one such individual working > >>> on the bit syntax > >>> compilation issue in OTP-22 right now.) Another solution could be for > >>> interested parties to > >>> fund maintenance via the Erlang Ecosystem Foundation. > >>> > >>> The try/catch issue is news to me, but since the bit syntax > >>> compilation issue was known > >>> as OTP-22.0 was released, my view is that OTP should have deprecated > >>> HiPE at that point > >>> with the understanding that OTP-23 would delete HiPE unless the > >>> community stepped up > >>> and fixed the issues. (And by that I don't mean "silently don't > >>> compile things we can't handle > >>> any more".) > >>> > >>> /Mikael, ex-HiPE developer > >> > >> Mikael, would it be possible for you or someone else from the OTP team > > Note: drop "else", I'm not in the OTP team, just a long-time contributor > > to Erlang/OTP. > > > >> to provide more details about the minimal amount of work required to > >> bring HiPE back to the working order? I am looking for things like: > >> > >> 1. Any test suites available for HiPE (I would expect some tests not > >> passing due to recent changes) > > HiPE used to maintain its own internal test suite. The HiPE compiler > > application in OTP includes some tests, but I have no idea how > > complete it is; a quick look indicates it doesn't include everything > > from the old internal test suite. A snapshot of that test suite as of early > > 2011 is available in , but there > > are a few later additions that AFAIK are only available in a 2014 CVS > > snapshot I have locally. > > > Thanks for all the info. Is that CVS snapshot available anywhere apart > from your local comp? Is it possible to upload it for example to Github? Not yet, but I can fork andysan's repo and add the missing bits on my github. From mikpelinux@REDACTED Mon Jul 15 16:48:40 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Mon, 15 Jul 2019 16:48:40 +0200 Subject: [erlang-questions] Patch Package OTP 22.0.6 Released In-Reply-To: References: <20190710081807.GA18425@erix.ericsson.se> <2484bfe8-f773-b517-6cf1-54a30ff27e04@ninenines.eu> Message-ID: On Mon, Jul 15, 2019 at 2:00 PM Grzegorz Junka wrote: > > > On 14/07/2019 15:48, Mikael Pettersson wrote: > > On Fri, Jul 12, 2019 at 12:57 PM Grzegorz Junka wrote: > >> On 10/07/2019 22:00, Mikael Pettersson wrote: > >>> On Wed, Jul 10, 2019 at 6:08 PM Lo?c Hoguin wrote: > >>>>> OTP-15949 Application(s): dialyzer, hipe > >>>>> > >>>>> The HiPE compiler would badly miscompile certain > >>>>> try/catch expressions, so it will now refuse to compile > >>>>> modules containing try or catch. > >>>>> > >>>>> As a consequence of this, dialyzer will no longer > >>>>> compile key modules to native code. > >>>> This means --enable-native-libs is now broken. Results in: > >>>> > >>>> hipe.erl: native-code compilation failed because of an unimplemented > >>>> instruction (catch). > >>>> > >>>> That's a bit rough. > >>>> > >>>> Is HiPE just going to slowly rot or are there plans to revive it somehow > >>> I had this discussion with Bj?rn from the OTP team at the latest EUC > >>> (er, "Code BEAM Sto"). > >>> > >>> The issue is that the original implementers of HiPE have long since > >>> moved on to other things > >>> and can't spend time on it any more. At the same time the OTP team is only able > >>> to support things their customers care about and pay for. HiPE isn't > >>> one of those things. > >>> > >>> So it's up to the community as a whole to support HiPE, if it wants > >>> it. This could take the > >>> form of one or more dedicated individuals taking on maintenance of > >>> HiPE and fixing issues > >>> as they are discovered. (There's at least one such individual working > >>> on the bit syntax > >>> compilation issue in OTP-22 right now.) Another solution could be for > >>> interested parties to > >>> fund maintenance via the Erlang Ecosystem Foundation. > >>> > >>> The try/catch issue is news to me, but since the bit syntax > >>> compilation issue was known > >>> as OTP-22.0 was released, my view is that OTP should have deprecated > >>> HiPE at that point > >>> with the understanding that OTP-23 would delete HiPE unless the > >>> community stepped up > >>> and fixed the issues. (And by that I don't mean "silently don't > >>> compile things we can't handle > >>> any more".) > >>> > >>> /Mikael, ex-HiPE developer > >> > >> Mikael, would it be possible for you or someone else from the OTP team > > Note: drop "else", I'm not in the OTP team, just a long-time contributor > > to Erlang/OTP. > > > >> to provide more details about the minimal amount of work required to > >> bring HiPE back to the working order? I am looking for things like: > >> > >> 1. Any test suites available for HiPE (I would expect some tests not > >> passing due to recent changes) > > HiPE used to maintain its own internal test suite. The HiPE compiler > > application in OTP includes some tests, but I have no idea how > > complete it is; a quick look indicates it doesn't include everything > > from the old internal test suite. A snapshot of that test suite as of early > > 2011 is available in , but there > > are a few later additions that AFAIK are only available in a 2014 CVS > > snapshot I have locally. > > > >> 2. Documentation detailing the HiPE implementation (if available) > > Go to and read the > > various publications. Those and the source code (erts/emulator/hipe/, > > other parts of erts/ under #ifdef HIPE, lib/hipe/ (the compiler), and a > > few other bits under lib/) are the documentation. > > > >> 3. New features that the new compiler no longer compiles for HiPE > >> 4. Planned features that will require support in the compiler in the > >> foreseeable future > >> > >> Also, is the HiPE code tightly integrated with OTP and its compiler or > >> it could be extracted into a separate repo and maintained at its own peace? > > HiPE and OTP are mutually dependent: > > - the HiPE compiler's input is the BEAM code output by the OTP compiler, > > so whenever BEAM instructions are added or the OTP compiler changes > > drastically, the HiPE compiler needs to be updated > > - the OTP compiler dispatches to the HiPE compiler if you compile with the > > native flag enabled > > - the OTP code loader dispatches to the HiPE code loader for modules > > compiled to native code > > - the OTP VM (aka runtime system) has extensions to > > + load native code > > + allow Erlang processes to call native code from BEAM and vice versa > > + likewise handle throwing exceptions across the two execution modes > > + garbage collection of the native code's stack > > + handling dynamic (re-)loading of modules containing native code > > > Sorry, forgot to ask one more question. If HiPE compiler's input is the > BEAM code then I understand interested in HiPE may not only be the > Erlang community but also other communities that use the BEAM VM, e.g. > Elixir and some other listed here > https://github.com/llaisdy/beam_languages ? HiPE should work with any language that compiles to Erlang. It may also work with languages that compile via Core Erlang, but that path is less tested. From okaprinarjaya@REDACTED Mon Jul 15 21:14:17 2019 From: okaprinarjaya@REDACTED (I Gusti Ngurah Oka Prinarjaya) Date: Tue, 16 Jul 2019 02:14:17 +0700 Subject: [erlang-questions] How to quick calculation max Erlang's processes and scheduler can alive based on machine specs In-Reply-To: References: Message-ID: Hi Andersen, Woww thank you very much for the explanation. >> First, you need to recognize you have a parallelism problem Yes, i need parallelism. But i don't have time to research about GPU processing. Yes now i know, how much scheduler that i need to provide. Thank you :) Pada tanggal Sen, 15 Jul 2019 pukul 20.23 Jesper Louis Andersen < jesper.louis.andersen@REDACTED> menulis: > On Sat, Jul 13, 2019 at 10:47 AM I Gusti Ngurah Oka Prinarjaya < > okaprinarjaya@REDACTED> wrote: > >> Hi, >> >> I'm a super newbie, I had done very very simple parallel processing using >> erlang. I experimenting with my database containing about hundreds of >> thousands rows. I split the rows into different offsets then assign each >> worker-processes different rows based on offsets. For each row i doing >> simple similar text calculation using binary:longest_common_prefix/1 >> >> > First, you need to recognize you have a parallelism problem, and not a > concurrency problem. So you are interested in what speedup you can get by > adding more cores, compared to a single-process solution. The key analysis > parameters are work, span and cost[0]. On top of that, you want to look at > the speedup factor (S = T_1 / T_p). > > >> 1. How to quick calculation / dumb / simple calculation max Erlang's >> processes based on above machine specs? >> >> > This requires measurement. A single-core/process system have certain > advantages: > > * It doesn't need to lock and latch. > * It doesn't need to distribute data (scatter) and recombine data (gather). > > Adding more processes has an overhead and at a point, it will cease to > provide speedup. In fact, speedup might go down. > > What I tend to do, is to napkin math the cost of a process. The PCB I > usually set at 2048 bytes. It is probably lower in reality, but an upper > bound is nice. If each process has to keep, say, 4096 bytes of data around, > I set it at 2*4096 to account for the GC. So that is around 10 Kilobytes > per process. If I have a million processes, that is 10 gigabytes of memory. > If each process is also doing network I/O you need to account for the > network buffers in the kernel as well, etc. However, since you are looking > at parallelism, this has less importance since you don't want to keep a > process per row (the overhead tends to be too big in that case, and the > work is not concurrent anyway[1]). > >> 2. The running time when doing similar text processing with 10 worker, or >> 20 worker or 40 worker was very blazingly fast. So i cannot feel, i cannot >> see the difference. How to measure or something like printing total minutes >> out? So i can see the difference. >> >> > timer:tc/1 is a good start. eministat[2] is a shameless plug as well. > >> 3. How many scheduler need to active / available when i create 10 >> processes? or 20 processes? 40 processes? and so on.. >> >> > If your machine has 2 physical cores with two hyperthreads per core, a > first good ballpark is either 2 or 4 schedulers. Adding more just makes > them fight for the resources. The `+stbt` option might come in handy if > supported by your environment. Depending on your workload, you can expect > some -30 to 50% extra performance out of the additional hyperthread. In > some cases it hurts performance: > > * Caches can be booted out by the additional hyperthread > * If you don't have memory presssure to make a thread wait, there is > little additional power in the hyperthread > * In a laptop environment, the additonal hyperthread will generate more > thermal heat. This might make the CPU clock down resulting in worse run > times. This is especially important on MacBooks. They have really miserable > thermals and add way too powerful CPUs in a bad thermal solution. It gives > them good peak performance when "sprinting" for short bursts, but bad > sustain performance, e.g., "marathons". Battery vs AC power also means a > lot and will mess with runtimes. > > As for how many processes: you want to have enough to keep all your > schedulers utilized, but not so many your work is broken into tiny pieces. > This will mean more scatter/gather IO is necessary, impeding your > performance. And if that IO is going across CPU cores, you are also looking > at waiting on caches. > > If you are really interested in parallel processing, it is probably better > to look at languages built for the problem space. Rust, with its rayon > library. Or something like https://futhark-lang.org/ might be better > suited. Or even look at TensorFlow. It has a really strong, optimized, > numerical core. Erlang, being bytecode interpreted, pays an overhead which > you have to balance out with either more productivity, ease of programming, > faster prototyping or the like. Erlang tends to be stronger at MIMD style > processing (and so does e.g., Go). > > [0] https://en.wikipedia.org/wiki/Analysis_of_parallel_algorithms > [1] your work is classical SIMD rather than MIMD. > [2] github.com/jlouis/eministat > > -- > J. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Tue Jul 16 12:38:17 2019 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 16 Jul 2019 11:38:17 +0100 Subject: [erlang-questions] Line numbers in escript errors? Message-ID: When something goes wrong in my escript, I get something like this: escript: exception error: no match of right hand side value {ok, ...} in function erl_eval:expr/5 (erl_eval.erl, line 453) in call from erl_eval:exprs/5 (erl_eval.erl, line 126) in call from lists:foldl/3 (lists.erl, line 1263) ...but it doesn't tell me which line in my script was at fault. Is there a way to get escript to divulge that information? From z@REDACTED Tue Jul 16 13:01:57 2019 From: z@REDACTED (Danil Zagoskin) Date: Tue, 16 Jul 2019 14:01:57 +0300 Subject: [erlang-questions] Line numbers in escript errors? In-Reply-To: References: Message-ID: Hi! Do you use compile mode? It gives much more meaningful stacktraces (especially when you specify module name as well): $ cat hello.escript #!/usr/bin/env escript -module(hello). -mode(compile). main(_) -> [1/X || X <- lists:seq(-5, 2)]. $ ./hello.escript escript: exception error: an error occurred when evaluating an arithmetic expression in function hello:'-main/1-lc$^0/1-0-'/1 (./hello.escript, line 6) in call from hello:'-main/1-lc$^0/1-0-'/1 (./hello.escript, line 6) in call from escript:run/2 (escript.erl, line 758) in call from escript:start/1 (escript.erl, line 277) in call from init:start_em/1 in call from init:do_boot/3 On Tue, Jul 16, 2019 at 1:38 PM Roger Lipscombe wrote: > When something goes wrong in my escript, I get something like this: > > escript: exception error: no match of right hand side value > {ok, ...} > in function erl_eval:expr/5 (erl_eval.erl, line 453) > in call from erl_eval:exprs/5 (erl_eval.erl, line 126) > in call from lists:foldl/3 (lists.erl, line 1263) > > ...but it doesn't tell me which line in my script was at fault. Is > there a way to get escript to divulge that information? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From zxq9@REDACTED Tue Jul 16 13:22:41 2019 From: zxq9@REDACTED (zxq9@REDACTED) Date: Tue, 16 Jul 2019 20:22:41 +0900 Subject: [erlang-questions] Line numbers in escript errors? In-Reply-To: References: Message-ID: <2795297.sjBaDMZNOJ@takoyaki> On 2019?7?16???? 14?01?57? JST Danil Zagoskin wrote: > Hi! > > Do you use compile mode? > -mode(compile). > > On Tue, Jul 16, 2019 at 1:38 PM Roger Lipscombe > wrote: > > > When something goes wrong in my escript, I get something like this: > > > > escript: exception error: no match of right hand side value > > {ok, ...} > > in function erl_eval:expr/5 (erl_eval.erl, line 453) > > in call from erl_eval:exprs/5 (erl_eval.erl, line 126) > > in call from lists:foldl/3 (lists.erl, line 1263) > > > > ...but it doesn't tell me which line in my script was at fault. Is > > there a way to get escript to divulge that information? Another useful thing is to make sure your set to unicode mode with io:setopts/1. This can be perplexing to troubleshoot. I tend to start experiments with this as a template: #! /usr/bin/env escript -mode(compile). main(Args) -> ok = io:setopts([{encoding, unicode}]), io:format("Escript received the args: ~tp~n", [Args]). -Craig From raoknz@REDACTED Tue Jul 16 15:55:21 2019 From: raoknz@REDACTED (Richard O'Keefe) Date: Wed, 17 Jul 2019 01:55:21 +1200 Subject: [erlang-questions] Where is the Golden Path? In-Reply-To: References: Message-ID: A former manager used to say "You hero, sir" when someone did something good. Imagine me saying it. On Mon, 15 Jul 2019 at 19:02, Todd wrote: > From http://zwrob.com/posts/erlang-01/ > > I'm slowly learning [Erlang][0]. It's taken me more than 10 years to get to > where I am now...which, frankly, isn't very far. I thought I'd share some > newbie > thoughts from a veteran software developer with over 25 years of > experience in > the industry. > > # History > > From 2009 to 2019... > > * read books [(Joe, Fred, etc.)][4] > * write little code snippets > * post little [how-to-tutorials][3] showing how little I understand about > Erlang > * wander away as I lose focus and time > * repeat. > > > This year, after Joe died, I thought...I'm not getting any younger either. > I > decided to take the summer off and really study Erlang. So far the process > has been: > > * read the [same books][4], but only as references > * have a real problem to solve (I'm basing a business on it) > * write little code snippets (escripts) to POC business components > * document what I am learning on my [personal website][5] > * design the full scale app > * implement ... oops hitting the road blocks... > > > ## Road blocks > > ### Erlang installation and tools > > I wish I'd known about [asdf][6] much earlier. That's really simplified my > dev box > configuration. I wish that [rebar3][7] and [kerl][8] and other docs just > pointed this > out. In fact, I wish there was a `golden` path published that just says, > look, > here's the common accepted tool chain you are going to want to use. Stay on > this path, and life will be easy. [rebar3][7] is a big part of this story, > but > not the whole thing. > > > ### Migrating from escripts to `real` apps > > $ rebar3 new escript myfooscript > > I started with escripts because I didn't want the hassle of understanding > OTP > or anything else as I was writing POC snippets to understand the basic > Erlang > libraries. So I'd write an escript to shell out and curl some resource and > gradually build up an application that ingests data and writes into a > database, > blah blah. But along the way I could learn about `xmerl` and other useful > libraries. Oh, and I could run the app and see STDOUT. Cool! Just like any > other language I'm familiar with. > > So I roll up my sleeves and decide to create an app... > > ### Naming things is hard > > $ rebar3 new release|umbrella myfooapp > > Um, why does 'umbrella' exist as an option here? Is it the same thing as a > 'release'? Is it necessary? Why is 'release' called 'release'? This is an > overloaded term, as there are 'releases' which is a thing, and there's a > 'release' command, and there's a 'release' target in the rebar3 command. > And > there's an 'umbrella' in there, too. OK, release == umbrella, so I pick > one. > > $ rebar3 new release myfooapp > > ### Where is STDOUT? > > So, let me say, `rebar3` is great. I barely remember what it was like to > use > `sinan` or `faxien`. (And while Loic's Makefiles look amazing, I'm nowhere > near > smart enough to use them.) But here's the thing, I had to watch a number > of videos > before I found out what the `shell` command was. This is important to me > because > the next block I had was... how do I start my application _and_ see the > output > from it? I want to watch STDOUT, right? I was watching some conference > video > when someone mentioned that 'shell' was the coolest part of rebar3 and I'm > like, 'what is that'? And voila! It's what I needed. > > This should be on the golden path. > > $ cd myfooapp > $ rebar3 shell myfooapp > > > ### Where is the golden path? > > It's weird that there is no golden path. [In this talk][2], at 14:50, Fred > talks > about how it's only far into various Erlang books that authors start > talking > about running code outside the shell, in contrast to K&R C where it's > discussed > on page 6. In fact, the entire (excellent) presentation is on the terrible > state > of tooling in the Erlang ecosystem. > > *begin rant* > > #### Here's what's weird about Erlang : Books are out of date > > * The books are already out of date. Even [LYSEFGG][9] still talks about > [systools][11] and [reltool][12] even though [rebar3][7] and [relx][10] > have > supplanted them? What's weird about this is to be reading the rebar3 > documentation, then cross-referencing with relx, and reading the various > books > that describe the old ways of building releases and relups, etc. > > #### Docs are hard to follow > > * [relx][10] documentation is pretty hard to follow > * Community support seems fragmented > * [Github shows relx][14] has 41 open issues and 6 open pull requests, > with > 89 contributors > * [Github shows rebar3][13] has 107 open issues and 11 open pull > requests, > with 239 contributors > > #### Who's maintaining these tools? > > If I were Tristan or Fred, boy I'd be tired of supporting this stuff. > > #### Where are the videos? > > Here's another thing that's weird... > > I cannot find videos on how to use the Erlang shell. So on top of that > weird > fact, I'm finding out about erlang by watching Elixir videos. I was > watching an > Elixir video on 'wobserver' and realized, 'Hey! I bet that's just a web > interface on some Erlang thingy called "observer"'. So then I find out > about > 'observer' and how useful that is. Great! But things like, how to I do > basic > stuff like navigate from one process to another, what do I do when > everything > seems hung and broken, what do real live seasoned Erlang devs do when > '_stuff_ > hit's the fan'? How do they go about examining a running system? The web > seems > to have nothing on this. But that's just weird, b/c Erlang has been around > for > over 25 years, and any other language / framework/ runtime whatever has > zillions > of youtube videos. > > *end rant* > > ## Culture of Quick Fixes > > OK, so enough ranting. Let me get into [Fred's mention of the 'Culture of > Quick > Fixes'][2] (at about 21:00) by introducing my own steaming pile of a quick > fix. > > So here's the deal. I'm trying to build a [company][15]. I have limited > $$$, I > can't screw around learning stuff forever. At some point I have to build a > real > live app and try to generate some buzz. I'll roughly describe my first > app/service and run through my decision points... > > ### App > > The app basically pulls data from publicly available but disparate data > sets, > ingests them, normalizes them into a common data store, and then surfaces > the > data store for analysis, reporting, AI/ML, etc, etc. In a nutshell, take > data, > add magic, produce pretty pictures. > > ### Process > > * prototype in bash (or python, or whatever...) > > Seriously, with just `bash` and I can query for my data, extract in, play > around with it, etc. If I wanted I could hook it up to `cron` and probably > move on > to actually using the data rather than learning Erlang and how to build > 'proper' > infrastructure. > > ### Prototype in escript > > Here's where I take small tasks and learn the Erlang libraries to > accomplish > what I'm trying to do. It takes about as much time to do this as the > previous > prototyping step. I find this to be a great way to both decompose a > problem and > learn a new language. > > ### Start building industrial grade services > > So now, rather than focusing on my business, finding customers, analyzing > the > data I've collected, or in any other way providing value that could bring > in > revenue and allow me to purchase more Erlang books... I'm veering off into > the > weeds and learning how to: > > * build erlang apps for real > * build erlang releases > * wire all this into docker containers > * wire in monitoring and all the 'industrial grade goodies' > > Along the way I tend to post about what I learn [here][5]. > > * Is any of this worthwhile? > * Am I just engaged in endless pencil sharpening? > * I dunno. I'm too close to the fire. > > I'm having fun though. And it's incredibly useful to my brain in some way > I cannot describe. > > ### The Problem > > So back to "The Culture of Quick Fixes". As I'm building my first set of > components and learning about rebar.config and config/sys.config and more > groovy > stuff, I run into the issue of how to deploy Erlang to docker containers. > The > answer is, run the release with the `foreground` command. But this wasn't > obvious to me at first and took a lot of digging around the 'net, [posting > a > question on the rebar3 discussion list][16], and just general noodling > around. > > But, if I'm building industrial grade applications, then I need to solve > for > issues such as: > > * How do I emit metrics from my app? > * How do I monitor my metrics (e.g. Prometheus)? > * How do I hook up a visualization tool (e.g. Grafana)? Alarms? > * And how do I wire all this up into a containerized solution so that it's > re-usable and shareable? > * Don't forget my "awesome" Makefiles! I like to have a common control > plane for > all my services, and common Makefiles are great for this. > > Now, if you watched the end of Fred's video, he was talking about many of > these > same things. > > *And I'll suggest that what I've built is an example of exactly what > shouldn't be done:* > > * I ignored everything on hex. Why? Um, I don't really understand hex that > well > yet, I'd have to go read a bunch of code to understand what folks have > done, > and I'm still learning Erlang by building things myself. None of these > is a > good reason, BTW. > * I only published my stuff to github, and not to hex. This may be a good > thing > as I'd just be duplicating other, probably better, efforts. > * What I built should probably be a rebar3 plugin, and not a Makefile with > dependencies on rebar3 etc. > > However, I'll show you what this is because I think it satisfies a need and > perhaps we can all come up with a better implementation strategy. Or learn > something. > > ## Erlang-Seed > > So, here we have 'yet-another-quick-fix' called [erlang-seed][17]. Let me > be > honest, this is a 'quick-fix' to satisfy my own personal needs... > > ### The Good > > What this does is create an erlang application, inject it into a Docker > container, and then spin up a local Docker cluster that monitors the > Erlang app > and surfaces the metrics via Prometheus and Grafana. So with one command I > can > generate an OTP application, all the infrastructure necessary to monitor > it with > common tooling, _and_ spin it up and run it on my dev box. I find this to > be > really useful. YMMV. > > ### The Bad > > This is really crufty. It calls into rebar3 to generate the app. It should > probably be a rebar3 plugin so that it can better evolve with the tooling. > It > could then more intelligently inject the necessary dependencies, > instrument the > code with metrics, etc. Right now it's gross, as it just overwrites files > as > necessary using mustache templates. > > ### The Ugly > > * Do I have time to maintain this? No. > * Do I have time to make this a rebar3 plugin? Not right now. > * Will this probably break over time due to either rebar3, docker, or some > other dependency changing? Certainly, eventually, yes. > > > ## Summary > > The reason I'm sharing this is to just widen the discussion on what the > Erlang > education and tooling could look like. I think that generating full stacks > that > allow developers to focus more on solving business domain issues rather > than > forcing them to understand all the arcane details of whatever is under the > covers is the 'way to go (TM)'. There's got to be a way to allow > developers to > maintain velocity while increasing their depth and scope of knowledge as > necessary. I've been studying Erlang intensely for at least a month now, > read > the books _countless_ times, and read the online docs and I still don't > quite > understand how this all fits together. I mean I get the big picture. But > there's > a _lot_ of details. > > Contrast this with Go. I was writing production code in 2 days. The > quality was > production quality after about a week. Back in the day it took me about a > month > to become proficient in Java, though it required reading Bloch's book "Java > Concurrency In Practice" to be 'good'. Python was similar, it took about a > week > to ramp up, about a month to become comfortable. In all of these languages > it > was a relatively short and easy ramp up and then smooth sailing for years > and > years. > > With Erlang it's an incredibly steep ramp that goes on and on. I guess if I > remember that I'm learning the equivalent of a language, an orchestration > framework (like kubernetes), a database system, etc., then it starts to > make > sense. > > Anyway, for my part, I'll keep posting things as I figure them out. > > -Todd > > [0]:https://www.erlang.org/ > [1]:https://ferd.ca/ten-years-of-erlang.html > [2]:https://youtu.be/Z28SDd9bXcE?t=1260 > [3]:https://github.com/ToddG/experimental/tree/master/erlang/wilderness > [4]: > https://github.com/ToddG/experimental/blob/master/erlang/resources/books.md > [5]:http://zwrob.com/posts > [6]:https://github.com/asdf-vm/asdf > [7]:https://www.rebar3.org > [8]:https://github.com/kerl/kerl > [9]:https://learnyousomeerlang.com/ > [10]:https://github.com/erlware/relx > [11]:http://erlang.org/doc/man/systools.html > [12]:http://erlang.org/doc/man/reltool.html > [13]:https://github.com/erlang/rebar3 > [14]:https://github.com/erlware/relx > [15]:http://envirosoftwaresolutions.com > [16]:https://www.rebar3.org/discuss/5d29172873e1ed00447cb362 > [17]:https://github.com/ToddG/erlang-seed > [18]:http://zwrob.com/posts/developer-automation/ > > -Todd > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Tue Jul 16 15:58:18 2019 From: rtrlists@REDACTED (Robert Raschke) Date: Tue, 16 Jul 2019 15:58:18 +0200 Subject: [erlang-questions] ftp lib behaviour has changed between ftp-1.0.1 and ftp-1.0.2 In-Reply-To: References: Message-ID: Hi Ingela, the server I see this behaviour on is: Pure-FTPd - http://pureftpd.org/ If I can find the time, I will try to raise a report. Might take a bit. Also, the ftp server is not mine, but a live commercial installation. So I'm not sure about the parameters of their installation or if I can ever find out. Cheer, Robby On Fri, 12 Jul 2019 at 11:52, Ingela Andin wrote: > Hi Robert! > > Can you provide a reliable way to reproduce the problem it will help > getting it fixed. Have you tried to run our ftp test suite? > It passes in our tests runs. The possible bug might be server dependent. > > Could you report it at https://bugs.erlang.org/ > > Regards Ingela Erlang/OTP Team - Ericsson AB > > Den fre 12 juli 2019 kl 10:43 skrev Robert Raschke < > rtrlists@REDACTED>: > >> Hi Ingela, >> >> I just had a case of ftp:recv_bin(FTP, "filename") repeatedly returned >> only 'ok'. >> That is, my hoped for workaround of simply retrying the operation fails. >> >> This makes version 1.0.2 of the ftp lib unusable, I'm afraid. >> I will have to revert to an earlier version. >> >> Cheers, >> Robby >> >> >> On Tue, 9 Jul 2019 at 20:49, Ingela Andin wrote: >> >>> Hi Robert! >>> >>> Well it somewhat unexpected that it returns an undocumented value. It >>> might be that the correction made to fix a timing bug in the FTP >>> application, that >>> was exposed by TLS optimizations when running FTP over TLS, uncovered >>> some other timing bug. Most of the FTP code is very old and I wished for >>> the gen_statem behavior while fixing the bug I just mentioned, so I would >>> not be very surprised if there are more race conditions in that code. >>> >>> Regards Ingela Erlang/OTP team >>> >>> Den m?n 8 juli 2019 kl 18:11 skrev Robert Raschke < >>> rtrlists@REDACTED>: >>> >>>> Hi, >>>> >>>> I have code that matches on {ok, Result} and {error, Reason} tuples >>>> coming from calls to ftp:ls/2 and ftp:recv_bin/2 (on 21.1, ftp-1.0.1) and >>>> upgrading to 21.3 (ftp-1.0.2) sometimes returns a simple ok on those calls. >>>> This is surprising. >>>> >>>> 15> f(). >>>> >>>> ok >>>> >>>> 16> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", >>>> "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), >>>> ftp:close(FTP), R. >>>> >>>> {ok,"-rw-r--r-- 1 2001 2001 174993 Jul 8 17:16 >>>> ..."} >>>> >>>> 17> f(). >>>> >>>> ok >>>> >>>> 18> {ok, FTP} = ftp:open("somesite"), ok = ftp:user(FTP, "someuser", >>>> "somepwd"), timer:sleep(100), R = ftp:ls(FTP, "/somefolder/*"), >>>> ftp:close(FTP), R. >>>> >>>> ok >>>> >>>> 19> >>>> >>>> >>>> What might be the reason for this? And is this expected? >>>> >>>> >>>> Cheers, >>>> >>>> Robby >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Wed Jul 17 17:52:54 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 17 Jul 2019 18:52:54 +0300 Subject: [erlang-questions] How to properly stop complicated async NIF resource. Message-ID: Hi. We are writing NIF wrapper for OpenMAX ? standard API for transcoding video on Android or Raspberry Pi. This API requires to launch separate thread (launched by library) and this thread receives some events from hardware. This thread wraps hardware events in erlang messages and sends them to owner process. All this looks really cool and we have excellently working happy path of code. When whole resource is to be destroyed, we need to clean it properly, shutdown all opened hardware handlers. Right now we have to write complicated code on C in destructor that calls cond_wait, mutex_lock, etc. The same code in erlang is 100 times cleaner and easier, however in destructor we cannot write in erlang. I cannot exit from destructor function and ask to continue destructing when separate thread will be activated by hardware. So it would be cool to continue having erlang vm even in destructor or make something like "delayed destructor" with "I promise to finish this destruction". Question is: is my problem well known or it is very specific? -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlsson.rm@REDACTED Wed Jul 17 19:39:42 2019 From: karlsson.rm@REDACTED (Mikael Karlsson) Date: Wed, 17 Jul 2019 19:39:42 +0200 Subject: [erlang-questions] How to properly stop complicated async NIF resource. In-Reply-To: References: Message-ID: Hi Max, I had a similar problem when interfacing towards the ALSA library for sound generation on Linux, but it is probably much more simple than your case so I am not sure it will help. For every thread I have a peer gen_server that opens a handle in a resource and starts the callback thread (I get events every 5 ms) in init/1 and handle_continue/2 function . When the gen_server is shutdown and terminate/2 is called I call the a nif to close the handle. The resource itself is garbage collected by erlang (I think :-) ). What I noticed was that I had to set the process_flag(trap_exit, true) in order to have the terminate function called at supervisor:terminate_child/2 . I am not sure what you are meaning with delayed destructor but if you need a lot of time for complete destruction maybe you can orchestrate it from a separately spawned erlang process that calls the proper nifs. You can checkout my code at https://github.com/karlsson/xalsa , mainly c_src/xalsa_nif.c and src/xalsa_server.erl Best Regards Mikael Den ons 17 juli 2019 kl 17:53 skrev Max Lapshin : > Hi. > > We are writing NIF wrapper for OpenMAX ? standard API for transcoding > video on Android or Raspberry Pi. > > This API requires to launch separate thread (launched by library) and this > thread receives some events from hardware. This thread wraps hardware > events in erlang messages and sends them to owner process. All this looks > really cool and we have excellently working happy path of code. > > When whole resource is to be destroyed, we need to clean it properly, > shutdown all opened hardware handlers. Right now we have to write > complicated code on C in destructor that calls cond_wait, mutex_lock, etc. > > The same code in erlang is 100 times cleaner and easier, however in > destructor we cannot write in erlang. I cannot exit from destructor > function and ask to continue destructing when separate thread will be > activated by hardware. > > So it would be cool to continue having erlang vm even in destructor or > make something like "delayed destructor" with "I promise to finish this > destruction". > > Question is: is my problem well known or it is very specific? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity@REDACTED Wed Jul 17 20:52:46 2019 From: icfp.publicity@REDACTED (Sam Tobin-Hochstadt) Date: Wed, 17 Jul 2019 14:52:46 -0400 Subject: [erlang-questions] Second Call for Participation: ICFP 2019 Message-ID: <5d2f6e7ecf56c_68f92ae6da55e5c4450b6@homer.mail> ** The Early Registration deadline is tomorrow! ** ===================================================================== Call for Participation ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 18 - August 23, 2019 Berlin, Germany http://icfp19.sigplan.org/ Early Registration until July 18! ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. This year, ICFP is co-located with BOBKonf! * Overview and affiliated events: http://icfp19.sigplan.org/home * Program: http://icfp19.sigplan.org/program/program-icfp-2019 * Accepted papers: http://icfp19.sigplan.org/track/icfp-2019-papers * Registration is available via: https://regmaster4.com/2019conf/ICFP19/register.php Early registration ends 18 July, 2019. * Programming contest: https://icfpcontest2019.github.io/ * Student Research Competition: https://icfp19.sigplan.org/track/icfp-2019-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference In addition to BOBKonf (8/21), there are several events co-located with ICFP: * Erlang Workshop (8/18) * Functional Art, Music, Modeling and Design (8/23) * Functional High-Performance and Numerical Computing (8/18) * Haskell Implementors' Workshop (8/23) * Haskell Symposium (8/22-8/23) * miniKanren Workshop (8/22) * ML Family Workshop (8/22) * OCaml Workshop (8/23) * Programming Languages Mentoring Workshop (8/18) * Scheme Workshop (8/18) * Type-Driven Development (8/18) ### ICFP Organizers General Chair: Derek Dreyer (MPI-SWS, Germany) Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Ilya Sergey (Yale-NUS College, Singapore) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: William J. Bowman (University of British Columbia, Canada) Workshops Co-Chair: Christophe Scholliers (Universiteit Gent, Belgium) Jennifer Hackett (University of Nottingham, UK) Conference Manager: Annabel Satin (P.C.K.) ### PACMPL Volume 3, Issue ICFP 2019 Principal Editor: Fran?ois Pottier (Inria, France) Review Committee: Lennart Beringer (Princeton University, United States) Joachim Breitner (DFINITY Foundation, Germany) Laura M. Castro (University of A Coru?a, Spain) Ezgi ?i?ek (Facebook London, United Kingdom) Pierre-Evariste Dagand (LIP6/CNRS, France) Christos Dimoulas (Northwestern University, United States) Jacques-Henri Jourdan (CNRS, LRI, Universit? Paris-Sud, France) Andrew Kennedy (Facebook London, United Kingdom) Daan Leijen (Microsoft Research, United States) Kazutaka Matsuda (Tohoku University, Japan) Bruno C. d. S. Oliveira (University of Hong Kong, China) Klaus Ostermann (University of T?bingen, Germany) Jennifer Paykin (Galois, United States) Frank Pfenning (Carnegie Mellon University, USA) Mike Rainey (Indiana University, USA) Chung-chieh Shan (Indiana University, USA) Sam Staton (University of Oxford, UK) Pierre-Yves Strub (Ecole Polytechnique, France) German Vidal (Universitat Politecnica de Valencia, Spain) External Review Committee: Michael D. Adams (University of Utah, USA) Robert Atkey (University of Strathclyde, IK) Sheng Chen (University of Louisiana at Lafayette, USA) James Cheney (University of Edinburgh, UK) Adam Chlipala (Massachusetts Institute of Technology, USA) Evelyne Contejean (LRI, Universit? Paris-Sud, France) Germ?n Andr?s Delbianco (IRIF, Universit? Paris Diderot, France) Dominique Devriese (Vrije Universiteit Brussel, Belgium) Richard A. Eisenberg (Bryn Mawr College, USA) Conal Elliott (Target, USA) Sebastian Erdweg (Delft University of Technology, Netherlands) Michael Greenberg (Pomona College, USA) Adrien Guatto (IRIF, Universit? Paris Diderot, France) Jennifer Hackett (University of Nottingham, UK) Troels Henriksen (University of Copenhagen, Denmark) Chung-Kil Hur (Seoul National University, Republic of Korea) Roberto Ierusalimschy (PUC-Rio, Brazil) Ranjit Jhala (University of California, San Diego, USA) Ralf Jung (MPI-SWS, Germany) Ohad Kammar (University of Oxford, UK) Oleg Kiselyov (Tohoku University, Japan) Hsiang-Shang ?Josh? Ko (National Institute of Informatics, Japan) Ond?ej Lhot?k (University of Waterloo, Canada) Dan Licata (Wesleyan University, USA) Geoffrey Mainland (Drexel University, USA) Simon Marlow (Facebook, UK) Akimasa Morihata (University of Tokyo, Japan) Shin-Cheng Mu (Academia Sinica, Taiwan) Guillaume Munch-Maccagnoni (Inria, France) Kim Nguy?n (University of Paris-Sud, France) Ulf Norell (Gothenburg University, Sweden) Atsushi Ohori (Tohoku University, Japan) Rex Page (University of Oklahoma, USA) Zoe Paraskevopoulou (Princeton University, USA) Nadia Polikarpova (University of California, San Diego, USA) Jonathan Protzenko (Microsoft Research, USA) Tiark Rompf (Purdue University, USA) Andreas Rossberg (Dfinity, Germany) KC Sivaramakrishnan (University of Cambridge, UI) Nicholas Smallbone (Chalmers University of Technology, Sweden) Matthieu Sozeau (Inria, France) Sandro Stucki (Chalmers | University of Gothenburg, Sweden) Don Syme (Microsoft, UK) Zachary Tatlock (University of Washington, USA) Sam Tobin-Hochstadt (Indiana University, USA) Takeshi Tsukada (University of Tokyo, Japan) Tarmo Uustalu (Reykjavik University, Iceland) Benoit Valiron (LRI, CentraleSupelec, Univ. Paris Saclay, France) Daniel Winograd-Cort (University of Pennsylvania, USA) Nicolas Wu (University of Bristol, UK) From max.lapshin@REDACTED Wed Jul 17 21:45:32 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 17 Jul 2019 22:45:32 +0300 Subject: [erlang-questions] How to properly stop complicated async NIF resource. In-Reply-To: References: Message-ID: I'm afraid of the situation when the only resource owner is killed and resource must be destroyed by calling destructor. It is too late to call to erlang at this time =( However, your idea is interesting. I can register some destruction manager just like a "hier" in ets and when resource is going to be killed, or its owner is going to be killed, we send a message to the "destruction manager" and it will clean without these messy cond_wait_timeout calls. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlsson.rm@REDACTED Thu Jul 18 03:19:52 2019 From: karlsson.rm@REDACTED (Mikael Karlsson) Date: Thu, 18 Jul 2019 03:19:52 +0200 Subject: [erlang-questions] How to properly stop complicated async NIF resource. In-Reply-To: References: Message-ID: Wed 17 July 2019 21:45 Max Lapshin wrote: > I'm afraid of the situation when the only resource owner is killed and > resource must be destroyed by calling destructor. > > It is too late to call to erlang at this time =( > > However, your idea is interesting. I can register some destruction > manager just like a "hier" in ets and when resource is going to be killed, > or its owner is going to be killed, we send a message to the "destruction > manager" and it will clean without these messy cond_wait_timeout calls. > I think I understand.... In my case I do not even register a destructor callback since I do not need to. Just some other ideas, maybe it is possible to use the enif_open_resource_type_x function to register a "down" function and then monitor your resource owner process from the thread with enif_monitor_process. I guess that the down callback would be called from within your thread and then you could cleanup in that without the need of mutexes and cond_wait_timout calls. Or if enif_send is called often you could check if it returns false, which means that to_pid or sender is not alive, and then perform cleanup in that case. Also just to be clear, even if you start a thread from an API it will run within the erlang VM if you can call enif_send: http://erlang.org/pipermail/erlang-questions/2019-May/097983.html It took me some time (and help from OTP developer) to understand this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Jul 18 09:19:15 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 18 Jul 2019 10:19:15 +0300 Subject: [erlang-questions] How to properly stop complicated async NIF resource. In-Reply-To: References: Message-ID: I've refactored my code and now there is a special killing process near each NIF resource. It will properly shutdown hardware when nif owner is dead. nif destructor now is a bit useless, because it is called when everything is done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me@REDACTED Thu Jul 18 12:57:40 2019 From: me@REDACTED (Bernard Kolobara) Date: Thu, 18 Jul 2019 12:57:40 +0200 Subject: [erlang-questions] crypto.generate_key() with PrivKeyIn fails Message-ID: Hi, I?m trying to generate a public key out of a private one, but I get a bad argument exception. Without passing in a private key everything works as expected: 5> {A, B} = crypto:generate_key(ecdh, x25519). {<<88,216,213,80,104,49,248,233,208,241,195,111,5,45,82, ?? 92,137,30,43,41,127,9,104,22,219,147,147,160,...>>, <<248,251,237,26,106,194,122,49,49,147,162,189,80,223, ?? 224,216,21,126,161,1,101,38,43,21,161,98,92,...>>} But if I add a private key to the function: 6> crypto:generate_key(ecdh, x25519, B).????? ** exception error: bad argument ???? in function? crypto:ec_key_generate/2 ??????? called as crypto:ec_key_generate({evp,x25519}, ???????????????????????????????????????? <<248,251,237,26,106,194,122,49,49,147,162,189,80,223, ?????????????????????????????????????????? 224,216,21,126,161,1,101,38,43,21,161,98,92,...>>) Also being new to this I?m a bit confused with the output of: 7> crypto:info_lib(). [{<<"OpenSSL">>,269488191, ? <<"OpenSSL 1.1.1c? 28 May 2019">>}] But my system openssl command reports a different version, but same date: sh> openssl version OpenSSL 1.0.2s? 28 May 2019 Cheers, Bernard -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlsson.rm@REDACTED Thu Jul 18 21:46:41 2019 From: karlsson.rm@REDACTED (Mikael Karlsson) Date: Thu, 18 Jul 2019 21:46:41 +0200 Subject: [erlang-questions] How to properly stop complicated async NIF resource. In-Reply-To: References: Message-ID: > I've refactored my code and now there is a special killing process near > each NIF resource. > > It will properly shutdown hardware when nif owner is dead. > Nice. nif destructor now is a bit useless, because it is called when everything > is done. > Guess you just can replace it with NULL when it gets completely useless. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Jul 18 22:08:29 2019 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 18 Jul 2019 23:08:29 +0300 Subject: [erlang-questions] How to properly stop complicated async NIF resource. In-Reply-To: References: Message-ID: I'm afraid that I need to replace it with something like: if(!obj->cleaned) { fprintf(stderr, "We should not get here"); abort(); } because if we get to destructor without calling erlang destructor, it means that we need to reboot whole program and after 5 times reboot whole device with power cycle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlsson.rm@REDACTED Thu Jul 18 22:33:30 2019 From: karlsson.rm@REDACTED (Mikael Karlsson) Date: Thu, 18 Jul 2019 22:33:30 +0200 Subject: [erlang-questions] How to properly stop complicated async NIF resource. In-Reply-To: References: Message-ID: > because if we get to destructor without calling erlang destructor, it > means that we need to reboot whole program and after 5 times reboot whole > device with power cycle. > > OK, this brings me a bit back to previous discussion about enif_release_resource. If you do not call enif_release_resource in the same function as when you do enif_allocate_resource but wait until you have cleaned everything up with the killing process ("erlang destructor") you will make sure that garbage collection and destructor call will not happen before this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From v@REDACTED Fri Jul 19 11:00:18 2019 From: v@REDACTED (Valentin Micic) Date: Fri, 19 Jul 2019 11:00:18 +0200 Subject: [erlang-questions] HiPE and BIF Message-ID: Hi all, It is my understanding (as per Erlang Manual) that if a module that has been compiled using HiPE calls a function in a module that is not (compiled using HiPE), then there may be a performance penalty that is due to "mode switching?. Does this assertion hold when HiPE compiled module calls BIF as well? Kind regards V/ From mikpelinux@REDACTED Fri Jul 19 11:29:38 2019 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Fri, 19 Jul 2019 11:29:38 +0200 Subject: [erlang-questions] HiPE and BIF In-Reply-To: References: Message-ID: On Fri, Jul 19, 2019 at 11:00 AM Valentin Micic wrote: > It is my understanding (as per Erlang Manual) that if a module that has been compiled using HiPE calls a function in a module that is not (compiled using HiPE), then there may be a performance penalty that is due to "mode switching?. Correct. A similar penalty occurs if BEAM code calls native code, so you'll want to minimize the number of transitions between native and BEAM (either direction). > Does this assertion hold when HiPE compiled module calls BIF as well? No. Calling a BIF is more direct and does not involve any "mode switch", so it's fairly efficient. /Mikael From bryan.hunt@REDACTED Sat Jul 20 20:58:25 2019 From: bryan.hunt@REDACTED (Bryan Hunt) Date: Sat, 20 Jul 2019 19:58:25 +0100 Subject: [erlang-questions] Common test can't find NIF shared object library Message-ID: <370E2272-DE31-4EF9-BE1B-9807E505F284@erlang-solutions.com> I?m trying to resurrect an old library (epgpme) so I?ve added a rebar3 configuration using the ports compiler (pc) plugin. It compiles the code fine and the nif is generated to 'priv/egpgme_nif.so? (which looks fine). However, when I run the ct suite it?s looking for the nif in '_build/test/lib/egpgme/priv/egpgme_nif.so?, so the tests fail. I?ve messed around with a couple of configurations but can?t figure out the problem - can anyone offer a suggestion? Thanks, Bryan {erl_opts, [debug_info, warnings_as_errors]}. %% Compile nif using port compiler plugin {plugins, [pc,rebar3_hex]}. {artifacts, ["priv/epgpme_nif.so"]}. {port_env, [ {"CFLAGS", "$CFLAGS -I/usr/local/include "}, {"LDFLAGS", "$LDFLAGS -L/usr/local/lib -lgpgme"} ]}. {port_specs, [{ "priv/epgpme_nif.so", ["c_src/*.c"] }]}. {provider_hooks, [ {pre, [ {compile, {pc, compile}}, {test, {pc, compile}}, {clean, {pc, clean}} ] } ] }. /code/common/egpgme/ make test ===> Verifying dependencies... ===> Compiling egpgme ===> Verifying dependencies... ===> Compiling egpgme ===> Running Common Test suites... %%% basic_SUITE: .... =WARNING REPORT==== 20-Jul-2019::19:56:03 === The on_load function for module egpgme returned: {error,{load_failed,"Failed to load NIF library: 'dlopen(/code/common/egpgme/_build/test/lib/egpgme/priv/egpgme_nif.so, 2): image not found'"}} %%% basic_SUITE ==> run_export: FAILED %%% basic_SUITE ==> {undef,[{egpgme,context,[],[]}, {basic_SUITE,run_export,1, [{file,"/code/common/egpgme/test/basic_SUITE.erl"}, {line,41}]}, {test_server,ts_tc,3,[{file,"test_server.erl"},{line,1529}]}, {test_server,run_test_case_eval1,6, [{file,"test_server.erl"},{line,1045}]}, {test_server,run_test_case_eval,9, [{file,"test_server.erl"},{line,977}]}]} ... %%% gpg_SUITE: ................... EXPERIMENTAL: Writing retry specification at /code/common/egpgme/_build/test/logs/retry.spec call rebar3 ct with '--retry' to re-run failing cases. Failed 1 tests. Passed 26 tests. Results written to "/code/common/egpgme/_build/test/logs/index.html". ===> Failures occurred running tests: 1 make: *** [test] Error 1 find . -name "*.so" ./priv/epgpme_nif.so -- Code Sync & Erlang Solutions Conferences Code Elixir LDN - London: 18 July 2019 Code BEAM Lite BD - Budapest: 20 September 2019 Code BEAM Lite NYC - NYC: 01 October 2019 RabbitMQ Summit - London: 4 November 2019 Code Mesh LDN - London: 7-8 November 2019 Code BEAM Lite India - Bangalore: 14 November 2019 Code BEAM Lite AMS - Amsterdam: 29 November 2019 Lambda Days - Krak?w: 13-14 February 2020 Code BEAM SF - San Francisco: 5-6 March 2020 *Erlang Solutions cares about your data and privacy; please find all details about the basis for communicating with you and the way we process your data in our?**Privacy Policy* *.You can update your email preferences or opt-out from receiving Marketing emails?here .* From areege.alzubaidi@REDACTED Mon Jul 22 18:14:50 2019 From: areege.alzubaidi@REDACTED (Areege Al Zubaidi) Date: Mon, 22 Jul 2019 17:14:50 +0100 Subject: [erlang-questions] Code BEAM Lite NYC - fintech x the BEAM - VEB ends tomorrow! Message-ID: Code BEAM Lite NYC tickets launched last week! Get your ticket to the first-ever Erlang and Elixir event for the fintech space! There are world-class Erlang, Elixir, Phoenix, and RabbitMQ training and tutorials on offer around the conference: * OTP for the seasoned Erlanger by Francesco Cesarini (3-days) * Professional LiveView and OTP by Bruce Tate (3-days) * Crash course in Elixir by Chris Bell (1-day) * RabbitMQ express by Brett Cameron (1-day) * Building resilient distributed systems with Elixir by Chris Keathley (1-day) PS: for our 3-day training courses, buy bundled with a conference ticket to get 10% off! A very limited number of very early bird tickets are available, and will close *tomorrow at 23:59 EDT*! Buy now to avoid disappointment! We hope to see you in NYC! Areege -- *Areege Al Zubaidi* *Conferences Marketing Executive* T: +44 (0) 2076550332 W: www.codesync.global A: Erlang Solutions Ltd, The Loom,14 Gower's Walk, London, E1 8PY -- Code Sync & Erlang Solutions Conferences Code BEAM Lite BD - Budapest: 20 September 2019 Code BEAM Lite NYC - NYC: 01 October 2019 RabbitMQ Summit - London: 4 November 2019 Code Mesh LDN - London: 7-8 November 2019 Code BEAM Lite India - Bangalore: 14 November 2019 Code BEAM Lite AMS - Amsterdam: 29 November 2019 Lambda Days - Krak?w: 13-14 February 2020 Code BEAM SF - San Francisco: 5-6 March 2020 *Erlang Solutions cares about your data and privacy; please find all details about the basis for communicating with you and the way we process your data in our?**Privacy Policy* *.You can update your email preferences or opt-out from receiving Marketing emails?here .* -------------- next part -------------- An HTML attachment was scrubbed... URL: From elbrujohalcon@REDACTED Mon Jul 22 21:07:06 2019 From: elbrujohalcon@REDACTED (Brujo Benavides) Date: Mon, 22 Jul 2019 16:07:06 -0300 Subject: [erlang-questions] [ANN] 2 months until SpawnFest 2019 Message-ID: <4D1B6ECE-A31C-4DFE-9250-D6A795DD0160@gmail.com> Hey erlangers! We?re just 2 months away from our annual hackathon: SpawnFest! The free online competition where teams compete for prizes by creating a BEAM-based app in 48 hours will take place on September 21 and 22. Remember: - All projects should be written to run on the Erlang VM / BEAM. - They can be written in any BEAM-based language (i.e. Erlang, Elixir, LFE, efene, clojerl, etc.). - Supplementary languages such as Javascript (and JS frameworks) are allowed. More information on our website . Build your team and register it here ! As usual, we?re also looking for sponsors. If your company wants to contribute with a prize for the winners, please fill out this form and join us! Contact us at spawnfest-organizers@REDACTED if you have any questions! Brujo Benavides -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.r.nohl@REDACTED Wed Jul 24 10:38:00 2019 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Wed, 24 Jul 2019 10:38:00 +0200 Subject: [erlang-questions] Erlang machine stopped instantly (distribution name conflict?). Message-ID: Hello! I have a (rebar3-generated) project using Erlang 20.3 that I try to start on Windows 10. I can "install" the Windows service, but when I try to start it, I get this "Erlang machine stopped instantly (distribution name conflict?)." error in the Windows logs. I can start a node (using werl.exe) with the node name (at least with the node name that is supposed to be used). On Google I found plenty of this errors related to RabbitMQ, but I haven't find a solution that's applicable to my case yet (I mean deleting RabbitMQ app data won't help me). I'm not quite sure how to debug it at all - how can I see exactly what command is executed to start the Erlang VM? From attila.r.nohl@REDACTED Wed Jul 24 11:11:56 2019 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Wed, 24 Jul 2019 11:11:56 +0200 Subject: [erlang-questions] Erlang machine stopped instantly (distribution name conflict?). In-Reply-To: References: Message-ID: Attila Rajmund Nohl ezt ?rta (id?pont: 2019. j?l. 24., Sze, 10:38): > > Hello! > > I have a (rebar3-generated) project using Erlang 20.3 that I try to > start on Windows 10. I can "install" the Windows service, but when I > try to start it, I get this > > "Erlang machine stopped instantly (distribution name conflict?)." > > error in the Windows logs. I can start a node (using werl.exe) with > the node name (at least with the node name that is supposed to be > used). On Google I found plenty of this errors related to RabbitMQ, > but I haven't find a solution that's applicable to my case yet (I mean > deleting RabbitMQ app data won't help me). I'm not quite sure how to > debug it at all - how can I see exactly what command is executed to > start the Erlang VM? Process Monitor from sysinternals helped me, I found the command line and also that an erl_crash.dump was written with this slogan: init terminating in do_boot ({load_failed,[kernel,erl_eval,erl_parse,erl_lint,gen,gen_event,gen_server,supervisor,file,error_logger,code_server,application_master,file_io_server,code,file_server,ets,a I guess some path is not correct somewhere. From vicbaz@REDACTED Wed Jul 24 11:29:42 2019 From: vicbaz@REDACTED (vicbaz@REDACTED) Date: Wed, 24 Jul 2019 12:29:42 +0300 Subject: [erlang-questions] Erlang machine stopped instantly (distribution name conflict?). In-Reply-To: References: Message-ID: <0a4d9481-500d-c600-3ab7-26715e4c3635@yandex.ru> Hello, Could you show vm.args? On 24/07/2019 11:38, Attila Rajmund Nohl wrote: > Hello! > > I have a (rebar3-generated) project using Erlang 20.3 that I try to > start on Windows 10. I can "install" the Windows service, but when I > try to start it, I get this > > "Erlang machine stopped instantly (distribution name conflict?)." > > error in the Windows logs. I can start a node (using werl.exe) with > the node name (at least with the node name that is supposed to be > used). On Google I found plenty of this errors related to RabbitMQ, > but I haven't find a solution that's applicable to my case yet (I mean > deleting RabbitMQ app data won't help me). I'm not quite sure how to > debug it at all - how can I see exactly what command is executed to > start the Erlang VM? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From attila.r.nohl@REDACTED Wed Jul 24 12:42:34 2019 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Wed, 24 Jul 2019 12:42:34 +0200 Subject: [erlang-questions] Erlang machine stopped instantly (distribution name conflict?). In-Reply-To: <0a4d9481-500d-c600-3ab7-26715e4c3635@yandex.ru> References: <0a4d9481-500d-c600-3ab7-26715e4c3635@yandex.ru> Message-ID: Hello! My built release was wrong (previously I tried to build with a different erts version and somehow the beam files got mixed up). I did a clean build, now I don't get erl_crash.dump file, only an error. The interesting part of the vm.args file (I modified the name and cookie because the generated file had $VARIABLE values and I wasn't sure they would work): ## Name of the node -name app@REDACTED ## Cookie for distributed erlang -setcookie app ## Start the node as a hidden node -hidden ## Heartbeat management; auto-restarts VM if it dies or becomes unresponsive ## (Disabled by default..use with caution!) -heart ## Enable kernel poll +K true ## -smp auto starts the Erlang runtime system with SMP support enabled if it is ## available and more than one logical processor are detected. -smp auto ezt ?rta (id?pont: 2019. j?l. 24., Sze, 11:29): > > Hello, > > Could you show vm.args? > > On 24/07/2019 11:38, Attila Rajmund Nohl wrote: > > Hello! > > > > I have a (rebar3-generated) project using Erlang 20.3 that I try to > > start on Windows 10. I can "install" the Windows service, but when I > > try to start it, I get this > > > > "Erlang machine stopped instantly (distribution name conflict?)." > > > > error in the Windows logs. I can start a node (using werl.exe) with > > the node name (at least with the node name that is supposed to be > > used). On Google I found plenty of this errors related to RabbitMQ, > > but I haven't find a solution that's applicable to my case yet (I mean > > deleting RabbitMQ app data won't help me). I'm not quite sure how to > > debug it at all - how can I see exactly what command is executed to > > start the Erlang VM? > > _______________________________________________ > > 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 toraritte@REDACTED Wed Jul 24 18:19:20 2019 From: toraritte@REDACTED (=?UTF-8?Q?Guly=C3=A1s_Attila?=) Date: Wed, 24 Jul 2019 09:19:20 -0700 Subject: [erlang-questions] CRC32c in Erlang? In-Reply-To: <20180801162644.GA29634@jarowit.net> References: <20180801162644.GA29634@jarowit.net> Message-ID: CRC32 and CRC32c are not the same. [1] https://stackoverflow.com/questions/26429360/crc32-vs-crc32c [2] https://cloud.google.com/storage/docs/hashes-etags#_CRC32C Thomas Cioppettini did a lot of work collecting info in Cowboy issue #1340, and also did an Erlang and Elixir implementation in a Github gist. [3] https://github.com/ninenines/cowboy/issues/1340 [4] https://gist.github.com/tomciopp/2d174f3960b6386e86167268b1a9875d Found Erlang NIF bindings (seem to be forked from the same root): [5] https://github.com/zmstone/crc32cer [6] https://github.com/voluntas/crc32c On Wed, Aug 1, 2018 at 9:27 AM Stanislaw Klekot wrote: > On Wed, Aug 01, 2018 at 06:38:13PM +0300, pablo platt wrote: > > Is there CRC32c implementation in Erlang? > > It's required for SCTP checksum [1]. > > I only found NIF bindings but I prefer native Erlang implementation if > > exists. > > You mean, something like erlang:crc32/1 and erlang:crc32/2? > > -- > Stanislaw Klekot > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From askjuise@REDACTED Thu Jul 25 08:49:44 2019 From: askjuise@REDACTED (Alexander Petrovsky) Date: Thu, 25 Jul 2019 09:49:44 +0300 Subject: [erlang-questions] erlang 21.3 and erts-10.3 scheduler_4 got stuck In-Reply-To: References: Message-ID: Thanks! But it?s already fixed in https://github.com/erlang/otp/pull/2313 and released, so I guess the ticket could be closed ??, 25 ???? 2019 ?. ? 9:21, Kjell Winblad : > Hi Alexander, > > Thanks for reporting this. I have created an issue in our issue tracker so > we can continue the discussion about the issue there ( > https://bugs.erlang.org/browse/ERL-1011). In addition to the information > that you have provided, it would be useful to know what processor > architecture and operating system you used. > > Best regards, > Kjell Winblad > > On Thu, 27 Jun 2019 at 18:03, Alexander Petrovsky > wrote: > >> Additional, steps to reproduce from my colleague: >> >> # cat ./loop-rep.gdb >> br erl_process.h:2341 >> cont >> set p->run_queue.counter=p->run_queue.counter+1 >> quit >> >> # gdb --pid 32025 -x ./loop-rep.gdb >> >> where pid 32025 is scheduler thread pid >> >> ??, 27 ???. 2019 ?. ? 18:23, Alexander Petrovsky : >> >>> Hello! >>> >>> Dear maintainers, during perf test I stumble upon that application >>> freeze, don't respond to erlang pings, don't accept any new connections and >>> don't write any logs. Seems like one of the Erlang schedulers got stuck in >>> an endless loop. >>> >>> # top -H >>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >>> 15977 hbc 20 0 5103668 1.6g 5764 R 99.9 21.5 10:23.40 4_scheduler >>> >>> The trace from gdb attached. Is any additional information required? >>> >>> -- >>> ?????????? ????????? / Alexander Petrovsky, >>> >>> Skype: askjuise >>> Phone: +7 931 9877991 >>> >>> >> >> -- >> ?????????? ????????? / Alexander Petrovsky, >> >> Skype: askjuise >> Phone: +7 931 9877991 >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- ?????????? ????????? / Alexander Petrovsky, Skype: askjuise Phone: +7 931 9877991 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjellwinblad@REDACTED Thu Jul 25 08:21:35 2019 From: kjellwinblad@REDACTED (Kjell Winblad) Date: Thu, 25 Jul 2019 08:21:35 +0200 Subject: [erlang-questions] erlang 21.3 and erts-10.3 scheduler_4 got stuck In-Reply-To: References: Message-ID: Hi Alexander, Thanks for reporting this. I have created an issue in our issue tracker so we can continue the discussion about the issue there ( https://bugs.erlang.org/browse/ERL-1011). In addition to the information that you have provided, it would be useful to know what processor architecture and operating system you used. Best regards, Kjell Winblad On Thu, 27 Jun 2019 at 18:03, Alexander Petrovsky wrote: > Additional, steps to reproduce from my colleague: > > # cat ./loop-rep.gdb > br erl_process.h:2341 > cont > set p->run_queue.counter=p->run_queue.counter+1 > quit > > # gdb --pid 32025 -x ./loop-rep.gdb > > where pid 32025 is scheduler thread pid > > ??, 27 ???. 2019 ?. ? 18:23, Alexander Petrovsky : > >> Hello! >> >> Dear maintainers, during perf test I stumble upon that application >> freeze, don't respond to erlang pings, don't accept any new connections and >> don't write any logs. Seems like one of the Erlang schedulers got stuck in >> an endless loop. >> >> # top -H >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 15977 hbc 20 0 5103668 1.6g 5764 R 99.9 21.5 10:23.40 4_scheduler >> >> The trace from gdb attached. Is any additional information required? >> >> -- >> ?????????? ????????? / Alexander Petrovsky, >> >> Skype: askjuise >> Phone: +7 931 9877991 >> >> > > -- > ?????????? ????????? / Alexander Petrovsky, > > Skype: askjuise > Phone: +7 931 9877991 > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From publicityifl@REDACTED Fri Jul 26 12:58:50 2019 From: publicityifl@REDACTED (Jurriaan Hage) Date: Fri, 26 Jul 2019 03:58:50 -0700 Subject: [erlang-questions] Final call for draft papers for IFL 2019 (Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the final call for draft papers for IFL 2019. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ================================================================================ IFL 2019 31st Symposium on Implementation and Application of Functional Languages National University of Singapore September 25th-27th, 2019 http://2019.iflconference.org ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2019 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Keynote Speaker * Olivier Danvy, Yale-NUS College ### Submissions and peer-review Differently from previous editions of IFL, IFL 2019 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2019. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: June 15, 2019 Submission of draft papers: August 1, 2019 Regular papers notification: August 1, 2019 Regular draft papers notification: August 7, 2019 Deadline for early registration: August 15, 2019 Submission of pre-proceedings version: September 15, 2019 IFL Symposium: September 25-27, 2019 Submission of papers for post-proceedings: November 30, 2019 Notification of acceptance: January 31, 2020 Camera-ready version: February 29, 2020 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2019 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organization and Program committee Chairs: Jurrien Stutterheim (Standard Chartered Bank Singapore), Wei Ngan Chin (National University of Singapore) Program Committee: - Olaf Chitil, University of Kent - Clemens Grelck, University of Amsterdam - Daisuke Kimura, Toho University - Pieter Koopman, Radboud University - Tam?s Kozsik, E?tv?s Lor?nd University - Roman Leschinskiy, Facebook - Ben Lippmeier, The University of New South Wales - Marco T. Morazan, Seton Hall University - Sven-Bodo Scholz, Heriot-Watt University - Tom Schrijvers, Katholieke Universiteit Leuven - Alejandro Serrano, Utrecht University - Tony Sloane, Macquarie University - Simon Thompson, University of Kent - Marcos Viera, Universidad de la Rep?blica - Wei Ngan Chin, NUS - Jurri?n Stutterheim, Standard Chartered Bank ### Venue The 31st IFL is organized by the National University of Singapore. Singapore is located in the heart of South-East Asia, and the city itself is extremely well connected by trains and taxis. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2019 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.tansini95@REDACTED Mon Jul 29 10:28:34 2019 From: luca.tansini95@REDACTED (Luca Tansini) Date: Mon, 29 Jul 2019 10:28:34 +0200 Subject: [erlang-questions] Loading a copy of a module under a different name Message-ID: Hi all, I?m trying to load into the VM a copy of a module under a different name. The way I?m trying to do it is: - get the binary of the module with code:get_object_code(mod_name) - replace the module name inside the binary (otherwise the code loader won?t accept it) - reload it with code:load_binary(new_name, ??, RenamedBinary) here is some sample code showing the approach: https://pastebin.com/HpdUR0eU . This approach seems to work as long as the original module doesn?t contain any NIFs. In that case the module is still loaded (not always, I?ve found at least one exception, more below), but then gives runtime errors when NIFs are trying to be run. For instance this is what happens with the lists module: >> module_cp:load_module_copy(lists). {module,xists} >> xists:seq(1,10). [1,2,3,4,5,6,7,8,9,10] >> xists:reverse([1,2,3,4]). ** exception error: undefined function erlang:nif_error/1 in function xists:reverse/2 (xists.erl, line 95) For the erlang module instead, even the code loading fails: >> module_cp:load_module_copy(erlang). {error,badfile} =ERROR REPORT==== 26-Jul-2019::13:10:11 === Loading of failed: badfile =ERROR REPORT==== 26-Jul-2019::13:10:11 === beam/beam_load.c(2284): Error loading function xrlang:garbage_collect/2: op bif0 u x: no specific operation found I?m not very familiar with how NIFs work and are loaded, but is there a workaround for this? Maybe renaming only the module attribute is not enough. I?m on MacOS running Erlang/OTP 20 [erts-9.3]. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Mon Jul 29 14:34:05 2019 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 29 Jul 2019 15:34:05 +0300 Subject: [erlang-questions] Loading a copy of a module under a different name In-Reply-To: References: Message-ID: Hello Luca, I would not give you a straight answer about NIF but I know for sure it is not enough just to load Erlang module in cases of lists. You need to load native library as well. Typically NIF module has an association with library http://erlang.org/doc/tutorial/nif.html . Please note that lists is BIF module, you might not be able to re-bind it with other lib. I would suggest you to study meck implementation. It deals a lot with module re-loading https://github.com/eproxus/meck https://github.com/eproxus/meck/blob/master/src/meck_code.erl Best Regards, Dmitry > On 29 Jul 2019, at 11.28, Luca Tansini wrote: > > Hi all, > > I?m trying to load into the VM a copy of a module under a different name. > The way I?m trying to do it is: > > - get the binary of the module with code:get_object_code(mod_name) > - replace the module name inside the binary (otherwise the code loader won?t accept it) > - reload it with code:load_binary(new_name, ??, RenamedBinary) > > here is some sample code showing the approach: https://pastebin.com/HpdUR0eU . > > This approach seems to work as long as the original module doesn?t contain any NIFs. > In that case the module is still loaded (not always, I?ve found at least one exception, more below), but then gives runtime errors when NIFs are trying to be run. > > For instance this is what happens with the lists module: > > >> module_cp:load_module_copy(lists). > {module,xists} > >> xists:seq(1,10). > [1,2,3,4,5,6,7,8,9,10] > >> xists:reverse([1,2,3,4]). > ** exception error: undefined function erlang:nif_error/1 > in function xists:reverse/2 (xists.erl, line 95) > > For the erlang module instead, even the code loading fails: > > >> module_cp:load_module_copy(erlang). > {error,badfile} > > =ERROR REPORT==== 26-Jul-2019::13:10:11 === > Loading of failed: badfile > > =ERROR REPORT==== 26-Jul-2019::13:10:11 === > beam/beam_load.c(2284): Error loading function xrlang:garbage_collect/2: op bif0 u x: > no specific operation found > > > I?m not very familiar with how NIFs work and are loaded, but is there a workaround for this? > Maybe renaming only the module attribute is not enough. > I?m on MacOS running Erlang/OTP 20 [erts-9.3]. > > Thank you > > > _______________________________________________ > 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 Wed Jul 31 10:41:07 2019 From: peter.james.morgan@REDACTED (Peter Morgan) Date: Wed, 31 Jul 2019 09:41:07 +0100 Subject: [erlang-questions] gen_statem: next event internal and reply Message-ID: <76B140E6-CA4B-41B8-AE62-A2573944EB2C@gmail.com> Hi, I regularly use the following pattern in gen_statem: handle_event({call, From}, a, _, _) -> {keep_state_and_data, [{next_event, internal, work}, {reply, From, ok}]}; Where `work` is some side effect that needs to be done, and may be used by several other actions (hence wrapping it in a next_event) but the result is unimportant and doesn?t affect the reply. I use next_event rather than calling work() directly because it can be traced via sys. My assumption was that work would be processed before the reply was sent to the caller - i.e., that the actions were processed in order. Instead, it appears that the reply action is processed immediately? To work around this I have started using: handle_event({call, From}, a, _, _) -> {keep_state_and_data, [{next_event, internal, work}, {next_event, internal, {reply, From, ok}]}}; handle_event(internal, {reply, From, Result}, _, _) -> {keep_state_and_data, {reply, From, Result}}. The above ensures that work is completed before the reply is sent (result of the work is a side-effect here) - but is a rather ugly solution. Is the above intended behaviour? In some cases the `work` event causes state changes, or queueing subsequent other work (via next_event, internal) that was expected to be completed before the {reply, From, ok} was consumed. The above ordering of actions assumption caught me out recently, the early reply was causing a process to be killed before it had actually completed its work causing an unclean shutdown in a system. BTW the additional of log is very useful in failure analysis - what did this statem recently do? :) thanks! Thanks, Peter. Full example: -module(exaple_statem_reply). -behaviour(gen_statem). -export([a/0]). -export([b/0]). -export([callback_mode/0]). -export([handle_event/4]). -export([init/1]). -export([start/0]). -export([stop/1]). -include_lib("kernel/include/logger.hrl"). start() -> gen_statem:start({local, ?MODULE}, ?MODULE, [], [{debug, [log, trace]}]). a() -> gen_statem:call(?MODULE, ?FUNCTION_NAME). b() -> gen_statem:call(?MODULE, ?FUNCTION_NAME). stop(S) -> gen_statem:stop(S). init([]) -> {ok, limbo, #{}}. callback_mode() -> handle_event_function. handle_event({call, From}, a, _, _) -> {keep_state_and_data, [nei(work), {reply, From, ok}]}; handle_event({call, From}, b, _, _) -> {keep_state_and_data, [nei(work), nei({reply, From, ok})]}; handle_event(internal, work, _, _) -> keep_state_and_data; handle_event(internal, {reply, From, Result}, _, _) -> {keep_state_and_data, {reply, From, Result}}. nei(Event) -> {next_event, internal, Event}. 1> exaple_statem_reply:start(). *DBG* exaple_statem_reply enter in state limbo *DBG* exaple_statem_reply consume internal init_state in state limbo {ok,<0.161.0>} 2> exaple_statem_reply:a(). *DBG* exaple_statem_reply receive call a from <0.78.0> in state limbo *DBG* exaple_statem_reply receive internal work in state limbo *DBG* exaple_statem_reply send ok to <0.78.0> *DBG* exaple_statem_reply consume call a from <0.78.0> in state limbo ok *DBG* exaple_statem_reply consume internal work in state limbo 3> sys:get_status(exaple_statem_reply). {status,<0.161.0>, {module,gen_statem}, [[{'$ancestors',[<0.78.0>]}, {'$initial_call',{exaple_statem_reply,init,1}}], running,<0.161.0>, [{trace,true}, {log,[3, {{consume,{internal,work},limbo,limbo}, exaple_statem_reply,#Fun}, {{consume,{{call,{<0.78.0>, #Ref<0.2400559651.2919759873.28633>}}, a}, limbo,limbo}, exaple_statem_reply,#Fun}, {{out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, exaple_statem_reply,#Fun}, {{in,{internal,work},limbo}, exaple_statem_reply,#Fun}, {{in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, a}, limbo}, exaple_statem_reply,#Fun}, {{consume,{internal,init_state},limbo,limbo}, exaple_statem_reply,#Fun}, {{enter,limbo}, exaple_statem_reply,#Fun}]}], [{header,"Status for state machine exaple_statem_reply"}, {data,[{"Status",running}, {"Parent",<0.161.0>}, {"Logged Events", [{enter,limbo}, {consume,{internal,init_state},limbo,limbo}, {in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, a}, limbo}, {in,{internal,work},limbo}, {out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, {consume,{{call,{...}},a},limbo,limbo}, {consume,{internal,work},limbo,limbo}]}, {"Postponed",[]}]}, {data,[{"State",{limbo,#{}}}]}]]} 4> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Jul 31 11:16:07 2019 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 31 Jul 2019 11:16:07 +0200 Subject: [erlang-questions] gen_statem: next event internal and reply In-Reply-To: <76B140E6-CA4B-41B8-AE62-A2573944EB2C@gmail.com> References: <76B140E6-CA4B-41B8-AE62-A2573944EB2C@gmail.com> Message-ID: It is documented behaviour for next_event: This action does not set any transition_option() but instead stores the specified EventType and EventContent for insertion after all actions have been executed. My guess is that replies are sent as early as possible because this exposes concurrency to the maximum. I would also be very cautious around relying on orderings like these in a system since that is where concurrency bugs are hidden. On Wed, Jul 31, 2019 at 10:41 AM Peter Morgan wrote: > Hi, > > I regularly use the following pattern in gen_statem: > > handle_event({call, From}, a, _, _) -> > {keep_state_and_data, [{next_event, internal, work}, {reply, From, ok}]}; > > Where `work` is some side effect that needs to be done, and may be used by > several other actions (hence wrapping it in a next_event) but the result is > unimportant and doesn?t affect the reply. I use next_event rather than > calling work() directly because it can be traced via sys. > > My assumption was that work would be processed before the reply was sent > to the caller - i.e., that the actions were processed in order. > > Instead, it appears that the reply action is processed immediately? > > To work around this I have started using: > > handle_event({call, From}, a, _, _) -> > {keep_state_and_data, [{next_event, internal, work}, {next_event, > internal, {reply, From, ok}]}}; > handle_event(internal, {reply, From, Result}, _, _) -> > {keep_state_and_data, {reply, From, Result}}. > > The above ensures that work is completed before the reply is sent (result > of the work is a side-effect here) - but is a rather ugly solution. > > Is the above intended behaviour? In some cases the `work` event causes > state changes, or queueing subsequent other work (via next_event, internal) > that was expected to be completed before the {reply, From, ok} was consumed. > > The above ordering of actions assumption caught me out recently, the early > reply was causing a process to be killed before it had actually completed > its work causing an unclean shutdown in a system. > > BTW the additional of log is very useful in failure analysis - what did > this statem recently do? :) thanks! > > > Thanks, > Peter. > > Full example: > > -module(exaple_statem_reply). > > -behaviour(gen_statem). > -export([a/0]). > -export([b/0]). > -export([callback_mode/0]). > -export([handle_event/4]). > -export([init/1]). > -export([start/0]). > -export([stop/1]). > -include_lib("kernel/include/logger.hrl"). > > start() -> > gen_statem:start({local, ?MODULE}, > ?MODULE, > [], > [{debug, [log, trace]}]). > > a() -> > gen_statem:call(?MODULE, ?FUNCTION_NAME). > > b() -> > gen_statem:call(?MODULE, ?FUNCTION_NAME). > > stop(S) -> > gen_statem:stop(S). > > init([]) -> > {ok, limbo, #{}}. > > > callback_mode() -> > handle_event_function. > > handle_event({call, From}, a, _, _) -> > {keep_state_and_data, [nei(work), {reply, From, ok}]}; > > handle_event({call, From}, b, _, _) -> > {keep_state_and_data, [nei(work), nei({reply, From, ok})]}; > > handle_event(internal, work, _, _) -> > keep_state_and_data; > > handle_event(internal, {reply, From, Result}, _, _) -> > {keep_state_and_data, {reply, From, Result}}. > > nei(Event) -> > {next_event, internal, Event}. > > > 1> exaple_statem_reply:start(). > *DBG* exaple_statem_reply enter in state limbo > *DBG* exaple_statem_reply consume internal init_state in state limbo > {ok,<0.161.0>} > 2> exaple_statem_reply:a(). > *DBG* exaple_statem_reply receive call a from <0.78.0> in state limbo > *DBG* exaple_statem_reply receive internal work in state limbo > *DBG* exaple_statem_reply send ok to <0.78.0> > *DBG* exaple_statem_reply consume call a from <0.78.0> in state limbo > ok > *DBG* exaple_statem_reply consume internal work in state limbo > 3> sys:get_status(exaple_statem_reply). > {status,<0.161.0>, > {module,gen_statem}, > [[{'$ancestors',[<0.78.0>]}, > {'$initial_call',{exaple_statem_reply,init,1}}], > running,<0.161.0>, > [{trace,true}, > {log,[3, > {{consume,{internal,work},limbo,limbo}, > exaple_statem_reply,#Fun}, > {{consume,{{call,{<0.78.0>, > #Ref<0.2400559651.2919759873.28633>}}, > a}, > limbo,limbo}, > exaple_statem_reply,#Fun}, > {{out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > exaple_statem_reply,#Fun}, > {{in,{internal,work},limbo}, > exaple_statem_reply,#Fun}, > > {{in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > a}, > limbo}, > exaple_statem_reply,#Fun}, > {{consume,{internal,init_state},limbo,limbo}, > exaple_statem_reply,#Fun}, > {{enter,limbo}, > exaple_statem_reply,#Fun}]}], > [{header,"Status for state machine exaple_statem_reply"}, > {data,[{"Status",running}, > {"Parent",<0.161.0>}, > {"Logged Events", > [{enter,limbo}, > {consume,{internal,init_state},limbo,limbo}, > > {in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > a}, > limbo}, > {in,{internal,work},limbo}, > {out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > {consume,{{call,{...}},a},limbo,limbo}, > {consume,{internal,work},limbo,limbo}]}, > {"Postponed",[]}]}, > {data,[{"State",{limbo,#{}}}]}]]} > 4> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.james.morgan@REDACTED Wed Jul 31 11:33:04 2019 From: peter.james.morgan@REDACTED (Peter Morgan) Date: Wed, 31 Jul 2019 10:33:04 +0100 Subject: [erlang-questions] gen_statem: next event internal and reply In-Reply-To: References: <76B140E6-CA4B-41B8-AE62-A2573944EB2C@gmail.com> Message-ID: Thanks - In the back of my head I thought it was the case, but couldn't find that sentence. Log proved useful to find the cause. Regards, Peter. > On 31 Jul 2019, at 10:16, Jesper Louis Andersen wrote: > > It is documented behaviour for next_event: > > This action does not set any transition_option() but instead stores the specified EventType and EventContent for insertion after all actions have been executed. > > My guess is that replies are sent as early as possible because this exposes concurrency to the maximum. > > I would also be very cautious around relying on orderings like these in a system since that is where concurrency bugs are hidden. > > > On Wed, Jul 31, 2019 at 10:41 AM Peter Morgan > wrote: > Hi, > > I regularly use the following pattern in gen_statem: > > handle_event({call, From}, a, _, _) -> > {keep_state_and_data, [{next_event, internal, work}, {reply, From, ok}]}; > > Where `work` is some side effect that needs to be done, and may be used by several other actions (hence wrapping it in a next_event) but the result is unimportant and doesn?t affect the reply. I use next_event rather than calling work() directly because it can be traced via sys. > > My assumption was that work would be processed before the reply was sent to the caller - i.e., that the actions were processed in order. > > Instead, it appears that the reply action is processed immediately? > > To work around this I have started using: > > handle_event({call, From}, a, _, _) -> > {keep_state_and_data, [{next_event, internal, work}, {next_event, internal, {reply, From, ok}]}}; > handle_event(internal, {reply, From, Result}, _, _) -> > {keep_state_and_data, {reply, From, Result}}. > > The above ensures that work is completed before the reply is sent (result of the work is a side-effect here) - but is a rather ugly solution. > > Is the above intended behaviour? In some cases the `work` event causes state changes, or queueing subsequent other work (via next_event, internal) that was expected to be completed before the {reply, From, ok} was consumed. > > The above ordering of actions assumption caught me out recently, the early reply was causing a process to be killed before it had actually completed its work causing an unclean shutdown in a system. > > BTW the additional of log is very useful in failure analysis - what did this statem recently do? :) thanks! > > > Thanks, > Peter. > > Full example: > > -module(exaple_statem_reply). > > -behaviour(gen_statem). > -export([a/0]). > -export([b/0]). > -export([callback_mode/0]). > -export([handle_event/4]). > -export([init/1]). > -export([start/0]). > -export([stop/1]). > -include_lib("kernel/include/logger.hrl"). > > start() -> > gen_statem:start({local, ?MODULE}, > ?MODULE, > [], > [{debug, [log, trace]}]). > > a() -> > gen_statem:call(?MODULE, ?FUNCTION_NAME). > > b() -> > gen_statem:call(?MODULE, ?FUNCTION_NAME). > > stop(S) -> > gen_statem:stop(S). > > init([]) -> > {ok, limbo, #{}}. > > > callback_mode() -> > handle_event_function. > > handle_event({call, From}, a, _, _) -> > {keep_state_and_data, [nei(work), {reply, From, ok}]}; > > handle_event({call, From}, b, _, _) -> > {keep_state_and_data, [nei(work), nei({reply, From, ok})]}; > > handle_event(internal, work, _, _) -> > keep_state_and_data; > > handle_event(internal, {reply, From, Result}, _, _) -> > {keep_state_and_data, {reply, From, Result}}. > > nei(Event) -> > {next_event, internal, Event}. > > > 1> exaple_statem_reply:start(). > *DBG* exaple_statem_reply enter in state limbo > *DBG* exaple_statem_reply consume internal init_state in state limbo > {ok,<0.161.0>} > 2> exaple_statem_reply:a(). > *DBG* exaple_statem_reply receive call a from <0.78.0> in state limbo > *DBG* exaple_statem_reply receive internal work in state limbo > *DBG* exaple_statem_reply send ok to <0.78.0> > *DBG* exaple_statem_reply consume call a from <0.78.0> in state limbo > ok > *DBG* exaple_statem_reply consume internal work in state limbo > 3> sys:get_status(exaple_statem_reply). > {status,<0.161.0>, > {module,gen_statem}, > [[{'$ancestors',[<0.78.0>]}, > {'$initial_call',{exaple_statem_reply,init,1}}], > running,<0.161.0>, > [{trace,true}, > {log,[3, > {{consume,{internal,work},limbo,limbo}, > exaple_statem_reply,#Fun}, > {{consume,{{call,{<0.78.0>, > #Ref<0.2400559651.2919759873.28633>}}, > a}, > limbo,limbo}, > exaple_statem_reply,#Fun}, > {{out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > exaple_statem_reply,#Fun}, > {{in,{internal,work},limbo}, > exaple_statem_reply,#Fun}, > {{in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > a}, > limbo}, > exaple_statem_reply,#Fun}, > {{consume,{internal,init_state},limbo,limbo}, > exaple_statem_reply,#Fun}, > {{enter,limbo}, > exaple_statem_reply,#Fun}]}], > [{header,"Status for state machine exaple_statem_reply"}, > {data,[{"Status",running}, > {"Parent",<0.161.0>}, > {"Logged Events", > [{enter,limbo}, > {consume,{internal,init_state},limbo,limbo}, > {in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > a}, > limbo}, > {in,{internal,work},limbo}, > {out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > {consume,{{call,{...}},a},limbo,limbo}, > {consume,{internal,work},limbo,limbo}]}, > {"Postponed",[]}]}, > {data,[{"State",{limbo,#{}}}]}]]} > 4> > > > _______________________________________________ > 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 Wed Jul 31 12:00:14 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 31 Jul 2019 12:00:14 +0200 Subject: [erlang-questions] gen_statem: next event internal and reply In-Reply-To: <76B140E6-CA4B-41B8-AE62-A2573944EB2C@gmail.com> References: <76B140E6-CA4B-41B8-AE62-A2573944EB2C@gmail.com> Message-ID: <20190731100014.GA81508@erix.ericsson.se> On Wed, Jul 31, 2019 at 09:41:07AM +0100, Peter Morgan wrote: > Hi, > > I regularly use the following pattern in gen_statem: > > handle_event({call, From}, a, _, _) -> > {keep_state_and_data, [{next_event, internal, work}, {reply, From, ok}]}; > > Where `work` is some side effect that needs to be done, and may be used by several other actions (hence wrapping it in a next_event) but the result is unimportant and doesn?t affect the reply. I use next_event rather than calling work() directly because it can be traced via sys. > > My assumption was that work would be processed before the reply was sent to the caller - i.e., that the actions were processed in order. > > Instead, it appears that the reply action is processed immediately? > > To work around this I have started using: > > handle_event({call, From}, a, _, _) -> > {keep_state_and_data, [{next_event, internal, work}, {next_event, internal, {reply, From, ok}]}}; > handle_event(internal, {reply, From, Result}, _, _) -> > {keep_state_and_data, {reply, From, Result}}. > > The above ensures that work is completed before the reply is sent (result of the work is a side-effect here) - but is a rather ugly solution. > > Is the above intended behaviour? In some cases the `work` event causes state changes, or queueing subsequent other work (via next_event, internal) that was expected to be completed before the {reply, From, ok} was consumed. This is by design, intentional and documented (somewhat convoluted) in: http://erlang.org/doc/man/gen_statem.html#type-transition_option http://erlang.org/doc/man/gen_statem.html#type-action http://erlang.org/doc/man/gen_statem.html#type-enter_action http://erlang.org/doc/man/gen_statem.html#type-reply_action The {next_event, Type, Content} transition action inserts an event to be handled during later event handler invocations. {reply, From, Reply} immediately sends a reply during the state transition hence before the next event handler invocation. Most of the transition actions set options for the state transition, and how these options affect the state transition is described in the first link above: http://erlang.org/doc/man/gen_statem.html#type-transition_option The actions are processed in order, but that is far from the whole truth. The only transition action that immediately does something for which the order matters is {reply,,}, the others just set transition options. Order also matters between {next_event,,} actions since their inserted events will be handled in order. Your assumption that a {next_event,,,} action should be processed before a {reply,,} action would also be very confusing: if handling of the inserted event also would use {reply,,}; what would the order of the replies be? Especially if both event handler invocations would insert multiple events and generate multiple replies... Then add state enter calls to that mix. I think your solution is logical and only moderatly ugly. Would it be possible to instead have the handler of (internal, work) decide on sending the reply based on some other state data instead of having to generate two internal events? Best Regards / Raimo Niskanen > > The above ordering of actions assumption caught me out recently, the early reply was causing a process to be killed before it had actually completed its work causing an unclean shutdown in a system. > > BTW the additional of log is very useful in failure analysis - what did this statem recently do? :) thanks! > > > Thanks, > Peter. > > Full example: > > -module(exaple_statem_reply). > > -behaviour(gen_statem). > -export([a/0]). > -export([b/0]). > -export([callback_mode/0]). > -export([handle_event/4]). > -export([init/1]). > -export([start/0]). > -export([stop/1]). > -include_lib("kernel/include/logger.hrl"). > > start() -> > gen_statem:start({local, ?MODULE}, > ?MODULE, > [], > [{debug, [log, trace]}]). > > a() -> > gen_statem:call(?MODULE, ?FUNCTION_NAME). > > b() -> > gen_statem:call(?MODULE, ?FUNCTION_NAME). > > stop(S) -> > gen_statem:stop(S). > > init([]) -> > {ok, limbo, #{}}. > > > callback_mode() -> > handle_event_function. > > handle_event({call, From}, a, _, _) -> > {keep_state_and_data, [nei(work), {reply, From, ok}]}; > > handle_event({call, From}, b, _, _) -> > {keep_state_and_data, [nei(work), nei({reply, From, ok})]}; > > handle_event(internal, work, _, _) -> > keep_state_and_data; > > handle_event(internal, {reply, From, Result}, _, _) -> > {keep_state_and_data, {reply, From, Result}}. > > nei(Event) -> > {next_event, internal, Event}. > > > 1> exaple_statem_reply:start(). > *DBG* exaple_statem_reply enter in state limbo > *DBG* exaple_statem_reply consume internal init_state in state limbo > {ok,<0.161.0>} > 2> exaple_statem_reply:a(). > *DBG* exaple_statem_reply receive call a from <0.78.0> in state limbo > *DBG* exaple_statem_reply receive internal work in state limbo > *DBG* exaple_statem_reply send ok to <0.78.0> > *DBG* exaple_statem_reply consume call a from <0.78.0> in state limbo > ok > *DBG* exaple_statem_reply consume internal work in state limbo > 3> sys:get_status(exaple_statem_reply). > {status,<0.161.0>, > {module,gen_statem}, > [[{'$ancestors',[<0.78.0>]}, > {'$initial_call',{exaple_statem_reply,init,1}}], > running,<0.161.0>, > [{trace,true}, > {log,[3, > {{consume,{internal,work},limbo,limbo}, > exaple_statem_reply,#Fun}, > {{consume,{{call,{<0.78.0>, > #Ref<0.2400559651.2919759873.28633>}}, > a}, > limbo,limbo}, > exaple_statem_reply,#Fun}, > {{out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > exaple_statem_reply,#Fun}, > {{in,{internal,work},limbo}, > exaple_statem_reply,#Fun}, > {{in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > a}, > limbo}, > exaple_statem_reply,#Fun}, > {{consume,{internal,init_state},limbo,limbo}, > exaple_statem_reply,#Fun}, > {{enter,limbo}, > exaple_statem_reply,#Fun}]}], > [{header,"Status for state machine exaple_statem_reply"}, > {data,[{"Status",running}, > {"Parent",<0.161.0>}, > {"Logged Events", > [{enter,limbo}, > {consume,{internal,init_state},limbo,limbo}, > {in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > a}, > limbo}, > {in,{internal,work},limbo}, > {out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > {consume,{{call,{...}},a},limbo,limbo}, > {consume,{internal,work},limbo,limbo}]}, > {"Postponed",[]}]}, > {data,[{"State",{limbo,#{}}}]}]]} > 4> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-questions@REDACTED Wed Jul 31 14:36:21 2019 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 31 Jul 2019 14:36:21 +0200 Subject: [erlang-questions] gen_statem: next event internal and reply In-Reply-To: <20190731100014.GA81508@erix.ericsson.se> References: <76B140E6-CA4B-41B8-AE62-A2573944EB2C@gmail.com> <20190731100014.GA81508@erix.ericsson.se> Message-ID: <20190731123621.GA14338@erix.ericsson.se> I have checked in a branch in the daily builds that clarifies the documentation for transition_option() to be more explicit about when replies are sent, and some other stuff. / Raimo On Wed, Jul 31, 2019 at 12:00:14PM +0200, Raimo Niskanen wrote: > On Wed, Jul 31, 2019 at 09:41:07AM +0100, Peter Morgan wrote: > > Hi, > > > > I regularly use the following pattern in gen_statem: > > > > handle_event({call, From}, a, _, _) -> > > {keep_state_and_data, [{next_event, internal, work}, {reply, From, ok}]}; > > > > Where `work` is some side effect that needs to be done, and may be used by several other actions (hence wrapping it in a next_event) but the result is unimportant and doesn?t affect the reply. I use next_event rather than calling work() directly because it can be traced via sys. > > > > My assumption was that work would be processed before the reply was sent to the caller - i.e., that the actions were processed in order. > > > > Instead, it appears that the reply action is processed immediately? > > > > To work around this I have started using: > > > > handle_event({call, From}, a, _, _) -> > > {keep_state_and_data, [{next_event, internal, work}, {next_event, internal, {reply, From, ok}]}}; > > handle_event(internal, {reply, From, Result}, _, _) -> > > {keep_state_and_data, {reply, From, Result}}. > > > > The above ensures that work is completed before the reply is sent (result of the work is a side-effect here) - but is a rather ugly solution. > > > > Is the above intended behaviour? In some cases the `work` event causes state changes, or queueing subsequent other work (via next_event, internal) that was expected to be completed before the {reply, From, ok} was consumed. > > This is by design, intentional and documented (somewhat convoluted) in: > http://erlang.org/doc/man/gen_statem.html#type-transition_option > http://erlang.org/doc/man/gen_statem.html#type-action > http://erlang.org/doc/man/gen_statem.html#type-enter_action > http://erlang.org/doc/man/gen_statem.html#type-reply_action > > The {next_event, Type, Content} transition action inserts an event > to be handled during later event handler invocations. > > {reply, From, Reply} immediately sends a reply during the state transition > hence before the next event handler invocation. > > Most of the transition actions set options for the state transition, and > how these options affect the state transition is described in the first > link above: > http://erlang.org/doc/man/gen_statem.html#type-transition_option > > The actions are processed in order, but that is far from the whole truth. > The only transition action that immediately does something for which the > order matters is {reply,,}, the others just set transition options. > Order also matters between {next_event,,} actions since their inserted > events will be handled in order. > > Your assumption that a {next_event,,,} action should be processed before a > {reply,,} action would also be very confusing: if handling of the > inserted event also would use {reply,,}; what would the order of the > replies be? Especially if both event handler invocations would insert > multiple events and generate multiple replies... > Then add state enter calls to that mix. > > I think your solution is logical and only moderatly ugly. Would it be > possible to instead have the handler of (internal, work) decide on sending > the reply based on some other state data instead of having to generate > two internal events? > > Best Regards > / Raimo Niskanen > > > > > > The above ordering of actions assumption caught me out recently, the early reply was causing a process to be killed before it had actually completed its work causing an unclean shutdown in a system. > > > > BTW the additional of log is very useful in failure analysis - what did this statem recently do? :) thanks! > > > > > > Thanks, > > Peter. > > > > Full example: > > > > -module(exaple_statem_reply). > > > > -behaviour(gen_statem). > > -export([a/0]). > > -export([b/0]). > > -export([callback_mode/0]). > > -export([handle_event/4]). > > -export([init/1]). > > -export([start/0]). > > -export([stop/1]). > > -include_lib("kernel/include/logger.hrl"). > > > > start() -> > > gen_statem:start({local, ?MODULE}, > > ?MODULE, > > [], > > [{debug, [log, trace]}]). > > > > a() -> > > gen_statem:call(?MODULE, ?FUNCTION_NAME). > > > > b() -> > > gen_statem:call(?MODULE, ?FUNCTION_NAME). > > > > stop(S) -> > > gen_statem:stop(S). > > > > init([]) -> > > {ok, limbo, #{}}. > > > > > > callback_mode() -> > > handle_event_function. > > > > handle_event({call, From}, a, _, _) -> > > {keep_state_and_data, [nei(work), {reply, From, ok}]}; > > > > handle_event({call, From}, b, _, _) -> > > {keep_state_and_data, [nei(work), nei({reply, From, ok})]}; > > > > handle_event(internal, work, _, _) -> > > keep_state_and_data; > > > > handle_event(internal, {reply, From, Result}, _, _) -> > > {keep_state_and_data, {reply, From, Result}}. > > > > nei(Event) -> > > {next_event, internal, Event}. > > > > > > 1> exaple_statem_reply:start(). > > *DBG* exaple_statem_reply enter in state limbo > > *DBG* exaple_statem_reply consume internal init_state in state limbo > > {ok,<0.161.0>} > > 2> exaple_statem_reply:a(). > > *DBG* exaple_statem_reply receive call a from <0.78.0> in state limbo > > *DBG* exaple_statem_reply receive internal work in state limbo > > *DBG* exaple_statem_reply send ok to <0.78.0> > > *DBG* exaple_statem_reply consume call a from <0.78.0> in state limbo > > ok > > *DBG* exaple_statem_reply consume internal work in state limbo > > 3> sys:get_status(exaple_statem_reply). > > {status,<0.161.0>, > > {module,gen_statem}, > > [[{'$ancestors',[<0.78.0>]}, > > {'$initial_call',{exaple_statem_reply,init,1}}], > > running,<0.161.0>, > > [{trace,true}, > > {log,[3, > > {{consume,{internal,work},limbo,limbo}, > > exaple_statem_reply,#Fun}, > > {{consume,{{call,{<0.78.0>, > > #Ref<0.2400559651.2919759873.28633>}}, > > a}, > > limbo,limbo}, > > exaple_statem_reply,#Fun}, > > {{out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > > exaple_statem_reply,#Fun}, > > {{in,{internal,work},limbo}, > > exaple_statem_reply,#Fun}, > > {{in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > > a}, > > limbo}, > > exaple_statem_reply,#Fun}, > > {{consume,{internal,init_state},limbo,limbo}, > > exaple_statem_reply,#Fun}, > > {{enter,limbo}, > > exaple_statem_reply,#Fun}]}], > > [{header,"Status for state machine exaple_statem_reply"}, > > {data,[{"Status",running}, > > {"Parent",<0.161.0>}, > > {"Logged Events", > > [{enter,limbo}, > > {consume,{internal,init_state},limbo,limbo}, > > {in,{{call,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > > a}, > > limbo}, > > {in,{internal,work},limbo}, > > {out,ok,{<0.78.0>,#Ref<0.2400559651.2919759873.28633>}}, > > {consume,{{call,{...}},a},limbo,limbo}, > > {consume,{internal,work},limbo,limbo}]}, > > {"Postponed",[]}]}, > > {data,[{"State",{limbo,#{}}}]}]]} > > 4> > > > > > > > _______________________________________________ > > 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