* luaa.c: Remove useless stack operation
We get package.loaded and immediately throw away the result. That's
pointless, so remove this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Refactor modification of package.path
Awesome adds various entries to package.path during startup. This commit
moves that into a helper function. No functional changes intended. The
only change I did to the code was changing a call to lua_type(L, 2) into
lua_type(L, -1);.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Modify package.cpath just like package.path
This adds, for example, paths specified via the --search argument also
to package.cpath.
Fixes: https://github.com/awesomeWM/awesome/issues/1248
Signed-off-by: Uli Schlachter <psychon@znc.in>
In contrast do dpkg, rpm tracks which package created a directory. No
idea what happens if you remove the package which owns the directory,
but another package still owns files in there. Anyway, this behaviour
produced the following problem:
file /etc/xdg from install of awesome-[snip].x86_64 conflicts with
file from package filesystem-3.2-37.fc24.x86_64
Fix this by telling CPack to exclude these directories from the file
list.
Fixes: https://github.com/awesomeWM/awesome/issues/1234
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allows for `DO_COVERAGE=1 make check` with local tests (where
`CI=true` is not given).
It uses the new environment variables to configure the default theme,
instead of creating a temporary config/theme.
- checkout previous commit, so the coverage upload uses the current
code
- do not run coverage reports when testing previous commits
- improve failure message: display subject/author/name for each commit
The build files do not get updated on source changes currently anyway
(as a dependency of these targets), and this seems to be a leftover from
when `lua.in` files were used / pre-processing was required?!
- Execute the tests without compiling, and don't mess with the source
files when coverage is enabled.
This ensures that the coverage report lines are correct.
This disables the doc tests, as their results would be unused.
Hack: it still expands macros on util.lua, because of
`util.get_themes_dir()` and `util.get_awesome_icon_dir()`, which might
be moved later. Ref:
https://github.com/awesomeWM/awesome/pull/1239#discussion_r93828178.
- ensure that BUILD_APIDOC and DO_COVERAGE are not used together
- awesomeConfig.cmake: add DO_COVERAGE as an option
- Travis: only install codecov with DO_COVERAGE=codecov
- Travis: do not use set -v; use set -x with DO_COVERAGE
- do not use trailing slashes with dirs in tests/examples/CMakeLists.txt / .luacov
- Use latest luacov (0.12.0-1) again
This reverts parts of 4cc6a815.
I think it is better to fix any failure that 4cc6a815 tried to work around.
- Travis: simplify/fix require('luacov') for functionaltests
- tests/examples/CMakeLists.txt: resolve ../.. in SOURCE_DIR
- tests/examples/CMakeLists.txt: add DO_COVERAGE to env
- Cleanup/simplify .luacov: work with SOURCE_DIRECTORY alone
- tests/run.sh: pass through / set SOURCE_DIRECTORY when running awesome
- tests/run.sh: resolve source_dir
- use DO_COVERAGE from env only
These warnings might help catching some problems in the future. These
could be asserts, but printing a warning is a lot nicer than dying.
Signed-off-by: Uli Schlachter <psychon@znc.in>
X11 does not allow to resize a window to size 0x0. Also, there are some
possibilities of integer overflows in our case. We tried to handle this
already, but there was a loop-hole: If the too-small-value is only
produced after applying size hints, then this was not caught.
Fix this by applying size hints before checking if the resulting size is
valid. However, this means some check needs to be duplicated to handle
the possibility of integer underflows while applying size hints.
Helps-with: https://github.com/awesomeWM/awesome/issues/1340
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a new argument to the test client spawning function that will
make the test client window set a resize increment property.
The API here is starting to a bit ugly, but since this is not any user
facing API, that should not be a problem.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Otherwise commented lines look like ---- My comment
instead of -- -- My comment. This wasn't a problem before the
intentation fix commit, but it is now.
Commit a944636c02 "bashified" tests/run.sh for some reason.
Afterwards, commit 4abd820051 fixed some of the fall-out.
However, there is still a problem left.
We have "set -e" in this script. Thus, whenever some command exits with
status 0, the script abort. When the variable errors is zero/unset, the
command "((errors++))" has exit status zero. Thus, this instruction
caused the shell script to abort. This was not intended.
Fix this by using "((++errors))" instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, the test runner used a timer which fired every 0.1 seconds
to "do its thing". Many of these waits seem unnecessary.
This commit makes the test runner wait 0 seconds for the first call of a
step function. Only following calls will have a timeout of 0.1 seconds
applied.
A full run of the test suite (tests/run.sh without further arguments)
took about 100 seconds before this change. After this change, we are
down to 60 seconds. This is almost factor two faster! (Well, five thirds
is the exact number, so factor 1.66)
(The numbers are best out of three runs. The "before" number is rounded
down while the "after" number is rounded up.)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function should only be necessary for the test suite. It makes sure
that the X11 server received and handled all previous requests that
awesome sent. This will be needed, for example, in tests that use
root.fake_input().
After a call to awesome.sync(), we are sure that "faking input" has been
done and the next main loop iteration will handle the input event.
Without the sync, it could happen that the X11 server did not yet fake
the input in the next iteration.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When menubar.refresh() is called, it tries to update the menubar widget.
The call chain looks like this: menulist_update -> common.list_update ->
get_current_page. get_current_page then tries to query information about
the size of the menubar.
Since there is not much point in this, just skip the whole callback in
this case.
Side note: What is the point of menubar.get()? It seems quite useless to
me.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Renato Botelho
Uli Schlachter
Daniel Hahler
Emmanuel Lepage Vallee
Daniel Hahler
Uli Schlachter
rob
Ingo Bürk