I would prefer "yes" and "no" as it distinguishes boolean values from numeric
but using "yes and "no" results in PBD::Property<T>::from_string failing to
parse the correct values when opening in an older Ardour version as there is no
specialization for bool.
Using 0 and 1 also results in less change to the Session file.
All conversions are performed as if in the "C" locale but without actually
changing locale.
This is a wrapper around printf/sscanf for int types which aren't affected by
locale and uses glib functions g_ascii_strtod and g_ascii_dtostr for
float/double types.
My first attempt at this used std::stringstream and
ios::imbue(std::locale::classic()) as it should be thread safe, but testing
shows it is not for gcc/mingw-w64 on Windows, and possibly also some versions
of macOS/OS X.
Use "yes" and "no" when converting a boolean in PBD::string_to<bool> as this
seems to be the convention used throughout libardour which will allow using
string_to<bool> in those cases.
Add accepted bool string values from PBD::string_is_affirmative to
PBD::string_to<bool>
Mark strings in pbd/string_convert.cc as not for translation
Add u/int16_t string conversions to pbd/string_convert.h and tests
Add DEBUG_TRACE output on conversion errors
Add int8_t/uint8_t conversions(using int16/uint16 types) to string_convert.h
Add support for converting an infinity expression to/from string
Follows the C99/C11 standard for strtof/strtod where subject sequence is an
optional plus or minus sign then INF or INFINITY, ignoring case.
This currently fails because the windows only realpath implementation in
pbd/pathexpand.cc, which is called from PBD::canonical_path to resolve the path
uses Glib::locale_from/to_utf8. As I demonstrated in the
testOpenFileUTF8Filename test case Glib::locale_from/to_utf8 are not the
correct functions to use for this use case as it converts to/from utf-8 to the
locale's current character encoding. On Windows this is most often a single
byte encoding such as Windows-1252 and conversion will fail if the path
contains any characters that are not in system codepage.
The default scheduling on windows seems fairly erratic or is at least in the
VM that I'm running these tests on, so increase the timing slack a bit so the
test has a better chance of passing. It is still quite easy for it to fail
though, especially if you for instance manipulate the terminal window somehow
while running the tests but it does not really matter in any case as this test
serves its purpose in testing the PBD::MMTimers API.
Remove the directory recursively including itself. The function
is used in two places only:
* LV2Plugin::add_state() -- no change, remove tmp. state
* Session::save_as() -- on error, remove target
In both cases removing the folder itself is correct.
It looks as if the default timer resolution for applications running under wine
is different than Windows so just test that the minimum timer resolution is
below a certain amount rather than checking before and after calling
timeBeginPeriod
GStatBuf is not usable on 32 bit Windows without the redefinition in
pbd/gstdio_compat.h so add a test to check for the correct behavior of
g_stat and g_utime on all platforms now that the issue is fixed.
I'm not sure if this test is going to be effective as I don't have hardware to
test on at the moment. As noted in the documentation, Windows XP should be the
only OS where QPC uses a timer source that is non-monotonic(multi-core with
non-syncronized TSC).
This shows that PBD::Timer is pretty much identical in terms of timing and CPU
usage as Glib TimeoutSources.
They also show the differences on Windows when setting the minimum Multimedia Timer
resolution using timeBeginPeriod
From this I can see that PBD::copy_file is not working correctly on windows
as it is adding windows style line endings. Adding O_BINARY to ::open flags
would fix it, but perhaps there is a better way...
Windows headers define SearchPath which means we have to undefine it
where necessary. This is a pain and can be tricksy, so I feel renaming
the class slightly is the easiest solution.