| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Previously we'd get an error if the first lines in the mappings file
were blank or comments.
|
|
This broke recently I think. You can no longer have a mappings file that
starts with blank lines or comment lines.
Removing the empty and blank handler in `definitions()` fixes the tests
added by this commit but fails these:
parser::tests::map_group_empty_input_does_not_fail
parser::tests::map_group_skipped_input_outputs_default_map_group
Using this diff:
diff --git a/src/parser.rs b/src/parser.rs
index 3f3d7b9..d18b56a 100644
--- a/src/parser.rs
+++ b/src/parser.rs
@@ -629,11 +629,11 @@ where
I: Stream<Item = char>,
I::Error: ParseError<I::Item, I::Range, I::Position>,
{
- or(
- (
- blank(),
- eof(),
- ).map(|_| MapGroup::default()),
+ // or(
+ // (
+ // blank(),
+ // eof(),
+ // ).map(|_| MapGroup::default()),
(
definitions(),
eof(),
@@ -661,8 +661,8 @@ where
}
map_group
- }),
- )
+ })
+ // )
}
fn comment<I>() -> impl Parser<Input = I>
Need to figure out some way to get both sets of tests to pass.
|
|
Remove the TODO key and use a real one instead. A description of the
program.
|
|
Check that the desired error messages appear for a couple extra invalid
mapping definitions.
Rename the existing `map_group_shows_error_in_middle_of_line()` test to
use the naming pattern of the two new tests.
The new tests check that the right errors appear in map actions, and for
missing the closing brace on a mode definition.
|
|
Just noticed this. Seems it served its purpose.
|
|
In addition to asserting the position of the error, also check that it's
the error we expect by looking for an unexpected 'n' token.
|
|
This seems to fix the problem of errors in the middle of definitions not
being surfaced (what the test in
3091ebe0deb1ba832b4a5925263409ec5b651c62 is for).
Need to write some more tests for other error cases.
The reason why this happens is because `try()` causes the parser to not
consume the input. Since the input isn't consumed, I guess the error
messages from within never get surfaced. Moving the `try()` further down
the parser tree appears to fix things.
|
|
I wrote the wrong column number on which the error should occur.
|
|
Since the errors are going to be different from what's written in the
test expectation, just remove them to correct the test. We kind of only
care about the position. Maybe the first error would be interesting to
match on, but let's just get rid of the part we know is wrong.
|
|
|
|
|
|
This functions correctly. No need for the TODO.
|
|
We currently correctly report errors in the middle of the first line
(problems with the trigger, problems with special keys in an action),
but for all subsequent lines, the error message is limited to the first
character on the line. This means that even if you write "map", "cmd",
or "mode", which are all correct, the error message will refer to
"column 1", even though the actual error is in a different part of the
parser.
Not sure why that's happening, nor why it doesn't happen for the first
line. But at least we have a test for it now. The test will need to be
modified once I can actually get the error messages propagating
correctly, as the `Expected` lines are going to be wrong. They were just
copy-pasted from the test above this one.
|
|
This was split into two new functions, `map_kind_map()` and
`map_kind_cmd()`, in 7776832ec11ee7d4e62cfd2a6ad7735f323ab5bc. As such,
this function is no longer used or needed.
Update the tests to use the new parser functions.
|
|
Now that `run_action()` returns a `Result`
(e4c21b11069297d289f25834cfc3c001a4604b5f), we need to use that `Result`
when we call it in `run_key_action()`.
Pass on the `Result` to `ffi::run_key_action()`, and print the error
message from there.
|
|
Revert changes from 75d52e385fa66d6e151c9baa2cf22c2223c39ff0. These are
obsolete.
Now that we parse actions right in the main parser
(7776832ec11ee7d4e62cfd2a6ad7735f323ab5bc), get rid of all code related
to the second pass parser from `Action::String`s into `Action::Map`s, as
it's obsolete.
All of this action parsing is now handled by the main `map_group()`
parser.
|
|
Was having a hell of a time trying to return a `Result` from
`MapAction::parse()` in 75d52e385fa66d6e151c9baa2cf22c2223c39ff0. After
struggling with it, I started to think if there was a different way to
go about this. Previously I had tried and failed to parse map actions in
the main parser. If I could get that working, then this whole
`MapAction::parse()` method would be obsolete. No need to muss with
`Result`s and borrowed strings at all.
When I originally wrote the parser code, I thought in terms of: "How do
I get the parsed result of the `map()` parser into the `action()` parser
so that it can conditionally parse one way for the `map` keyword, and
another for the `cmd` keyword?". In hindsight, this was incredibly
idiotic, but I guess I was too close to the code and too deep in the
details.
Obviously the answer to parsing differently depending on `map` or `cmd`
is not to get the parsed result of `map()` into `action()`. These are
parser combinators. _Of course_ we can just make two map definition
parsers, one for `map` and another for `cmd`. Can't believe I never
thought of that last time. Who knows how much time I wasted trying and
failing, then writing a sub-optimal solution.
Oh well, I guess I should just be thankful that a niggling logging
problem (in `MapAction::parse()`) that turned into a maddening journey
to a giant brick wall in search of a `Result` return value with correct
borrows finally enlightened me to the fact that I was doing the wrong
thing all along.
* Comment out double-parsing code related to `MapAction::parse()`
because we want to parse in a single go. No more two-pass parsing.
* Split the `map_kind()` parser into two separate parsers for `map` and
`cmd`. Similarly, split the `map()` parser into `map_map()` and
`map_cmd()` for the same reason. Our new parser tree looks like this:
map(): map definition line
-> map_map(): `map` definitions
-> map_kind_map(): `map`
-> map_cmd(): `cmd` definitions
-> map_kind_cmd(): `cmd`
* Up the `recursion_limit` to 256 from 128 because I was getting stack
size errors randomly when I was updating the tests for this code
change.
* Update `action_character()` to not parse `\n` newlines. Otherwise the
newline gets included as a real `Character` in the
`KeyboardKeyWithModifiers` vector.
* The `map_collection_fails_without_terminating_newline()` test fails as
a result of the `action_character()` parser change. Previously it
relied on `map` lines parsing to `Action::String`s, which fail if
there's no terminating newline. Now that `map`s parse to
`Action::Map`s, the newline isn't checked by the map line parser
(`map_map()`). Because the newline doesn't matter for `map`
definitions, the parser would return `Ok`, failing this test even
though the behaviour was correct. Change the map line to a `cmd` to
have the test check the behaviour it was previously testing.
* Update the tests to use parsed `Action::Map` instead of
`Action::String`s where appropriate. Used this program to convert the
strings into the correct source code:
# action_string_to_action_map.py
#!/usr/bin/env python3
import sys
action_string = sys.argv[1]
action = ''
action += 'action: Action::Map(vec![\n'
for c in action_string:
action += ' KeyboardKeyWithModifiers::new(\n'
action += " KeyboardKey::Character(Character::new('{}')),\n".format(c)
action += ' vec![],\n'
action += ' ),\n'
action += ']),'
print(action)
|
|
Want to be able to return a `Result` here so we can print the error from
the `ffi` module so we don't have to permit 'stderrlog' on this parser
module.
Beset with errors like this:
error[E0506]: cannot assign to `self.action` because it is borrowed
--> src/parser.rs:188:21
|
176 | Action::String(ref s) => {
| ----- borrow of `self.action` occurs here
...
188 | self.action = action;
| ^^^^^^^^^^^^^^^^^^^^ assignment to borrowed `self.action` occurs here
error: aborting due to previous error
Even cloning the `Action` doesn't work because the Combine error
`Result` needs an `&str` reference to the parser input, and if we
reassign `self.action`, that string reference would disappear.
Need to figure out a different way of dealing with this, but I at least
want to commit what I have because the next step is going to be
something different.
|
|
Instead of handling the error in this function, pass it up to the
caller. This will allow the error message to be printed, as we've only
allowed 'stderrlog' to print log messages in the `ffi` module.
|
|
Previously, the modified input in `map_group_with_invalid_input_fails()`
in this commit would fail with a result of `Ok` instead of `Err`. The
`map_group()` parser would parse the first, correct line, and ignore the
second, incorrect one.
That's wrong. We want the whole parser to fail because it contains an
invalid sequence. Do this by ensuring `eof()` follows all
`definitions()`. This way we're guaranteed to always parse the whole
input, and any errors within get surfaced.
|
|
Instead of just printing the parse error, also print the mappings file
name to context about where the error comes from.
|
|
|
|
Since 'combine' errors aren't included in our error chain, calling
`chain_err()` only printed the message inside, not the parser error.
The trouble is, we can't add 'combine''s error to 'error-chain' because
it needs a lifetime:
combine::Easy::Errors<char, &str, SourcePosition>
and you can't use errors with lifetimes in 'error-chain'.
Since we can't use 'error-chain', just use the 'combine' error directly.
This doesn't allow us to chain an addiitional error message, but does
correctly print the parse error message.
|
|
This type is already imported. No need to use the full path.
|
|
In 13e90c090923a209e5e26fb3e609d5d12f737f53 I decided to make `Map` a
type alias to a tuple containing the key-value pair used by
`MapCollection`.
Here I've decided that I prefer the type as it was before. Sure, it was
more of an intermediary type, but it did have a name that was used
consistently. We do have to leave in our custom `HashMap` building, so
perhaps this isn't the ideal solution, but I'm going with it, at least
for now.
|
|
An input with all mixed whitespace and comments should behave the same
as empty input.
|
|
Since the most recent `many1` change
(09c0a432fb339a2218096bb9a4398fb86301488f), the parser fails on
end-of-input, or an empty string.
In that case, it should instead return the default `MapGroup`. Add a
special case for this.
|
|
Thanks to Arnavion on Mozilla#rust for clueing me into this:
> The documentation starts with "A parser in this library can be
> described as a function which takes some input and if it is
> successful, returns a value together with the remaining input."
> Key phrase being "with the remaining input"
> So I assume it just matches as best as it can (which is nothing, in
> your case)
> Maybe you want to use some one-or-more combinator rather than many
> which is a zero-or-more combinator
> Then add your own check that "the remaining input" is empty
Replacing my `many()` parsers with `many1()` correctly propagates errors
up from sub-parers. Nice!
This will fail when we try to parse an empty string, but we can just add
a special case for that to parse successfully.
|
|
Investigating why I'm not getting error messages in my parsed result.
The layer where I stop getting them is when parsing to a
`MapCollection`.
Split the list of `map()` parser out from `map_collection()` to get more
information. Turns out that the new `maps()` parser is now where parse
errors get discarded.
In an attempt to get the errors to appear, I tried to replicate the
structure of Combine's INI example parser:
https://github.com/Marwes/combine/blob/921202a018000041c9d3e8b12b7c1a53d0252f67/examples/ini.rs
That program makes a `property()` parser which outputs a 2-tuple of
`(String, String)`, and a `properties()` parser which outputs a
`HashMap<String, String>`, using the values in the tuple to construct
the HashMap.
Unfortunately, this change didn't solve the problem of the non-bubbling
error messages. Unsure about whether or not to keep this change.
|
|
Don't on errors from reading or parsing the mappings file. Instead print
the error and parse an empty mappings string.
Took a lot of doing to get this working because of this error:
error[E0597]: `dkmap` does not live long enough
--> src/ffi.rs:72:44
|
72 | match MapGroup::parse(&dkmap)
| ^^^^^ borrowed value does not live long enough
...
82 | },
| - borrowed value only lives until here
|
= note: borrowed value must be valid for the static lifetime...
Finally got tired to trying things and just decided to store the
unparsed mappings string in `State` to get it to live long enough.
|
|
This was here for reference. No longer needed.
|
|
Otherwise the literal spaces are included in the string.
|
|
This means that if any of `<Up>`, `<Play>`, or `<Down>` are undefined in
the mappings file definition, they will be set to their default action
values (as set in `MapGroup::default()`).
To get rid of the default, map the button trigger to `<Nop>`.
Update a test that didn't map `<Up>` to give it the default mapping.
|
|
If a mappings file is found but is empty, no mappings will be set. Hmm,
that sounds wrong. We still want to keep the defaults even if only some
button triggers are mapped. Making buttons do nothing is what `<Nop>` is
for, not this behaviour. Darn.
|
|
This idea is replaced by code from 'autopilot', which lives in the
`autopilot_internal` module.
|
|
This argument is meant to be use in conjunction with the `--daemon`
argument. What we had before was preventing audio from getting turned on
if `--daemon` was passed first and vice versa.
I just added to the existing if-else block without thinking. This makes
the condition separate.
|
|
Including this flag will tell the program to play interface audio
(namely the sounds for mode activated & deactivated).
|
|
Remove code that was commented in
44f6a2d5544e3ad49e5e3c52167c045aed1d56b2. Since we weren't able to
correctly link to the Core Audio framework from the Objective-C code
using this Rust audio code, get rid of it. Instead, we play audio in the
Objective-C application.
|
|
Take a function pointer argument that will be called whenever a mode is
activated or deactivated. We'll be using this on the Objective-C side to
play audio when the mode changes.
|
|
I was getting the following error when building the Objective-C project
with the latest audio playing code:
ld: warning: object file (.../DomeKey/lib/dome-key-map/target/debug/libdome_key_map.a(minimp3.o)) was built for newer OSX version (10.12) than being linked (10.7)
ld: warning: object file (.../DomeKey/lib/dome-key-map/target/debug/libdome_key_map.a(util_helpers.o)) was built for newer OSX version (10.12) than being linked (10.7)
ld: warning: object file (.../DomeKey/lib/dome-key-map/target/debug/libdome_key_map.a(aesni_helpers.o)) was built for newer OSX version (10.12) than being linked (10.7)
Undefined symbols for architecture x86_64:
"_AudioComponentFindNext", referenced from:
coreaudio::audio_unit::AudioUnit::new_with_flags::hc9c3029c77a9ba1d in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal12.rcgu.o)
"_AudioComponentInstanceNew", referenced from:
coreaudio::audio_unit::AudioUnit::new_with_flags::hc9c3029c77a9ba1d in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal12.rcgu.o)
"_AudioObjectGetPropertyData", referenced from:
cpal::cpal_impl::Device::name::h96cf527e96e03bec in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::Device::supported_formats::h9019a8aeda6b1a55 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::Device::default_format::h1cffda96edcf1b5f in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::EventLoop::build_input_stream::rate_listener::he669322d080b4fd0 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::enumerate::audio_devices::h35df9cd3ad61905a in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal8.rcgu.o)
cpal::cpal_impl::enumerate::default_input_device::h4d38066593597777 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal8.rcgu.o)
cpal::cpal_impl::enumerate::default_output_device::hfb207f3766c759d9 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal8.rcgu.o)
...
"_AudioObjectGetPropertyDataSize", referenced from:
cpal::cpal_impl::Device::supported_formats::h9019a8aeda6b1a55 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::enumerate::audio_devices::h35df9cd3ad61905a in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal8.rcgu.o)
"_AudioOutputUnitStart", referenced from:
coreaudio::audio_unit::AudioUnit::start::h0ceab6edb211b577 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
"_AudioOutputUnitStop", referenced from:
coreaudio::audio_unit::AudioUnit::stop::h2929fdfd118ee7be in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
"_AudioUnitGetProperty", referenced from:
coreaudio::audio_unit::get_property::h58ff3c44f7ccc617 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
coreaudio::audio_unit::get_property::habcd9010fa8dc136 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
"_AudioUnitInitialize", referenced from:
coreaudio::audio_unit::AudioUnit::new_with_flags::hc9c3029c77a9ba1d in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal12.rcgu.o)
"_AudioUnitSetProperty", referenced from:
coreaudio::audio_unit::set_property::h5e5a6451ac49ed54 in libdome_key_map.a(rodio-d252ad0025b836aa.rodio15.rcgu.o)
coreaudio::audio_unit::set_property::h86353d3d091c7540 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
coreaudio::audio_unit::set_property::hbaa7f6c599c38fa2 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
coreaudio::audio_unit::set_property::hf450b8b66e374b66 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal12.rcgu.o)
"_AudioUnitUninitialize", referenced from:
_$LT$coreaudio..audio_unit..AudioUnit$u20$as$u20$core..ops..drop..Drop$GT$::drop::h0a1df660f851dad4 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
After setting:
$ export MACOSX_DEPLOYMENT_TARGET=10.7
in the shell, the error changed to:
Undefined symbols for architecture x86_64:
"_AudioComponentFindNext", referenced from:
coreaudio::audio_unit::AudioUnit::new_with_flags::hc9c3029c77a9ba1d in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal12.rcgu.o)
"_AudioComponentInstanceNew", referenced from:
coreaudio::audio_unit::AudioUnit::new_with_flags::hc9c3029c77a9ba1d in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal12.rcgu.o)
"_AudioObjectGetPropertyData", referenced from:
cpal::cpal_impl::Device::name::h96cf527e96e03bec in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::Device::supported_formats::h9019a8aeda6b1a55 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::Device::default_format::h1cffda96edcf1b5f in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::EventLoop::build_input_stream::rate_listener::he669322d080b4fd0 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::enumerate::audio_devices::h35df9cd3ad61905a in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal8.rcgu.o)
cpal::cpal_impl::enumerate::default_input_device::h4d38066593597777 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal8.rcgu.o)
cpal::cpal_impl::enumerate::default_output_device::hfb207f3766c759d9 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal8.rcgu.o)
...
"_AudioObjectGetPropertyDataSize", referenced from:
cpal::cpal_impl::Device::supported_formats::h9019a8aeda6b1a55 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal0.rcgu.o)
cpal::cpal_impl::enumerate::audio_devices::h35df9cd3ad61905a in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal8.rcgu.o)
"_AudioOutputUnitStart", referenced from:
coreaudio::audio_unit::AudioUnit::start::h0ceab6edb211b577 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
"_AudioOutputUnitStop", referenced from:
coreaudio::audio_unit::AudioUnit::stop::h2929fdfd118ee7be in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
"_AudioUnitGetProperty", referenced from:
coreaudio::audio_unit::get_property::h58ff3c44f7ccc617 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
coreaudio::audio_unit::get_property::habcd9010fa8dc136 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
"_AudioUnitInitialize", referenced from:
coreaudio::audio_unit::AudioUnit::new_with_flags::hc9c3029c77a9ba1d in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal12.rcgu.o)
"_AudioUnitSetProperty", referenced from:
coreaudio::audio_unit::set_property::h5e5a6451ac49ed54 in libdome_key_map.a(rodio-d252ad0025b836aa.rodio15.rcgu.o)
coreaudio::audio_unit::set_property::h86353d3d091c7540 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
coreaudio::audio_unit::set_property::hbaa7f6c599c38fa2 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
coreaudio::audio_unit::set_property::hf450b8b66e374b66 in libdome_key_map.a(cpal-b228ca6a35ab9c25.cpal12.rcgu.o)
"_AudioUnitUninitialize", referenced from:
_$LT$coreaudio..audio_unit..AudioUnit$u20$as$u20$core..ops..drop..Drop$GT$::drop::h0a1df660f851dad4 in libdome_key_map.a(coreaudio-b5e291d8855015a5.coreaudio3.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Couldn't figure out how to get past this, so decided to move the audio
playing into the Objective-C code. It's been something of a theme, where
if something doesn't work in one language (like
dome_key_event_source_simulator), write it in the other.
Here we just comment out the audio-related code so I can work on
connecting mode activation and deactivation and audio playing. I'll be
completely removing this code soon.
|
|
It's not exactly a real test, more of a smoke test. And it plays the
actual audio, which isn't ideal when running the test suite.
|
|
* Commented code is no longer needed
* Commented reference constants have served their purpose
|
|
Log errors to stderr logger.
|
|
Mirror the `map::run_key_action()` function and add an extra `PlayAudio`
argument, which will control whether audio cues are played when a mode
is activated or deactivated.
The Objective-C code will pass in this value based on the value of a
`Config` setting, which will have come from a command line argument.
|
|
This has already been handled. See the condition just below the comment.
|
|
Play audio on mode activation and deactivation depending on the value of
the new argument.
Decided to make it an enum instead of a bool for better readability.
Will need to get rid of the `unwrap`s.
|
|
Now that this function no longer takes a "current mode" argument, the
"mode" part of the name doesn't make sense.
|
|
* Remove test "activ.wav" file
* Add mode activated and deactivated audio files
* Add two new methods to play these two sounds without having to pass in
`MODE_ACTIVATED` or `MODE_DEACTIVATED` from outside the module
* Make `play_audio()` private
The 'rodio' crate supports WAV, FLAC, MP3, and Vorbis file types. Tried
using OGG and MP3 versions of the audio, which sound effectively the
same played in an audio player, and have much better compression, but
'rodio' kept playing them choppily, in a weird staccato. Maybe the
sample rate wasn't right? No idea what the problem was. Didn't really
have the same problem with the WAV files. Unfortunate because the OGG
files were only 16K, and the MP3 files were 32K, while the WAV files are
348K. Would much rather have smaller size files, but if the sounds play
incorrectly, there's no easy way around it.
|
|
Create a new function that encapsulates the code we experimented with
for playing audio.
Clean up what we had and handle errors by passing them back in a
`Result`.
This allows us to encapsulate, audio playing so we can do it in a single
action during mode switching.
|
