Fix to CONST with the math evaluator to toss a message and error with values out of acceptable range for ARCSEC and ARCCSC.
Tweak to _PI to add constexpr for speedier execution.
Fix to the math tests for the new (and unbuggy) values for ARCSEC and ARCCSC.
Fairly simple, MacOS High Sierra's libcurl version is too old and not
have `CURLINFO_CONTENT_LENGTH_DOWNLOAD_T`. This adds a version check to
use the older version of that command which gives back a double instead.
Fixes: #287
Currently main() includes logic that is intended to sync time() with
GetTicks() for the purpose of using GetTicks() to get millisecond
accuracy with time(), which only has second accuracy. Unfortunately, the
'syncing' up of these time sources results in an average of a half
second delay in starting a QB64-PE program.
This logic is easly replaced with std::chrono, which provides a real
time clock which is also millisecond accurate. That removes the need to
use time() and GetTicks() together to get millisecond accuracy, and
means the delay syncing them is no longer necessary.
I also separated most of the "delay" and "time" related functions into
datetime.cpp, and included the new std::chrono code into that file.
Since I needed to call some of the rounding functions in datetime.cpp I
also moved that stuff out into its own .cpp and header files to clean
things up a bit.
Fixes: #282
Fairly simple, the finished entry is free'd and then removed from the
list, but that order results in us accessing the entry's next member
after it has been free'd. Swapping the order of the operations fixes the
issue.
Fixes: #281
The commands _ScreenX and _ScreenY got significantly slower due to the
need to wait for the GLUT thread to wake up and execute the glutGet()
command for them. We've already seen a few programs (including the IDE)
where this behavior completely grinds the program to a halt, so we
definitely can't keep it.
The simple solution here is to not call glutGet() on every _ScreenX/Y
command. Instead every time the idle/timer function runs we get the
current values for the relevant glutGet() variables and store them.
libqb_glut_get() then checks if the value being read is one of the ones
we read in the idle/timer functionand if so just returns the last read
value. By doing it this way the commands no longer has to wait on the
GLUT thread for the result.
Fairly straightfowrad, programs were randomly seg faulting on exit. This
was happening due to GLUT registering a cleanup function via atexit(),
which then gets called when exit() is called.
The issue happens when exit() is called on a thread other than the GLUT
thread, which leads to the exit() call then attempting to cleanup GLUT
while the other thread is still using it, which randomly leads to seg
faults.
Fixing this is slightly annoying. We cannot stop the GLUT thread, as
the basic GLUT API (which is used on Mac OS) simply does not offer a way
to exit the glutMainLoop() call. Thus the simplest solution is to simply
make sure we call exit() on the GLUT thread, which we can fairly easily
due via the message queue.
That being the case, a new libqb_exit() API was added, which simply
regsiters the GLUT exit message and then waits for the program to end.
The atexit() handler then runs on the GLUT thread and everything works
out fine.
In the future we probably should redo the exit logic a bit so that all
the threads are actually stopped/joined to ensure the exit process is
consistent, however this is good enough for now. Also, there's plenty of
error states which call exit() which I did not address.
This fixes all the code so that all the calls to glut functions
happen on the same thread that is running GLUT.
We achieve this by creating a queue of GLUT commands to execute.
Commands can be added to the queue anywhere in the code, and then the
queue is processed on the GLUT thread via it's idle func or timer func.
The command is run and if necessary the result is provided in the
message queue object. Each object contains a completion which can be
waited on to block until the GLUT thread has processed the command.
Fixes: #66
This adds the libqb_http API, which is designed to support HTTP and
HTTPS usage from QB64-PE source.
The design consists of a single thread which services all the HTTP(s)
connections. There are then various libqb_http APIs exposed that allow
interacting with this thread to create a new connection, query
connection status, read data, or close the connection.
Internally the thread makes use of the curl_multi interface to allow a
single thread to service multiple HTTP(s) connections in parallel. This
means you can _OPENCLIENT() multiple HTTP connection in a row and all of
them will be serviced at the same time in whatever order data is
available.
HTTP is optional and selected via a Makefile setting. A stub is swapped
in if HTTP support is not used, which avoids need to add another build
flag to libqb.cpp.
