You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
localgtimer=require("gears.timer")
localnaughty=require("naughty")
localfunctionnotify(val) --- A simple shim around naughty to support the V5 or V4 apisifnaughty.notificationthenreturnnaughty.notification({ message=tostring(val) }) endreturnnaughty.notify({ text=tostring(val) })
endgtimer.new({
call_now=true, -- This introduces the broken behaviorautostart=true, -- Call :start() for me, required to show the correct behavior (through :emit_signal('timeout'))timeout=1, -- A short timeout to easily reproduce the issuesingle_shot=true, -- Only run this once, not needed, but simplifies cleanup after the demonstrationcallback=notify, -- Call notify on timeout, just notifies the first value
})
Actual result:
A notification is received nil from the call_now
A second notification is received 1 second later (due to timeout) table: <address> (the timer)
Expected result:
call_now passes the timer to the callback like :emit_signal('timeout') does, resulting in two identical notifications both displaying the timer's memory address.
Possible implementation:
The code currently looks like this:
ifargs.callbackthenifargs.call_nowthenargs.callback()
endret:connect_signal("timeout", args.callback)
endifargs.single_shotthenret:connect_signal("timeout", function() ret:stop() end)
end
It would be simpler and avoid this sort of issue in the future to do this:
ifargs.callbackthenret:connect_signal("timeout", args.callback)
endifargs.call_nowthenret:emit_signal("timeout")
endifargs.single_shotthenret:connect_signal("timeout", function() ret:stop() end)
end
This makes call_now call :emit_signal("timeout") which would pass the timer to args.callback (the only connected listener)
This would also be more future-proof to potential changes to :emit_signal(), as it would make the actual timer behavior (in :start()) and the .call_now behavior match exactly.
alternatively, keep the current code and just call args.callback(ret)
The text was updated successfully, but these errors were encountered:
Output of
awesome --version
:Tested in both 4.3 and HEAD
How to reproduce the issue:
Actual result:
A notification is received
nil
from the call_nowA second notification is received 1 second later (due to timeout)
table: <address>
(the timer)Expected result:
call_now passes the timer to the callback like
:emit_signal('timeout')
does, resulting in two identical notifications both displaying the timer's memory address.Possible implementation:
The code currently looks like this:
It would be simpler and avoid this sort of issue in the future to do this:
This makes
call_now
call:emit_signal("timeout")
which would pass the timer toargs.callback
(the only connected listener)This would also be more future-proof to potential changes to
:emit_signal()
, as it would make the actual timer behavior (in:start()
) and the.call_now
behavior match exactly.alternatively, keep the current code and just call
args.callback(ret)
The text was updated successfully, but these errors were encountered: