VS2013 does not have constexpr support and in general is quite buggy.
There's no reason to use it anymore as even XP toolsets are available
for VS2015 and VS2017.
* Don't use a reserved identifier in include guards.
* Use fabs() from <cmath> instead of our own ffabs().
This shouldn't make any difference with modern toolchains.
* Convert a few preprocessor macros to constexprs.
After this commit, dbp() is renamed to DebugPrint() and moved to
platform.cpp, next to other similar functions. The existing short
name is provided by a preprocessor macro, similar to ssassert().
This leaves just the (rather hacky) temporary heap in util*.cpp.
This commit performs three related cleanups:
* The slvs library no longer uses explicit platform initialization
(which drags in the side effects of InitPlatform that are not
desirable in a library). Instead, it just ensures that it has
the temporary heap, which is what it was callingInitPlatform for.
* InitPlatform is simplified and moved to platform.cpp, next to
other path related functions.
* InitPlatform is renamed to InitCli and is called from InitGui
implementations. GUI toolkits sometimes have options they use
internally (that's the case for for GTK and Cocoa at least),
and we shouldn't try to parse those as a file to open.
Historically SolveSpace used its own heap on Windows since it gave
better control and debugging options, but a lot of development these
days happens on Linux, where that heap was a stub around malloc/free,
and also Windows debugging tools got a lot better.
In terms of immediate benefit, this commit fixes heap corruption
on Windows introduced in commits b4e1ce44 and 47e82798, caused
by allocating with HEAP_NO_SERIALIZE in parallel from OpenMP threads.
Without HEAP_NO_SERIALIZE there's no performance benefit to keeping
our own heap, either.
The vl() function is also removed because for development there are
better tools now, and the only place where it was permanently called
from became a no-op, since temporary heap always validates after
FreeAllTemporary() recreates it.
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.
ruevs
whitequark
phkahler
Maximilian Federle
Ryan Pavlik
Tim
nabijaczleweli
Roc
Koen Schmeets