I want to get Debug Information.
I implemented this code,but I can not get.
Please tell me how can I get Debug Infomation.
#[ink(message)]
fn set_test_data(&mut self, value: String) {
ink_core::env::println(value);
self.test_data.set(value);
}
Those error messages are printed to the console. Please note that you need to supply the following command line arguments to your node in order to make this happen:
--dev: Use the dev chain spec. You should already be using that.
-lruntime=debug: Increase the log level for runtime generated messages.
It's now in the ink_env crate:
ink_env::debug_println!("{}", "Hello log");
The FAQ entry on this is here:
https://paritytech.github.io/ink-docs/faq/#how-do-i-print-something-to-the-console-from-the-runtime
Related
I have written a basic program to send a UDS message in CAPL, But I don't know how to take the response inside the testcase function.
Below is the code snippet
includes
{
}
variables
{
message 0x639 read;
}
void maintest()
{
tc1();
}
testCase tc1()
{
read.dlc=0x08;
read.byte(0)=0X02;
read.byte(1)=0x10;
read.byte(2)=0x03;
output(read);
testStepPass("OK");
}
As mentioned in the previous comments, it is recommended to use the Diagnostic Features.
If you wish to use raw frames, then there is a function for waiting for the response message.
TestWaitForMessage(0x649,100);
TestGetWaitEventMsgData(res_msg);
The res_msg will be having the byte values of the response.
You can access it by res_msg.byte(0).
why don't you use diagnostic module from CANoe?
You can add your own diagnostic console under Diagnostics (or Diagnostics & XCP) tab -> Diagnostic/ISO TP and set up your own console (you need to configure things like target address, diagnostic layer etc.).
After that all the functions needed for CAPL you can find in help press F1 in CAPL Browser -> CAPL Functions -> Diagnostics CAPL Functions.
When working on Parity Substrate runtime development, how can I print out debug message for tracing and inspecting my variables?
Both of the above answers are correct in their own sense/time. Here's a more accurate overview:
runtime_io::print("..."); has been moved. You can now use the same function from sp-runtime::print(). These will be visible in a log target named runtime. So you'd have to do RUST_LOG=runtime=debug. You are still calling into sp_io under the hood though. Also, note that frame_support is re-exporting this for you. Most pallets need frame_support anyhow and this maeks the usage easier.
If you want to compile for wasm and native, and want prints only for native execution, use sp_std::if_std!{} macro.
Finally, you can use frame_support::debug module. This module provides wrappers around the above two to make the usage easier and more rust-like. Similar to a normal logger, you can use debug::native::warn!(...) etc.
A final useful tip is to: when possible, you can just bloat your code with println! and do SKIP_WASM_BUILD=1 cargo run [xxx]. This is helpful when you are developing and want quick debug prints without any of the setup explained above.
You can also use the if_std! macro included with sp-std:
https://github.com/paritytech/substrate/pull/2979
if_std! is a feature gate that should only be run when std feature is enabled.
Example
sp_std::if_std! {
// This code is only being compiled and executed when the `std` feature is enabled.
println!("Hello native world");
}
This is better because you can println variables and stuff rather than simply printing a string.
As a newcomer to Substrate development, the most direct way I found is with runtime_io::print().
Example:
use runtime_io::{ self };
decl_module! {
pub struct Module<T: Trait> for enum Call where origin: T::Origin {
fn deposit_event<T>() = default;
pub fn my_func(origin) -> Result {
runtime_io::print("Hello World");
Ok(());
}
}
}
The message will then appear in the console. Pay quick attention to it as it is constantly scrolling.
For a complete example, refer to the TCR tutorial example in github.
you can use the log crate, add it to your cargo.toml and use it like this:
log::info!("hello {}",substrate);
source : https://docs.substrate.io/test/debug/
Xcode UI Testing takes automatic screenshots for viewing in the results navigator whenever a test fails, which is greatly helpful. However, that does not include tests that fail because a predicate is failed. Since predicates are often for basic checks (such as if an element exists or not on a current view), that is a huge drawback because a screenshot would be useful in diagnosing what was happening in the app when the test failed.
Does anyone know how to force a screenshot? Does this require integrating the Fastlane Snapshot tool?
On tearDown you can check if test failed (that's helpful if you are not discarding screenshots when tests pass.)
if let failureCount = testRun?.failureCount, failureCount > 0 {
takeScreenshot()
}
If you are using Xcode 9 already, the takeScreenshot function can use the new API (If not, then use the workaround mentioned by the other answer) :
let screenshot = XCUIScreen.main.screenshot()
let attach = XCTAttachment(screenshot: screenshot)
add(attach)
You can also name the attach and change its lifetime ;)
See Apple's documentation for how to use and where to find them (the "Report navigator" in View > Navigators > Reports) in more detail.
You don't have to integrate Fastlane Snapshot for this. The only trick Snapshot is doing to force screenshot is triggering this code:
XCUIDevice.shared().orientation = .unknown
This will not alter UI as described on Snapshot documentation.
Unfortunately this will not work if you're using expectation for your predicate and you put this code into waitForExpectations(timeout:handler:) handler closure and I don't know why.
To workaround this you can create your own XCTestObservation handler like this:
class MockObserver: NSObject, XCTestObservation {
func testCase(_ testCase: XCTestCase, didFailWithDescription description: String, inFile filePath: String?, atLine lineNumber: UInt) {
XCUIDevice.shared().orientation = .unknown
}
}
XCTestObservationCenter.shared().addTestObserver(MockObserver())
You can put this code in either setUp() method or specific test... method.
The test output is a little weird as it will show "Set device orientation to Unknown" as an error and actual predicate error inside but you will have your screenshot:
You can override the recordFailure method to capture screenshots on any kinds of failures.
override func recordFailure(withDescription description: String, inFile filePath: String, atLine lineNumber: Int, expected: Bool) {
add(XCTAttachment(screenshot: XCUIScreen.main.screenshot()))
super.recordFailure(withDescription: description, inFile: filePath, atLine: lineNumber, expected: expected)
}
I want to do this:
test.FailNow("My Message")
but test.T.FailNow doesn't take a message. I am currently doing:
log.Println("Expected exception but got none")
test.FailNow()
Is there a better way?
See: http://golang.org/pkg/testing/#T.Fatal (and Fatalf)
The docs say: "Fatal is equivalent to Log() followed by FailNow()."
I build a little helping package as part of my Tideland Common Go Library (see http://code.google.com/p/tcgl/). The API doc can found at http://go.pkgdoc.org/code.google.com/p/tcgl/asserts.
An onFailure handler in webOS has an argument inError. I tried printing it using: console.log("error: " + inError);, but the result is only: error: [object Object]*** (app/assistants/main-assistant.js:26), which isn't much use. How can I log something more useful instead?
Update:
Ares generates: alarm1Failure: function(inSender, inError) {}. However, the error is contained as the errorText property of the first object and the second object is the request
I would use the interactive debugger at:
http://ares.palm.com/AresDebug/
Connect your device and run your app. Put your app name in the 'Script Filter' box and click get scripts.
Now use the 'Available Scripts' pull down to find your assembly.
You can set breakpoints (click on line numbers to the left) and inspect variables using the lower left pane and '>' prompt.
Be sure to use Chrome or Safari as it will not work with IE.
There is also a logger at:
http://ares.palm.com/AresLog/
if you don't want to use the debugger, then you probably should know something about the inError object getting returned to you. In this case I assume the onFailure comes from a Protocol function's callback, so try looking in the Protocol documentation to see what information the error object should contain.
Also for any logging purposes don't forget about the imensely useful function
JSON.stringify(obj)
It will take an object and return a JSON representation that you can log so you can see all the properties at once.