I'm trying to understand how to access and use the Bus system with custom S-Function Blocks. I built a very basic S-Function using the S-Function Builder which has no input and one Bus output. The Bus is a struct consisting only of one field of type double. This works just fine.
No I tried to connect its output to a newly created block (also with help of the S-Function Builder) which has one Bus input and no output. It should write the value of the only field inside the struct to the console using mexPrintf. But the value is always 0 (zero)
I set the output of the first block like that in the output wrapper function (works fine):
out0->data = 12;
and I try to get the input value inside the other block like this (prints always 0):
real_T insig = in0->data;
mexPrintf("Got a %d", insig);
Stupid error - I was using %d instead of %f for printing a double value...
Related
In a script I often call the function Rcplex(), which prints "CPLEX environment opened" and "Closed CPLEX environment" to the console. Since the function is called rather frequently, it prints this very often, which is quite annoying. Is there a way to suppress this? I tried sink(), suppressWarnings/Messages or invisible(catch.output()) but none of these did the trick. I proceeded to check the code of Rcplex() and found where the printing to the console happens. Rcplex() calls an underlying C-function (Rcplex.c). In the code of rcplex.c I located the commands which cause the printing:
REprintf("CPLEX environment opened\n");
REprintf("Closed CPLEX environment\n");
Is there a way to capture the output from REprintf() so that it does not get printed to the R-console? One way would obviously be to mess around with the Rcplex.c file and delete the corresponding lines. However, this would not be a very clean solution, which is why I'm asking for another way to capture the output from C-functions.
You had problems using sink() and capture.output() normally because sink() does not redirect output from REprintf, as we see in comments from the source code for REprintf:
/* =========
* Printing:
* =========
*
* All printing in R is done via the functions Rprintf and REprintf
* or their (v) versions Rvprintf and REvprintf.
* These routines work exactly like (v)printf(3). Rprintf writes to
* ``standard output''. It is redirected by the sink() function,
* and is suitable for ordinary output. REprintf writes to
* ``standard error'' and is useful for error messages and warnings.
* It is not redirected by sink().
However, we can use type = "message" to deal with this; from help("capture.output"):
Messages sent to stderr() (including those from message, warning and
stop) are captured by type = "message". Note that this can be "unsafe" and should only be used with care.
First I make a C++ function with the same behavior you're dealing with:
#include <Rcpp.h>
using namespace Rcpp;
// [[Rcpp::export]]
NumericVector example_function(NumericVector x) {
REprintf("CPLEX environment opened\n");
REprintf("Closed CPLEX environment\n");
// As mentioned by Dirk Eddelbuettel in the comments,
// Rcpp::Rcerr goes into the same REprintf() stream:
Rcerr << "Some more stuff\n";
return x;
}
If I call it from R normally, I get:
example_function(42)
CPLEX environment opened
Closed CPLEX environment
Some more stuff
[1] 42
However, I could instead do this:
invisible(capture.output(example_function(42), type = "message"))
[1] 42
And while the output is is printed to the console, the message is not.
Warning
I would be remiss if I didn't mention the warning from the help file I quoted above:
Note that this can be "unsafe" and should only be used with care.
The reason is that this will eliminate all output from actual errors as well. Consider the following:
> log("A")
Error in log("A") : non-numeric argument to mathematical function
> invisible(capture.output(log("A"), type = "message"))
>
You may or may not want to therefore send the captured output to a text file in case you have to diagnose something that went wrong. For example:
invisible(capture.output(log("A"), type = "message", file = "example.txt"))
Then I don't have to see the message in the console, but if I need to check example.txt afterward, the message is there:
Error in log("A") : non-numeric argument to mathematical function
I'm trying to print a double argument in a DTrace script from a user defined probe. The probe is defined as such:
/**
* Fired when the garbage collection threshold is changed with a certain factor
* #param factor the factor with which the GC threshold is changed
*/
probe gc__threshold(double factor);
In my script I'm trying to print the argument as follows:
pony$target:::gc-threshold
{
print(args[0]);
}
However it gives me the following error:
dtrace: failed to compile script ./test.d: line 7: translator for args[0] from double to double is not defined
I'm running the script on a Mac. Due to the lack of documentation and no similar problem around on the internet I'm having trouble finding leads on how to solve this problem.
I've also tried using floats and long doubles, but the same error occurs.
I'm writing my first ever C program in Ubuntu and it involves detecting when the AC adapter or Battery on my laptop see events (through udev_monitor). So far, I'm able to log to the console when the power situation changes using something like this while snippet:
while (1) {
dev = udev_monitor_receive_device(mon);
if (dev) {
printf("\n[INFO] Got Device\n");
printf(" [INFO] Device Name: %s\n", udev_device_get_sysname(dev));
...
And that's great! When I plug or unplug my laptop I get that logged to the console. However, what I'm failing to grok is how to conditionally test using these same functions.
For instance, this is never true:
if (udev_device_get_sysname(dev) == "ADP1") { ... }
I'm unsure how to properly test this. Obviously it prints as a string (array of characters?) when printf() and %s are used.
EDIT: The values logged to the consle from the function called are ADP1 for the adapter and BAT0 for the battery - which correlates to their entries in the /sys/class/ directory.
In C you compare strings using one of the string comparison routines, such as strcmp or strncmp. If you compare them using == you're only comparing the values of the pointers, which will not be the same.
So for the code checking the sysname is incorrect, as the pointer comparison will never be true. It should be changed to something like:
if (strcmp(udev_device_get_sysname(dev), "ADP1") == 0) { … }
which causes it to compare the strings, rather than the pointer values.
I'm trying to send midi messages from some Julia code I've written, but I'm having trouble with the midiOutOpen function. I'm following this tutorial here, but the output I'm getting from the function doesn't make sense.
This is my Julia code:
const CALLBACK_NULL = uint32(0x00000001)
function openoutputdevice(id::Uint32)
handle = uint32(0)
err = ccall((:midiOutOpen, :Winmm), stdcall,
Uint32,
(Ptr{Uint32}, Uint32, Ptr{Uint32}, Ptr{Uint32}, Uint32),
&handle, id, C_NULL, C_NULL, CALLBACK_NULL)
println(hex(err))
handle
end
The handle is always 0, and the error that's being returned is "10". I've grepped through the Windows header files, and this doesn't seem to match up with any of the errors that can be expected from the function (see here), so I'm more inclined to think that I'm mapping the wrong Julia data types in the ccall. It's been a long time since I've done anything C-related, so I'm hoping there's something obviously wrong with this. The only odd thing I've seen is that CALLBACK_NULL is defined in mmsyscom.h as 0x000000001 - a 9 digit hex number, even though the function doc specifies a DWORD for the final parameter to midiOutOpen.
Any ideas?
The error is MMSYSERR_INVALFLAG because CALLBACK_NULL is defined as:
#define CALLBACK_NULL 0x00000000l
That is a lowercase-letter-"L" at the end, not the number 1 (one). The call succeeds when this value is corrected.
Is there any way how can I get a list of breakpoints from within Windows Debugger Extension?
I'm using plain C (and I'm trying to avoid using COM interface they provide and I'm not even sure if that COM interface provides a way to do that).
I've read and researched wdbgexts.h and dbghelp.h but neither of them seem to contain any usable function or global variable, although there are some info on BPs in those files, such as DBGKD_GET_VERSION::BreakpointWithStatus.
Use IDebugControl::GetNumberBreakpoints, then IDebugControl::GetBreakpointByIndex.
Windows Debugger Extension provides function ULONG64 GetExpression(PCSTR lpExpression) (of course it's <sarcasm>well documented</sarcasm>)
#define GetExpression (ExtensionApis.lpGetExpressionRoutine)
which allows you to get results from any WinDBG expression like ?? #eip.
GetExpression( "#eip"); // Without `?? ` in the beginning
Next, if you take a look at:
Windows Debugger Help » Debugging Tools For Windows » Debuggers » Debugger References » Debugger Commands » Syntax Rules » Pseudo-Registers Syntax
You will find a line what looks like this:
$bpNumber - The address of the corresponding breakpoint. For example,
$bp3 (or $bp03) refers to the breakpoint whose breakpoint ID is 3.
Number is always a decimal number. If no breakpoint has an ID of
Number, $bpNumber evaluates to zero. For more information about
breakpoints, see Using Breakpoints.
So with some overhead you'll get this (working) solution:
#define MAX_BREAKPOINTS 100
DWORD i, addr;
CHAR buffer[] = "$bp\0\0\0\0\0\0\0\0\0\0\0\0";
for( i = 0; i < MAX_BREAKPOINTS; ++i){
// Appends string to BP prefix
itoa( i, buffer+3, 10);
addr = GetExpression( buffer);
if( !addr){
break;
}
// Do stuff
}
The only another solution is to use COM objects as Steve Johnson suggested.