Is there a way to tell clang-format to break and align trailing comments behind #defines, but leave the macro as it is?
What I write:
#define IDENTIFY_MODE_BSP_EVT BSP_EVENT_KEY_3 // Button event used to enter the Bulb into the Identify mode.
#define ZIGBEE_NETWORK_STATE_LED BSP_BOARD_LED_2 // LED indicating that light switch successfully joind Zigbee network.
#define BULB_LED BSP_BOARD_LED_3 // LED immitaing dimmable light bulb.
What I want clang-format to do:
#define IDENTIFY_MODE_BSP_EVT BSP_EVENT_KEY_3 // Button event used to \
enter the Bulb into the \
Identify mode.
#define ZIGBEE_NETWORK_STATE_LED BSP_BOARD_LED_2 // LED indicating that light \
switch successfully joind \
Zigbee network.
#define BULB_LED BSP_BOARD_LED_3 // LED immitaing dimmable \
light bulb.
What clang-format does:
#define IDENTIFY_MODE_BSP_EVT \
BSP_EVENT_KEY_3 // Button event used to enter the Bulb into the Identify
// mode.
#define ZIGBEE_NETWORK_STATE_LED \
BSP_BOARD_LED_2 // LED indicating that light switch successfully joind
// Zigbee network.
#define BULB_LED BSP_BOARD_LED_3 // LED immitaing dimmable light bulb.
#define LED_CHAIN_DOUT_PIN \
NRF_GPIO_PIN_MAP(0, 5) // GPIO pin used as DOUT (to be connected to DIN pin
// of the first ws2812 led in chain)
My .clang-format file so far:
BasedOnStyle: Google
AlignConsecutiveMacros: true
AlignTrailingComments: true
ColumnLimit: 80
Related
I'm fairly new to neovim (nvim) so forgive my lack of knowledge, many questions are similar to mine, but not quite the same.
I would like this:
by default should cut/copy to a buffer, not system clipboard.
it's other register (I think its +, please correct me if its *!) should go to the system clipboard.
I have done some research but nothing (so far) is working for me.
Info:
I use tmux so pushing to tmux buffers.
I'm away from home, so currently using termux so termux-clipboard-get/set
Here is what I thought would work in my case:
let g:clipboard = {
\ 'name': 'TmuxTermux',
\ 'copy': {
\ '*': ['tmux', 'load-buffer', '-'],
\ '+': ['termux-clipboard-set'],
\ },
\ 'paste': {
\ '*': ['tmux', 'save-buffer', '-'],
\ '+': ['termux-clipboard-get'],
\ },
\ 'cache_enabled': 1,
\ }
Now when I cut/copy, tmux buffers share vim's content, PERFECT! (almost...),
I cannot use the + buffer to use the system clipboard though, if I press '+' its just moves my cursor down by one line, if I swap the above order (make termux-clipboard-get/set the * register, instead of +), when I press * it highlights all instances of the word my cursor is on.
From reading, I expected:
By default, nvim use * register, this seems to be true as it successfully registers to tmux buffers with dd/yy and pastes with p (or in tmux with my bind of [PREFIX]+[p]
If I want to cut/copy/paste to my other register + (system clipboard), then I would use +dd/+yy and then paste with +p (or even *dd/*yy/*p) but this isnt working for me.
Problem:
As explained above, + will move my cursor down one line, when changing it to the * register, * highlights the current word and any other occurance of it
Apologies to those with more experience, I'm fresh from emacs (with a very sore pinky finger!:)
In order to yank to or put from a specific register, you have to prepend the name of the register with a ":
Bad
Good
+dd
"+dd
*dd
"*dd
+yy
"+yy
*yy
"*yy
Here's what worked for me in neovim under tmux on macOS:
init.vim (vimscript):
let g:clipboard = {
\ 'name': 'macos+tmux',
\ 'copy': {
\ '+': ['pbcopy'],
\ '*': ['tmux', 'load-buffer', '-'],
\ },
\ 'paste': {
\ '+': ['pbpaste'],
\ '*': ['tmux', 'save-buffer', '-'],
\ },
\ 'cache_enabled': 0,
\ }
In neovim's source code, pbcopy/pbpaste is used without cache_enabled, and the documentation on that setting is confusing to me so I think it is safer to leave it off.
Note that you cannot only override one of the registers with this configuration -- meaning if you only want to change one of the registers' behavior, you still have to replicate the other register's functionality with this g:clipboard configuration. The source can be a helpful reference:
https://github.com/neovim/neovim/blob/22b538139606321bb1083665c510e81adb3d6670/runtime/autoload/provider/clipboard.vim
Also, since this isn't exactly documented, the idea with these configurations is that each array is a set of command line arguments, where the copied/pasted text is expected to be produced on STDIN and STDOUT respectively.
I have the following flex source:
%{
#if !defined(__linux__) && !defined(__unix__)
/* Maybe on windows */
#endif
int num_chars = 0;
%}
%%
. ++num_chars;
%%
int main()
{
yylex();
printf("%d chars\n", num_chars);
return 0;
}
int yywrap()
{
return 1;
}
I generate a C file by the command flex flextest.l and compile the result with gcc -o fltest lex.yy.c
To my surprise, I get the following output:
flextest.l:2:37: error: operator "defined" requires an identifier
#if !defined(__linux__) && !defined(__unix__)
After further checking, the issue seems to be that flex has actually replaced __unix__ with the empty string, as shown by:
$ grep __linux_ lex.yy.c
#if !defined(__linux__) && !defined()
Why does this happen, and is it possible to avoid it?
It's actually m4 (the macro processor which is used by current versions of flex) which is expanding __unix__ to the empty string. The Gnu implementation of m4 defines certain symbols to empty macros so that they can be tested with ifdef.
Of course, it's (better said, it was) a bug in flex. Flex shouldn't allow m4 to expand macros within user content copied from the scanner definition file, and the current version of flex correctly arranges for the text included from the scanner description file to be quoted so that it will pass through m4 unmodified even if it happens to include a string which could be interpreted by m4 as a macro expansion.
The bug is certainly present in v2.5.39 and v2.6.1 of flex. I didn't test all previous versions, but I suppose it was introduced when flex was modified to use m4, which was v2.5.30 according to the NEWS file.
This particular quoting issue was fixed in v2.6.2 but the current version of flex (2.6.4) contains various other bug fixes, so I'd recommend you upgrade to the latest version.
If you really need a version which could work with both the buggy and the more recent versions of flex, you could use one of the two following hacks:
Find some other way to write __unix__. One possibility is the following
#define C(x,y) x##y
#define UNIX_ C(__un,ix__)
#if !defined(__linux__) && !UNIX_
That hack won't work with defined, since defined(UNIX_) tests whether UNIX_ is defined, not whether what it expands to is defined. But normally built-in symbols like __unix__ are actually defined to be 1, if they are defined, and the #if directive treats any identifier which is not #define'd as though it were 0, which means that you can usually leave use x instead of defined(x). (However, it will produce different results if there were a #define x 0 in effect, so it's not quite a perfect substitute.)
Flex, like many m4 applications, redefines m4's quote marks to be [[ and ]]. Both the buggy flex and the corrected versions substitute these quote marks with a rather elaborate sequence which effectively quotes the quote marks. However, the buggy version does not otherwise quote user-defined text, so macro substitutions will be performed in user text. (As mentioned, this is why __unix__ becomes the empty string.
In flex versions in which user-defined text is not quoted, it is possible to invoke the m4 macro which redefines quote marks. These new quote marks can then be used to quote the #if line, preventing macro substitution of __unix__. However, the quote definition must be restored, or it will completely wreck macro processing of the rest of the file. That's a bit tricky because it is impossible to write [[. (Flex will substitute it with a different string.)
The following seems to do the trick. Note that the macro invocations are placed inside C comments. The changequote macros will expand to an empty string, if they are expanded. But in flex versions since v2.6.2, user-supplied text is quoted, so the changequote macros will not be expanded. Putting them inside comments hides them from the C compiler.
%{
/*m4_changequote(<<,>>)<<*/
#if !defined(__linux__) && !defined(__unix__)
/*>>m4_changequote(<<[>><<[>>,<<]>><<]>>)*/
/* Maybe on windows */
#endif
(The m4 macro which changes quote marks is changequote but flex invokes m4 with the -P flag which changes builtins like changequote to m4_changequote. In the second call to changequote, the two [ which make up the [[ sign are individually quoted with the temporary << quote marks, which hides them from the code in flex which modifies use of [[.)
I don't know how reliable this hack is but it worked on the versions of flex which I had kicking around on my machine, including 2.5.4 (pre-M4) 2.5.39 (buggy), 2.6.1 (buggy), 2.6.2 (somewhat debugged) and 2.6.4 (more debugged).
I have a Beaglebone Black from which I use the some VCC pin. I need to programatically turn on/off VCC pins.
Say, the VCC pin number is #5, I am looking for some Linux command that will turn that particular pin on/off.
Is it possible via command line? or, there are some other way? is it possible at all?
please help.
What does you mean "VCC pin"?
You can't on/off VDD pins on connector P9 but tou can control GPIO pins (and switch power from VDD pins with an appropriate transistor).
From command line one can control GPIO via sysfs interface.
debian#beaglebone:$ cd /sys/class/gpio
debian#beaglebone:/sys/class/gpio$ ls
export gpio14 gpio26 gpio4 gpio48 gpio60 gpio68 gpiochip64
gpio112 gpio15 gpio27 gpio44 gpio49 gpio61 gpio69 gpiochip96
gpio114 gpio2 gpio3 gpio45 gpio5 gpio65 gpio7 unexport
gpio115 gpio22 gpio30 gpio46 gpio50 gpio66 gpiochip0
gpio116 gpio23 gpio31 gpio47 gpio51 gpio67 gpiochip32
You can see here directories for already exported GPIO pins and some additional files, see GPIO Sysfs Interface for Userspace
For example, I use GPIO49 (P9, pin 23) for LED control:
debian#beaglebone:/$ sudo su
root#beaglebone:/# cd /sys/class/gpio/gpio49
root#beaglebone:/sys/class/gpio/gpio49# cat direction
in
root#beaglebone:/sys/class/gpio/gpio49# echo out >direction
root#beaglebone:/sys/class/gpio/gpio49# echo 1 >value
root#beaglebone:/sys/class/gpio/gpio49# echo 0 >value
root#beaglebone:/sys/class/gpio/gpio49#
So that, you can control GPIO pins manually from command line, from bash script, and from any user-space program using file i/o.
I found dev-USB-PWR-CTL-00A1.dtbo file. (I think this is source code for it).
Using this file I try to expose USB1_DRVVBUS pin as GPIO (GPIO3_13) with commands:
echo dev-USB-PWR-CTL > /sys/devices/platform/bone_capemgr/slots
echo 109 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio109/direction
I see new cape entry in slots and new gpio files tree.
But when I change value with command
echo 0 > /sys/class/gpio/gpio109/value
I see new value in this file but nothing happens with USB VBUS.
What am I missing?
(Before you ask do I really need this: let's leave the consequences on the side for a moment.)
Have you looked at this? question about exactly this on the Beagleboard Google Group
Please note that there are some differences to back then and current images, e.g. by default CapeManager is disabled and overlays are loaded once in U-Boot
If you are using a recent elinux.org Debian image (the necessary device tree overlay was merged in June 2015), it includes a device tree overlay (with the comment "Unless you know what you are doing, do not load this cape!!!"). This uses a hack to expose the usb1_drvvbus signal as a fictitious LED, which can then be controlled using the led interface in /sys.
Firstly, load the dev-USB-PWR-CTL-00A1.dtbo device tree overlay. For recent setups (where all dtbos are loaded by uboot and then passed to the kernel at boot time), this could be done by adding dtb_overlay=/lib/firmware/dev-USB-PWR-CTL-00A1.dtbo to /boot/uEnv.txt and rebooting (older kernels/uboots will need to use the older config mechanisms as described in /boot/uEnv.txt).
You can then do this:
echo 'usb1' > /sys/bus/usb/drivers/usb/unbind
echo 0 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
sleep 1
echo 255 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
echo 'usb1' > /sys/bus/usb/drivers/usb/bind
... to power-cycle the device attached to USB1.
I'm working with Fortran code that has to work with various Fortran compilers (and is interacting with both C++ and Java code). Currently, we have it working with gfortran and g95, but I'm researching what it would take to get it working with ifort, and the first problem I'm having is figuring out how to determine in the source code whether it's using ifort or not.
For example, I currently have this piece of code:
#if defined(__GFORTRAN__)
// Macro to add name-mangling bits to fortran symbols. Currently for gfortran only
#define MODFUNCNAME(mod,fname) __ ## mod ## _MOD_ ## fname
#else
// Macro to add name-mangling bits to fortran symbols. Currently for g95 only
#define MODFUNCNAME(mod,fname) mod ## _MP_ ## fname
#endif // if __GFORTRAN__
What's the macro for ifort? I tried IFORT, but that wasn't right, and further guessing doesn't seem productive. I also tried reading the man page, using ifort -help, and Google.
You're after __INTEL_COMPILER, as defined in http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/win/compiler_f/bldaps_for/common/bldaps_use_presym.htm
According to their docs, they define __INTEL_COMPILER=910 . The 910 may be a version number, but you can probably just #ifdef on it.
I should note that ifort doesn't allow macros unless you explicity turn it on with the /fpp flag.