I have started recently programming in Contiki. Currently I want to synchronize the timer of a set of nodes. To achieve this, I am using the functions of the header file timesynch.h. I include it as a normal h file at the top of my code. But whenever I try to use the functions inside it (timesynch_init() for instance) I get the following error message:
xmas_sync.co: In function process_thread_example_collect_process':
/home/user/contiki-2.7/examples/rime/xmas_sync.c:108: undefined reference totimesynch_init'
collect2: ld returned 1 exit status
make: *** [xmas_sync.native] Error 1
I do not know if I need to do something else to use these synchronization functions. My code is based on the collect example.
You need to enable timesync in application's or platform's configuration. On most platforms, it is not done by default.
To enable it in application's configuration, there are two options:
Modify Makefile to include this define in CFLAGS:
CFLAGS += -DTIMESYNCH_CONF_ENABLED=1
Create a project-conf.h file, change Makefile to enable including this file:
CFLAGS += -DPROJECT_CONF_H=\"project-conf.h\"
and enable the timesync in project-conf.h by adding this line
#define TIMESYNCH_CONF_ENABLED 1
Also, it looks like you're to build the example for the native (x86) platform. To build for a sensor node hardware platform, set the TARGET variable, e.g. run make TARGET=sky example-collect.
Related
In one of my projects weare using Robot Framework and a special listener to push results via XRAY to Jira.
Now, we want to call Robot Framework in two different modes named A or B, and different labels need to pushed via XRay to Jira.
I don't want to set some environment variables prior to call robot, as they are really hard to track.
What might be the easiest way to make a global variables of a Robot Framework run accessible in a Robot Framework listener.
I just want to call robot something like this:
robot --listener XRayListener.py --variable Mode:A
How, can I now access the variable Mode inside of XRayListener.py
As detailed in this article , from the listener python code you can use BuiltIn().get_variables() to obtain a given variable value.
from robot.libraries.BuiltIn import BuiltIn
ROBOT_LISTENER_API_VERSION = 2
def end_test(name, attributes):
print("BROWSER = '%s'" % BuiltIn().get_variables()['${BROWSER}'])
Then run it as:
robot --listener ShowVariable simple.robot
The robot file, just for mere reference was:
*** Settings ***
Library SeleniumLibrary
*** Variables ***
${URL} https://www.google.com/
${REMOTE_URL} http://192.168.56.1:4444/wd/hub
${BROWSER} Chrome
*** Test Cases ***
Confirm login popup is accessable
#Go To ${URL}
open browser ${URL} ${BROWSER}
set window size 350 800
[Teardown] Close Browser(base
I'm aware of similar questions here and here, however, the LLVM codebase changes so quickly I'm here to ask if the state of things have changed since then.
So, currently I'm trying to write an out-of-tree pass that works on the whole program CFG (hence the need for the merged bitcode). I would prefer to use the legacy PassManager as opposed to the Mixin-based NPM due to some other legacy passes my current pass relies on.
clang is called with these args:
clang -flto -Xclang -O0 -Xclang -load -Xclang ./mvxaa.so -fuse-ld=gold -o ./tests/target_app $(TARGET_SOURCES)
Will this register the pass as an LTO (full) pass? The pass never runs.
static void registerGlobalCollectionPass(const PassManagerBuilder &PB,
legacy::PassManagerBase &PM) {
PM.add(new CollectGlobals());
}
static RegisterStandardPasses
RegisterMyPass(PassManagerBuilder::EP_FullLinkTimeOptimizationEarly,
registerGlobalCollectionPass);
Looking deeper, it seems that PassManagerBuilder::addExtensionsToPM is called by the individual populateXPassManager functions and they will look through the GlobalExtensions list to call the respective callback functions. For other non-LTO ExtensionPointTy like EP_EnabledOnOptLevel0 there are entries, but when populateLTOPassManager is called, there are no longer any entries in the GlobalExtensions smallvector. Why is this the case?
Is it because LTO occurs at a later point after the linker runs and the -load argument given to dlopen the shared libraries only loads the shared objects at the compilation phase?
I have a robot file (calc_check.robot) in which each test case has separate documentation.
*** Settings ***
Documentation
... The test cases are designed to test the calculator .
Library ../../Library/AddNumbers
*** Test Cases ***
Calc_check_test Testcase01_a
[Documentation]
... Verify that two numbers are added or not
[Tags] add calculator
${addition}= Add numbers 10 20
Calc_check_test Testcase01_b
[Documentation]
... Verify that two numbers are added or not with negative sign
[Tags] add calculator
${addition}= Add numbers 10 -20
When i try to generate documentation for that robot file using the rst file (call_check.rst) i'm getting complete test case along with documentation as well, but i need only "[Documentation]" part only.
calc_check
======================================
.. robot-settings::
:source:/Users/sphinx/calc_check.robot
.. robot-tests::
:source:/Users/sphinx/calc_check.robot
I want documentation (i.e., only [Documentation] part of test case) from two test cases excluding the test case code.
Please tell me how to generate only the documentation part of it.
Robot provides documentation generation libraries called libdoc:
https://robot-framework.readthedocs.io/en/2.9.2/_modules/robot/libdoc.html
Problem is that it generates only for libraries and resources files (those without ***Testcase*** part).
If you need to generate docs from test suites, I would recommand to temporary change TestSuite into Resource file (change section to Keywords) and run libdoc for such file:
python -m robot.libdoc <path to res/lib> <list/show>
If I execute a binary in a clearcase view, and look at /proc/self/exe for that on Linux, I see something like the following:
$ cd /proc/19220
$ ls -l exe
lrwxrwxrwx 1 peeterj pdxdb2 0 2012-11-30 13:04 exe -> /home/peeterj/views/peeterj_clang-7.vws/.s/00024/8000028250b8f1d1llvm-config
The clang llvm-config program, not unreasonably, uses this output to try to figure out the absolute fully qualified path that it is located in (I assume in case argv[0] isn't fully qualified).
Is there a way to find the location within the view that this corresponds to. For example, in this case, the llvm-config exe is actually in:
/vbs/bldsupp/linuxamd64/clang/debug/bin
(I'm wondering if it's feasible to modify clang's GetExecutablePath() function to figure this out.)
No trivial solution here (for an old version of ClearCase though):
The technote "PK27447: WITHIN A CLEARCASE DYNAMIC VIEW, THE READLINK() CALL ON LINUX RETURNS THE WRONG PATH FOR THE EXECUTABLE'S /PROC/SELF/EXE VALUE" suggests:
Local fix
Use getcwd(), get_current_dir_name(), getwd() in applications slated for a VOB/View context
Create an interposer library to intercept the readlink() call, and modify to use any of the above calls to return the proper data
The cause:
/proc/self/exe returns the improper path while getcwd succeeds.
Unfortunately, for /proc/self/exe to return the proper value [from within a VOB/View context] would require a change within the Linux kernel to allow MVFS to "override" the present setting.
IBM LTC has been working on having the Linux community adopt this change so that we can then incorporate the new features within MVFS.
Related: Bug Sun 6189256.
I am using Android-sdk-ndk in an Eclipse+ADT environment. In Android-sdk Java development, I could use "Log.i", "Log.w", ... statements to output messages and variable contents to the "LogCat" window. However, in Android-ndk C/C++ development, is there any similar C/C++ "print-like" statement that outputs messages / variable contents from a JNI C/C++ module to the "LogCat" window so that I could have some debug informations for my program.
Thanks for any suggestion.
Lawrence
From this guide: http://www.srombauts.fr/2011/03/06/standalone-toolchain/
You can #define the logging methods like this:
#define LOGI(...) ((void)__android_log_print(ANDROID_LOG_INFO, "hello-ndk", __VA_ARGS__))
And you need to make sure you're linking to liblog by compiling similar to this (just add -l log):
arm-linux-androideabi-gcc hello-ndk.c -l log -o hello-ndk