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.
With the recent changes to libqb.cpp to pull out some of the GLUT logic,
the only actual Objective-C in libqb.cpp was pulled out. That being the
case, it's no longer necessary to have libqb.mm for compiling libqb.cpp,
so we're removing it to simplify the compliation logic a bit.
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
Xvfb is being used to give us an X server implementation on the Linux
build agents. A running X server is necessary for graphics to function
(which we have so far avoided testing).
These tests cover all the commands that generally interact with GLUT.
The ensure that these functions can be used at the very beginning of a
program with no issues. Additionally they verify the behavior of these
functions in the presence of `$SCREENHIDE`, and also `_ScreenHide`.
This was overlooked in #258, previously this printing was being skipped
over via a check of idemode, but after changing where it was located so
it only prints once it now runs when using the IDE, which screwed up the
drawing of the IDE screen.
The simple fix is to check for idemode before doing the printing, which
is effectively what it was doing before anyway.
Fixes: #266
Starting with #201, source files relative to `_StartDir$` are allowed to
be passed to `-x` and compile as expected. Additionally as part of that
change, when the `-x` parameter is relative to `_StartDir$`, the `-o`
argument is _also_ treated relative to `_StartDir$`. This is simply the
behavior everyone using the compiler would expect - that the source file
and `-o` are relative to the same location.
An overlooked behavior was the executable location when `-o` is not
provided. It still writes to compiler directory, but it really should be
writing to `_Startdir$` since the output executable is intended to be
relative to the same location the source file is relative too. Overall
this is fairly straight forward to fix as the logic is the same, we just
need to make use of it when the `-o` flag is not provided.
Fixes: #257
Some commands like NoPrefix trigger a complete "recompile" due to how
they work. This has the accidental effect of duplicating the command
line output, which should still only be printed once. Moving the
printing logic up a bit is a simple solution.
Fixes: #256
Fairly straight forward, QB64-PE's dependency list has to be built into
the Makefile for when we're building straight from ./internal/source.
Recently it gained a HTTP dependency, so that now needs to be included.
Fixes: #255
https://github.com/QB64-Phoenix-Edition/QB64pe/issues/233
This should fix the comparisons with $IF and VERSION. A few things of note here, which might affect future version labeling:
This expects to find version numbers which follow our current style -- ##.##.## -- 3 numbers, separated by periods.
Adding in alphabetic characters will basically get ignored, and versions with less than 3 values will generate FALSE results in all comparisons.
The current GLUT initialization logic is flawed because it allows the
QB64 code portion of the program to start on a separate thread at the
same time that the GLUT code is starting. This results in a race where
some commands won't work for a brief period at the beginning of the
program (with "won't work" being very inconsistent, some return invalid
values, some have a chance at seg faulting).
The same issue also leads to us adding many `while (!window_exists)`
checks in an attempt to solve this race for some of the commands.
Unfortunately this solution is very inconsistently applied leading to
some deadlock situations, and really it's a silly solution when this
race is entirely our creation anyway.
To fix this, the logic was changed such that we perform all of the GLUT
initialization besides calling `glutMainLoop()` before we ever start the
thread that runs the actual QB64 code. By doing it this way we ensure
that the GLUT initialization has already taken place before the code
runs and thus the race is gone.
Things get a bit more interesting with $SCREENHIDE, because that simply
delays the execution of the GLUT initialization indefinitely until
_ScreenShow is done. This was previously very buggy since some commands
rely on FreeGLUT being up and will simply hang the entire program if
run. Other commands have logic to catch this and simply return zero.
The above issue is solved with the `NEEDS_GLUT()` and `OPTIONAL_GLUT()`
macros. Both of them simply check if the GLUT initialization has taken
place and exit the current function if it has not. The difference
between the two is that `NEEDS_GLUT()` throws an 'illegal function call'
error while `OPTIONAL_GLUT()` simply exits with no error. The choice of
behavior of each function was based upon its previous behavior - if it
checked `screen_hide` and exited with no error previously, then
`OPTIONAL_GLUT()` was used. If it deadlocked or similar then
`NEEDS_GLUT()` was used (so instead of deadlocking, it now produces an
error). In this way, programs can now never get stuck due to the use of
`$SCREENHIDE` and all the commands have consistent behavior that can be
relied upon.
Fixes: #234
