Mac builds require that Qt be built from sources since the binary Qt
package is built against the clang libstdc++ C++ support library and
we need it built against the more modern libc++ C++ support library.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4963 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
The temporary development version of jt9 called jt9_omp is now the
default jt9. This means that parallel decoding of JT65 and JT9 is the
default on platforms that support OpenMP.
If parallel decoding is not required or desired, it can be constrained
by setting the environment variable OMP_THREAD_LIMIT=1. In dual mode
operating this will deliver all decodes of the current mode before any
decodes of the other with the potential impact of taking up to twice
as long to finish decoding.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4960 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
The change to use QTextEdit in read only mode cause the cursor to
become an I-beam type, this changes it to the arrow pointer type that
the previous QTextBrowser used by default.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4959 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Colours behave like other configuration items and changes are only
applied when the Settings UI is dismissed via the "OK" button.
Simplified font settings and use style sheets consistently to set the
application and decoded text fonts. This is necessary because any UI
widget that has a style sheet applied does not honor a font set by
QWidget::setFont() even if there is no font setting in the style
sheet, this is broken behaviour IMHO but that is the way Qt currently
works.
Use a style sheet to style the frequency display and clock. This is
necessary to allow fonts to be cascaded through parent style sheets
and still be overridden on these widgets.
Simplify the decoded text widgets, there is no need to use the
QTextBrowser as a super class since the simpler QTextEdit set as
read-only is sufficient. Also removed colour setting via a background
brush as it doesn't work and the HTML 'bgcolor' attribute works
correctly.
Change to UI properties of the decoded text widgets to allow
horizontal scrolling if required, this allows larger fonts to be used
without truncating decoded messages.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4957 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Description and instructions to help those adding or amending settings
values.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4952 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
procedure; better window functions for some FFTs, resulting in
better decoder performance; User-selectable colors for backgrounds
of decoded messages. NB: more testing is desirable!
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4951 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Options have been added to control frequency cut off values, mode and, Tx mode.
The comand line parser now has optional long option names and usage help.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4949 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Outputo buffer flush commands have been added after each decoded message output
to ensure that other processes get timely updates of newly decoded messages.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4948 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
The native Mac C/C++ compilers (Clang) do not support OpenMP so CMake by
default disables OpenMP for the project since it requires all project compilers
to support it. This means that we have to hack the build script on Mac to
compile the Fortran sources with OpenMP turned on and manually link in the
required OpenMP run time support to the executables.
This hack presumes that the Fortran compiler on Mac is gfortran.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4947 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
This requires setting newdat=0 after the big FFT is computed. In the OMP
code this must be done separately for each mode; so new variables newdat9
and newdat65 have been defined. Both are set to "newdat", the value
forwarded from the GUI, each time jt9[_omp][.exe] goes into action.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4946 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Also moved the same large array from stack to heap which along with
other prior changes now allows the Windows jt9 OpenMP executable to
run with a default stack size again.
This also removes a crash on the Mac version which was probably due to
excessive stack usage.
Net result is an even faster JT9 decoder.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4942 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
calls to a subroutine. I believe this fixes the known outstanding decode
issue.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4941 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
This is only a temporary fix becuase if both decoders were to produce
results that need accumulating e.g. number of decodes, then more
complex code to merge the results would be needed.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4940 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Set the CMake variables CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET
must be set before the project() command since they can effect compiler
detection and capability tests.
Only use the -stdlib=libc++ option on Mac OS X when using Clang tools.
On other platforms with Clang tools libc+ is not currently the best choice.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4938 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Accounts for each traced call per thread and accumulates by rolling up
calls with an identical call chain before printing the statistics. The
print now accounts for function calls in their call chain so the same
function will be reported more than once if it is called in different
places.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4937 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Disable timer.out generation in OpenMP builds as it is broken.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4931 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Also limit the required threads for parallel decoding to 2.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4930 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
More detailed message to come, with comparative timing statistics.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4926 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
This tries to account for function calls in different threads
separately by decorating the function name with the thread number it
is running in. This may not be the best strategy for performance
timing but it is the easiest way of making it thread safe that I can
see.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4924 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
This change introduces the program jt9_omp which is a testbed for a
multi-threaded version of the jt9 decoder program. The program jt9_omp
should be a directly substitutable for jt9 except that JT65 and JT9
decodes are computed in parallel.
Also enable the OpenMP directives in decoder.f90 - note this is not
yet a working multi-threaded decoder and the existing jt9 is still the
correct decoder to be used in WSJT-X.
Increased the available stack size for jt9_omp.exe as this is a hard
limit on Windows and the default is not big enough for the OpenMP
version of jt9.
Also Fortran array bounds checking is now disabled for Release
configuration builds so as to improve performance a little.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4922 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Also note: something's wrong when trying to decode a file read
by the GUI from disk. Will fix it soon...
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4920 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
The long FFTs can now use the multi-threaded FFTW routines.
Subroutine decode9.f90 was renamed jt9fano.f90.
The JT9 decoder's top-level functions were removed from decoder.f90
and put into a separate subroutine decjt90.f90.
Subroutine decoder.f90 is now configured for possible use of OpenMP
SECTIONS, with the JT9 and JT65 decoders running concurrently on
a multi-core machine. Note, however, that this concurrent processing
is not yet fully implemented. Probably calls to timer need to be removed;
some variables used in calls to jt65a and decjt9 may need to be
declared PRIVATE in decoder; some sections probably need to be declared
CRITICAL; probably some SAVE statements in downstream routines have
made them not thread-safe; etc., etc.
I'm a neophyte at using OpenMP. Comments, suggestions, and/or tests by
others will be welcome!
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4919 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
