arm64 builds on Travis are not yet fully mature and this
causes a high failure rate that is not caused by our code.
Continue building and deploying arm64 to the edge channel,
but don't consider the result for the success of the whole
build job.
Alleviates #587
Using gnome-3-34 gives us a newer stack in general
and also provides us with a sdk build-snap, so we don't need
to specify as many build-packages and stage-packages.
This makes the snap slimmer and delegates the responsibility
for security updates to the gnome platform snap for even more
packages.
As per https://snapcraft.io/docs/snap-layouts,
bind-mounts significantly increase the startup time of the snap.
Use symlink instead for better performance.
This changes all the lambdas to have explicit captures, since the use of
implicit captures has led to some memory errors, especially segfaults in
the right-click menu.
I'm not 100% sure that the code is correct anyway - it really needs auditing
to ensure all referenced values are still valid when the menu item is clicked
(e.g. can you change stuff with keyboard shortcuts while the context menu is
visible?), but it should at least be *more* correct!
This was incorrectly capturing `r` by reference and using it after it left
its scope. Changed to capture by value, and also explicitly capture `this`
in case we were accidentally capturing any other scope variables by reference.
Fixes#571
* Limit u,v range between 0 and 1 in Newton. Fixes issue #471
* Change the math for projecting a point onto a plane to work better with non-orthogonal U,V derivatives in several places. Fixes#472.
Both GCC and Clang use x87 instructions by default on 32-bit x86
targets, but the loss of precision resulting from that has yielded
crashing tests (see referenced issue), and it can be safely assumed
there are very few CPUs that both don't support SSE2 and are expected to
run SolveSpace
This commit also removes a now-redundant check for 32-bit Windows
against TARGET, which doesn't seem to be actually set by CMake at all
Ref: #565
This has lead to linker problems if the environment does have standard
versions of zlib/png (like from MSYS2), see discussion in referenced
issue
Closes#559
flatbuffers hard-code general -Werror, which led to builds failing on
clang 11.0.0-++20200307120047+01c48d7d11e-1~exp1~20200307110643.632
with a plethora of
../extlib/flatbuffers/include/flatbuffers/flatbuffers.h:1720:25:
error: definition of implicit copy constructor for
'TableKeyComparator<reflection::Object>' is deprecated because it has
a user-declared copy assignment operator [-Werror,-Wdeprecated-copy]
See:
https://github.com/solvespace/solvespace/issues/92#issuecomment-567831112
The problem was first introduced here:
dabd57847e
and later "fixed" here:
f324477dd0
by setting the stack size to /STACK:33554432
Solvespace now starts up even with /STACK:554432
According to this:
https://en.cppreference.com/w/cpp/language/value_initialization
```
"2) if T is a class type with a default constructor that is neither user-provided nor deleted (that is, it may be a class with an implicitly-defined or defaulted default constructor), the object is zero-initialized and then it is default-initialized if it has a non-trivial default constructor; "
```
So removing the `{}` should leave both the `System` and `TextWindow` class instances properly initialized.
A warning found with /W4 by MSVC 2019 (Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28314)
is an actual bug. How does the SpaceMouse (I do not have one) work at all when the global `hSpaceWareDriverClass` is NULL?!
.\src\platform\guiwin.cpp(1392,34): warning C4459: declaration of 'hSpaceWareDriverClass' hides global declaration
.\src\platform\guiwin.cpp(1389,13): message : see declaration of 'SolveSpace::Platform::hSpaceWareDriverClass'
Found with /W4 by MSVC 2019 (Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28314)
A bunch of implicit casts 'double' to 'float' and one 'int64_t' to 'unsigned'.
.\src\platform\guiwin.cpp(1237): warning C4701: potentially uninitialized local variable 'cursorName' used
.\src\platform\guiwin.cpp(1237): warning C4703: potentially uninitialized local pointer variable 'cursorName' used
.\src\solvespace.cpp(805,30): warning C4456: declaration of 'gs' hides previous local declaration
.\src\solvespace.cpp(715,17): message : see declaration of 'gs'
.\src\solvespace.cpp(849,47): warning C4456: declaration of 'e' hides previous local declaration
.\src\solvespace.cpp(847,29): message : see declaration of 'e'
.\src\render\render.h(288,51): warning C4458: declaration of 'camera' hides class member
.\src\render\render.h(271,17): message : see declaration of 'SolveSpace::SurfaceRenderer::camera'
.\src\render\render.h(289,57): warning C4458: declaration of 'lighting' hides class member
.\src\render\render.h(272,17): message : see declaration of 'SolveSpace::SurfaceRenderer::lighting'
Remove all files from snap that are already included in the base snap
or in any connected content snaps.
The main advantage is the massively reduced snap size:
From ~70 MB down to ~6 MB.
Snapcraft's remote-build does not fit the requirements of CI,
so replace it with builds running directly on Travis:
1. Builds on Travis can run independently, whereas remote-build
competes for the same resource (Launchpad) and will potentially
block if multiple commits require building in succession.
2. Snapcrafts CLI for remote-build is not designed to be easily
scriptable.
3. Travis recently introduced building on arm64, so builds for
arm64 are now very fast and don't require emulation.
We do not build for armhf and i386 any more because they are
of little relevance on the desktop.
dpl-snap only supports pushing one snap at a time.
Instead of many repetitive deploy statements,
we use our own script to loop over the snaps to be released.
We invoke builds on Launchpad in stage "deploy" and release it into
the edge channel of the Snap Store.
The deploy stage is blocked on fails of the test stage, so we don't
release snaps with failing tests.
It turns out that using cmake_policy(VERSION) is effectively same as
using cmake_minimum_required(VERSION) because it is a hard error
if the CMake running the script is too old. As such, replace 22525e65
with two changes:
* Set the minimum required version to 3.7.2 (Debian stretch),
which also configures policies.
* If CMake is at least as new as 3.11.0, then set the policies
according to that version.
This should actually have the intended behavior.
GetIdent is called from an UI event callback, at which point there
might well not be an active GL context. Before this commit, that
would return a NULL pointer and result in a crash.
whitequark
phkahler
ruevs
Maximilian Federle
Ryan Pavlik
Tim
nabijaczleweli
Roc
Koen Schmeets