I'm learning Erlang and I've written a simple module to test "spawn" function:
-module(concurrent).
-export([go/0, loop/0]).
go() ->
Pid2 = spawn(echo, loop, []).
loop() -> 2.
but when I run concurrent:go(). I get this error message:
=ERROR REPORT==== 10-Feb-2023::14:41:34.586000 === Error in process
<0.84.0> with exit value: {undef,[{echo,loop,[],[]}]}
I don't understand what I'm doing wrong.
You try to spawn a process running function loop from module echo. But you export function loop from module named concurrent and not echo.
Related
Running Awesome on Debian (11) testing
awesome v4.3 (Too long)
• Compiled against Lua 5.3.3 (running with Lua 5.3)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.6
• LGI version: 0.9.2
I'm trying to signal to Awesome when systemd triggers suspend. After fiddling with D-Bus directly for awhile and getting nowhere, I wrote a couple of functions that somewhat duplicate the functionality of signals.
I tested it by running the following command in a shell, inside of my Awesome session:
$ awesome-client 'require("lib.syskit").signal("awesome-client", "Hello world!")'
This runs just fine. A notification posts to the desktop "Hello world!" as expected. I added the path to my lib.syskit code to the $LUA_PATH in my ~/.xsessionrc. Given the error described below, I doubt this is an issue.
Now for the more difficult part. I put the following in a script located at /lib/systemd/system-sleep/pre-suspend.sh
#!/bin/bash
if [ "${1}" == "pre" ]; then
ERR=$(export DISPLAY=":0"; sudo -u naddan awesome-client 'require("lib.syskit").signal("awesome-client", "pre-suspend")' 2>&1)
echo "suspending at `date`, ${ERR}" > /tmp/systemd_suspend_test
elif [ "${1}" == "post" ]; then
ERR=$(export DISPLAY=":0"; sudo -u naddan awesome-client 'require("lib.syskit").signal("awesome-client", "post-suspend")' 2>&1)
echo "resuming at `date`, ${ERR}" >> /tmp/systemd_suspend_test
fi
Here's the output written to /tmp/systemd_suspend_test
suspending at Thu 22 Jul 2021 10:58:01 PM MDT, Failed to open connection to "session" message bus: /usr/bin/dbus-launch terminated abnormally without any error message
E: dbus-send failed.
resuming at Thu 22 Jul 2021 10:58:05 PM MDT, Failed to open connection to "session" message bus: /usr/bin/dbus-launch terminated abnormally without any error message
E: dbus-send failed.
Given that I'm already telling it the $DISPLAY that Awesome is running under (this is a laptop), and that I'm running awesome-client as my user, not root, what else am I missing that's keeping this from working?
Is there a better way that I could achieve telling Awesome when the system suspends?
awesome-client is a shell script. It is a thin wrapper around dbus-send. Thus, since you write "After fiddling with D-Bus directly for awhile and getting nowhere", I guess the same reasoning applies.
Given that I'm already telling it the $DISPLAY that Awesome is running under (this is a laptop), and that I'm running awesome-client as my user, not root, what else am I missing that's keeping this from working?
You are missing the address of the dbus session bus. For me, it is:
$ env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
Is there a better way that I could achieve telling Awesome when the system suspends?
Instead of sending a message directly to awesome via some script, you could use the existing mechanism for this: Dbus signals. These are broadcasts that interested parties can listen to.
Google suggests that there is already a PrepareForSleep signal:
https://serverfault.com/questions/573379/system-suspend-dbus-upower-signals-are-not-seen
Based on this, Google then gave me the following AwesomeWM lua code that listens for logind's PrepareForSleep signal (written by yours truely - thanks Google for finding that!):
https://github.com/awesomeWM/awesome/issues/344#issuecomment-328354719
local lgi = require("lgi")
local Gio = lgi.require("Gio")
local function listen_to_signals()
local bus = lgi.Gio.bus_get_sync(Gio.BusType.SYSTEM)
local sender = "org.freedesktop.login1"
local interface = "org.freedesktop.login1.Manager"
local object = "/org/freedesktop/login1"
local member = "PrepareForSleep"
bus:signal_subscribe(sender, interface, member, object, nil, Gio.DBusSignalFlags.NONE,
function(bus, sender, object, interface, signal, params)
-- "signals are sent right before (with the argument True) and
-- after (with the argument False) the system goes down for
-- reboot/poweroff, resp. suspend/hibernate."
if not params[1] then
-- This code is run before suspend. You can replace the following with something else.
require("gears.timer").start_new(2, function()
mytextclock:force_update()
end)
end
end)
end
listen_to_signals()
I have a parallel map in Elixir using Task.async. I am using it with System.cmd to parallel ruby rbenv install a list of ruby version strings.
The script runs and installs the ruby versions. However it does not exit the Task once the ruby versions have been installed and errors with a Task.await timeout error.
I have tried passing a simple IO.puts function into the parallel map and behaves correctly, exiting when the work is done and not raising an error. What am I missing in my System.cmd to ensure that each process is ended once each rbenv process is finished.
# My parallel map
def pmap(collection, func) do
collection
|> Enum.map(&(Task.async(fn -> func.(&1) end)))
|> Enum.map(&Task.await/1)
end
# System.cmd is being passed into the map like this
def parallel_install(ruby_versions) do
pmap(ruby_versions, &(System.cmd("rbenv", ["install", &1])))
end
Output with Error:
rbenv: /Users/lewis.jones/.rbenv/versions/2.4.4 already exists
rbenv: /Users/lewis.jones/.rbenv/versions/2.5.1 already exists
rbenv: /Users/lewis.jones/.rbenv/versions/2.1.10 already exists
rbenv: /Users/lewis.jones/.rbenv/versions/2.3.7 already exists
rbenv: /Users/lewis.jones/.rbenv/versions/2.2.10 already exists
** (exit) exited in: Task.await(%Task{owner: #PID<0.73.0>, pid: #PID<0.82.0>,
ref: #Reference<0.100168651.1374158856.61975>}, 5000)
** (EXIT) time out
(elixir) lib/task.ex:491: Task.await/2
(elixir) lib/enum.ex:1270: Enum."-map/2-lists^map/1-0-"/2
(elixir) lib/code.ex:376: Code.require_file/2
Task.await defaults to a timeout of 5 seconds. I'm guessing rbenv install takes longer than that. You can either increase the timeout or set it to infinity.
300 seconds:
|> Enum.map(&Task.await(&1, 300_000))
or infinity:
|> Enum.map(&Task.await(&1, :infinity))
UPDATE: Confirmed as a bug. For more detail, see the link and details provided by #ViralBShah below.
Julia throws a strange error when I add and remove processes (addprocs and rmprocs), but only if I don't do any parallel processing in between. Consider the following example code:
#Set parameters
numCore = 4;
#Add workers
print("Adding workers... ");
addprocs(numCore - 1);
println(string(string(numCore-1), " workers added."));
#Detect number of cores
println(string("Number of processes detected = ", string(nprocs())));
# Do some stuff (COMMENTED OUT)
# XLst = {rand(10, 1) for i in 1:8};
# XMean = pmap(mean, XLst);
#Remove the additional workers
print("Removing workers... ");
rmprocs(workers());
println("Done.");
println("Subroutine complete.");
Note that I've commented out the only code that actually does any parallel processing (the call to pmap). If I run this code on my machine (Julia 0.2.1, Ubuntu 14.04), I get the following output in the console:
Adding workers... 3 workers added.
Number of processes detected = 4
Removing workers... Done.
Subroutine complete.
fatal error on
In [86]: fatal error on 88: ERROR: 87: ERROR: connect: connection refused (ECONNREFUSED)
in yield at multi.jl:1540
connect: connection refused (ECONNREFUSED) in wait at task.jl:117
in wait_connected at stream.jl:263
in connect at stream.jl:878
in Worker at multi.jl:108
in anonymous at task.jl:876
in yield at multi.jl:1540
in wait at task.jl:117
in wait_connected at stream.jl:263
in connect at stream.jl:878
in Worker at multi.jl:108
in anonymous at task.jl:876
The first four lines are printed by my program, and seem to indicate that it runs to completion. But then I get a fatal error. Any ideas?
The most interesting thing about this error is if I uncomment the code with the call to pmap (ie if I actually do some parallel processing), the fatal error goes away.
This issue is being tracked at https://github.com/JuliaLang/julia/issues/7646 and I reproduce the answer by Amit Murthy:
pid 1 does an addprocs(3)
addprocs returns after it has established connections with all 3 new workers.
However, at this time the the connections between workers may not have been setup, i.e. from pids 3 -> 2, 4 -> 2 and 4 -> 3.
Now pid 1 calls rmprocs(workers()) , i.e., pids 2, 3 and 4.
As pid 2 exits, the connection attempt in 4 to 2, results in an error.
Since we have redirected the output of pid 4, to the stdout of pid 1, we see the same error printed.
The system is still in a consistent state, though the printing of said error messages may suggest something amiss.
I have a smoke test that I run against my servers before making them live. At the moment it runs in serial form and takes around 60s per server. I can run these in parallel and I've done it with Thread.new which is great as it runs them a lot faster but I lose track of whether the test actually passed or not.
I'm trying to improve this by using Process.spawn to manage my processes.
pids = []
uris.each do |uri|
command = get_http_tests_command("Smoke")
update_http_tests_config( uri )
pid = Process.spawn( system( command ) )
pids.push pid
Process.detach pid
end
# make sure all pids return a passing status code
# results = Process.waitall
I'd like to kick off all my tests but then afterwards make sure that all the tests return a passing status code.
I tried using Process.waitall but I believe that to be incorrect and used for forks, not spawns.
After all the process have completed I'd like to return the status of true if they all pas or false if any one of them fails.
Documentation here
Try:
statuses = pids.map { |pid| Process.wait(pid, 0); $? }
This waits for each of the process ids to finish, and checks for the result status set in $? for each process
When I run my broadcast server, I got the error report:
=ERROR REPORT==== 14-Feb-2012::16:22:29 ===
Error in process <0.757.0> with exit value: {badarg,[{mymodule1,func1,1}]}
=ERROR REPORT==== 14-Feb-2012::16:22:30 ===
Error in process <0.751.0> with exit value: {function_clause,[{mymodule2, func2,[{#Port<0.2
When debugging an error or crash, it is often useful to see what input and output a certain function gets. The debug utility redbug in the eper repo makes it rather easy
Examples:
%%% Trace a function:
1>redbug:start("lists:sort")
2>lists:sort([3,1,2]).
21:41:00 <{erlang,apply,2}> {lists,sort,[[3,1,2]]}
%%% Trace a module and also get the return value
3>redbug:start("string->return")
4>string:to_upper("foo").
21:41:10 <{erlang,apply,2}> {string,to_upper,["foo"]}
21:41:10 <{erlang,apply,2}> {string,'-to_upper/1-lc$^0/1-0-',["foo"]}
...
21:41:10 <{erlang,apply,2}> {string,to_upper,1} -> "FOO"
So in your code I would for example see what input mymodule1:func1 gets:
1>redbug:start("mymodule1:func1").
2> %% redo the call that caused the crash
function_clause means simply that there is no definition for function mymodule2:func2 which matches the arguments. E.g.
func2({X, Y}) -> ... %% only accepts a tuple of size 2
func2([1, 2, 3])%% called with a list instead; will fail with function_clause
badarg with your function can be thrown because of wrong arguments to a built-in function: http://erlang.2086793.n4.nabble.com/function-badarg-td3645808.html
See a list of other failure reasons here: http://learnyousomeerlang.com/errors-and-exceptions
For debugging: 1) the latest Erlang release (R15B) should include line numbers in exception messages; 2) you can use the debugger which comes with Erlang.