Previously rescanLibraries() was automatically called internally in
setLibrariesFolder(). This lead to double calls to rescanLibraries()
when setLibrariesFolder() was used in combination with an explicit
call to rescanLibraries().
This commit adds a new method setLibrariesFoldersAndRescan(..) and
removes the internal call to rescanLibraries() from setLibrariesFolder().
The existing setLibrariesFolder()+rescanLibraries() combos have been
replaced with setLibrariesFoldersAndRescan().
Fix#10228
Previously, any CR without NL was treated just like a NL. For tools that
used single CRs to update a progress bar (such as dfu-util), this would
end up printing the subsequent versions of the progress bar below each
other, instead of updating a single line as intended. Additionally,
since ConsoleOutputStream only scrolled the view on \n, these updates
would end up outside of the main view, making the upload progress quite
unclear.
This commit makes EditorConsole support lone CRs by resetting the insert
position to the start of the current line, so subsequent writes
overwrite existing content. If subsequent lines are shorter than an
earlier line, only part of the earlier line will be overwritten (this
mimics what terminal emulators do).
Previously, the redirection would be triggered in the EditorConsole
constructor. However, this was problematic for unittests, which do not
need this redirection.
Since the redirection really is not useful intul there is a current
EditorConsole anyway, it can just be delayed a bit until
setCurrentEditorConsole is called.
This prevents the Arduino instance in tests from checking for updates. I
have not seen any problems resulting from this, but disabling network
requests is generally a good idea in tests (to prevent external factors
from influencing the test results).
In addition to update checks, there is also the CloudBoardResolver that
could do network requests, but there does not seem to be a preference
for disabling that.
This would match the "Close" dialog, by looking for any JDialog on
screen. However, in some cases, there could be a second dialog (I have
seen a "Install this package to use your xxx board" popup because I
happened to have an Arduino Zero connected, presumably an "Updates are
available" popup could cause this as well).
By matching not just the type of the dialog, but also the title, only
one dialog is matched and the testcase runs more reliably.
The tests would initialize Base, PreferencesData with default settings
and/or run the arduino executable, without specifying any settings to
use. In practice, this would read settings from e.g. `~/.arduino15`,
load libraries from the user's sketchbook, etc.
This is not a good idea, since this can be influence the test. For
example, the presence of invalid libraries would cause extra output to
be generated, which breaks the `--version` test. Or having the "Use
external editor" setting set would break tests that try to edit a
sketch.
This commit fixes this. The core of this commit is in
`AbstractWithPreferencesTest`, which sets up a clean settings dir (to
replace `~/.arduino15`) with a sketchbook and `preferences.txt` file
inside before every test (and removes it again after the test.
For some tests, this is enough, but some tests create an instance of
`Base`, which again initializes everything, including preferences, from
the default location. To prevent that, `--preferences-file` is passed to
the `Base` constructor, loading the previously set up preferences. This
is handled by the new `AbstractWithPreferencesTest.createBase()` method.
Furthermore, CommandLineTest calls the actual Arduino executable, which
has the same problem. This is fixed by passing the same
`--preferences-file` option on the commandline (generated by
`AbstractWithPreferencesTest.getBaseArgs()`).
This should prevent all tests from reading the the default settings
files, fixing some tests on my system and even speeding up the tests
somewhat (due less libraries and cores to load, probably).
Normally, init is only called once during startup, so this does not add
anything. However, when running the testsuite, PreferencesData could be
initialized multiple times in a single test run. To prevent preferences
from a previous test from interfering with subsequent tests, always
start with a clean slate when calling init.
Previously, this used the DeleteFilesOnShutdown class and a shutdown
hook, which would delete the files only after shutdown. However, the
shutdown handler would be re-added for every testcase, potentially
leading to a lot of threads trying to delete the same files.
This uses an alternative: Just keep a list of files to delete inside the
testcase and use an @After handler to delete the files directly after
each usecase.
Both classes contained some duplicate code, so unify that by making one
a subclass of the other. This also prepares for further additions that
should be inherited by both.
In one test, `--get-pref` is passed on the commandline to prevent
starting the full GUI. When ran without arguments, `--get-pref` causes
*all* preferences to be printed. Using `--version` achieves the same (no
GUI is started) with just a single line of output.
This abstracts some the common code (running Arduino, copying
output, waiting for completion, checking result) from all testcases into
a single method. This simplifies each testcase, but also prepares for
adding more common arguments to all runs in a subsequent commit.
Previously, it was ran before each test, but just running it once before
all tests is sufficient. So switch from @Before to @BeforeClass and make
the its result variable static.
This also lets ant print a message pointing to this artifact and
explaining the files inside briefly. To make sure this is only printed
inside the github action, an extra `-D` option is passed to `ant test`
from the workflow file.
To allow `if` / `unless` on the echo element, this adds some namespace
definitions (this allows them on *any* element, not just the ones that
explicitly allow it). See https://ant.apache.org/manual/ifunless.html
This ensures that all code is (re)built when running a test. Previously,
only the app code was built (because that's where the tests live),
requiring a manual full build when changing something in arduino-core.
This could lead to confusing situations, where you would changes
something but it was not always automatically recompiled.
This allows running an individual test class by specifying
-Dsingle-test-class=path.to.Classs and methods within the specified
class by specifying -Dsingle-test-methods=testMethod1,testMethod2.
Additionally, this improves the error output, but not showing full
stderr/stdout output when running the full test suite, and by generating
a browsable HTML report with test results (including stdout/stderr
output). When single-test-class is used, detailed output (including
stdout/stderr) is still printed directly.
This also moves the test result XML files into a subdirectory for
clarity, which is removed before starting a testrun (so the HTML report
does not include older test results).
In commit 067d7e925 (Delete builtin libraries sources) all the libraries
in there were removed, since they are all now automatically downloaded
during the build. To keep the repository clean, remove the empty
directory as well as the build rule that was used to copy libraries from
this (now empty) directory into the build result.
It seems this script was used to extract libraries, along with their
history, from the libraries directory of this repository. Since then,
all libraries have been extracted and then deleted in commit 067d7e925
(Delete builtin libraries sources), so no need to keep this script
around.
This keeps the repository root a bit cleaner. Since these files are used
automatically and are not intended to be directly read by users, there
is no point in keeping them in the root (github will pick up these
templates from the root, .github directory or docs directory equally).
According to JEP223, Java versions do not include trailing zero
elements. This means that e.g. Java 14.0.0 reports its version just as
"14". The changed code part expected at least three characters, so it
failed to start on such "zero-zero" Java releases. The evaluated java
version was not used anywhere, so the code block was removed.
Otherwise it may happen some weird sorting when untraslated and
translated labels are sorted together:
Arduino megaAVR Boards
Arduino nRF52 Board
ESP32 Arduino
ESP8266 Modules
Schede Arduino AVR <-- the localized string falls to the bottom
Also there is no way for 3rd party boards developers to actually provide
a translation, so let's just remove them.
This sorts the board submenus themselves, based on the displayed name.
This does not change the ordering of board items within these submenus
(which uses the order from boards.txt).
Previously, the Tools->Boards menu was one long list, divided into
different platforms by (unselectable) headers. When more than one or two
platforms were installed, this quickly results in a very long list of
boards that is hard to navigate.
This commit changes the board menu to have a submenu for each platform,
where each submenu contains just the boards for that platform.
Note that this first keeps a list of board items and then adds those to
the boards menu later. This could have been done directly, but the
intermediate list makes it easier to special-case single platform
installations, as well as sort the list in subsequent commits.
This fixes part of #8858.
There is some code that, for each submenu under Tools, shows the
selected item in the label of the submenu itself (e.g. before opening
the submenu). This was done whenever the Tools menu is opened and
iterated over all the items in the submenu to identify the s
Previously, this code only looked at direct children of the submenu.
Now, this code also looks through submenus recursively, to keep the code
working even when items are divided over sub-submenus.
This makes a small behaviour change: previously, the first selected item
with a non-zero label was used. Now, the first selected item is used,
which makes the code a bit cleaner. I cannot quickly see any case where
the first selected item would have an empty text (and even more that
there is *another* selected item), so this check seems unnecessary. If
this case would occur nonetheless, it would only mean the selected item
is not displayed in the tools menu, nothing would otherwise break.
When there are no programmers available for the current board, the
programmers menu would remain empty, which would prevent it from
unfolding and could make users think there was something wrong with the
menu.
Now, a disabled item with a message is added if no programmers are
available, which should make it more clear what is going on.
This is a followup for #9373.
This fixes a problem with the Serial UTF-8 decoder. This decoding moves
data from char[] buf, into a ByteBuffer inFromSerial, then decodes them
into a CharBuffer outToMessage and converts to a char[] to pass on.
When the buf read contained just over a full buffer worth of bytes and
contained some multi-byte characters, a situation could arise where two
decodes were needed to fill up outToMessage, leaving some data in
inFromSerial. If in this case no data would be left in buf, decoding
would stop until more data came in from serial.
This commit fixes this problem by:
- Changing the outer loop to continue running when buf is empty, but
inFromSerial is not.
- Changing the inner loop to run at least once (so it runs when buf is
empty, but inFromSerial is no).
- Breaking out of the outer loop when no characters were produced (this
handles the case where only an incomplete UTF-8 character remains in
inFromSerial, which would otherwise prevent the loop from
terminating.
- Removes a `if (outToMessage.hasRemaining()` check that is now
necessarily true if the break was not done.
This fixes#9808.
