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.
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
We are analyzing sequencing data while filtering and trimming fastq files encountered following error. Is the following error due to unavailability of core for processing commands?
Error in colnames<-(*tmp*, value = c("cs103_R1_dada.fastq", "cs110_R1_dada.fastq", : attempt to set 'colnames' on an object with less than two dimensions In addition: Warning message: In mclapply(seq_len(n), do_one, mc.preschedule = mc.preschedule, : all scheduled cores encountered errors in user code >
As pengchy suggested there may be something wrong with function.
try the same call by using lapply and error message will be more informative.
To clarify on what #f2003596 and #HelloWorld said: This just means that a crash occurred within the function you called, i.e. while it was executing that function. But this does not necessarily mean that your function is incorrect. For example, you get the same error when a variable has not been found.
That would mean your R function has a crash.
Note: If you include an unexpected argument in mclapply you also can get this error message. I put mC.cores instead of mc.cores by mistake and I got it.
I am trying to determine how fio (github.com/axboe/fio) determines if there is a write error when using the libaio ioengine.
From the post at linux kernel aio functionality, I see an example of error checking in the callback function, work_done(), which examines the events returned by io_getevents().
But I cannot find any similar error checking in the fio_libaio_getevents() function from libaio.c (https://github.com/axboe/fio/blob/master/engines/libaio.c#L145).
I have written to the mailing list (fio#vger.kernel.org) from https://github.com/axboe/fio/blob/fio-2.17/README#L77, but the mail bounces. So any help would be much appreciated.
Thanks in advance.
The errors are returned as res and res2 in struct iocb. In that fio code, you can see the iocb array passed in here, as ld->aio_events + events.
r = io_getevents(ld->aio_ctx, actual_min,
max, ld->aio_events + events, lt);
The actual error is checked earlier in the file, in the function fio_libaio_event.
my software is a Web Crawler,when I get the body from the http response, it cracks.
resp->body = Malloc(content_len);
memcpy(resp->body, body_start, content_len); //THIS IS THE FAULTY LINE
Malloc is a wrapper function of malloc,so resp->body is not NULL, and content_len is the length of memory area begin with body_start,but its content is "PK\003\004\024", "\003" is ETX(end of text), "\004" is EOT(end of transmission),"\024" is device control 4,I really don't know what 's the meaning of these strange chracters,why does it crack?
The body is ZIP encoded, from the ZIP wikipedia page;
Magic number
none, though PK\003\004, PK\005\006 (empty archive), or PK\007\008 (spanned archive) are common.
You'll need to check the header and unzip the body before reading it.
As for the segmentation fault, any of the 3 parameters to memcpy could be the culprit, code showing their initialisation is required to spot the exact problem. If you're using any of the string functions (strlen/strcpy) on the body in a non shown part of the code, they're likely to break with binary input like this.
I am trying to write an interface between RSPEC (ruby flavoured BDD) and a Windows application. The application itself is written in an obscure language, but it has a C API to provide access. I've gone with Ruby/DL but am having difficulties getting even the most basic call to a DLL method to work. Here is what I have so far, in a file called gt4r.rb:
require 'dl/import'
module Gt4r
extend DL::Importable
dlload 'c:\\gtdev\\r321\\bin\\gtvapi'
# GTD initialization/termination functions
extern 'int GTD_init(char *[], char *, char *)'
extern 'int GTD_initialize(char *, char *, char *)'
extern 'int GTD_done(void)'
extern 'int GTD_get_error_message(int, char **)'
end
My reading so far suggests that this is all I need to get going, so I wrote up a RSPEC example:
require 'gt4r'
##test_environment = "INCLUDE=C:\\graphtalk\\env\\aiadev\\config\\aiadev.ini"
##normal_user = "BMCHARGUE"
describe Gt4r do
it 'initializes' do
rv = Gt4r.gTD_initialize ##normal_user, ##normal_user, ##test_environment
rv.should == 0
end
end
And when run...
C:\code\GraphTalk>spec -fs -rgt4r gt4r_spec.rb
Gt4r
- initializes (FAILED - 1)
1)
'Gt4r initializes' FAILED
expected: 0,
got: 13 (using ==)
./gt4r_spec.rb:9:
Finished in 0.031 seconds
1 example, 1 failure
The return value (13) is an actual return code, meaning an error, but when I try to add the gTD_get_error_message call to my RSPEC, I can't get the parameters to work.
Am I heading in the right direction and can anyone point to the next thing I can try?
Thanks,
Brett
A follow up to this question, showing the part that fails when I try to get the error message from my target library:
require 'gt4r'
##test_environment = "INCLUDE=C:\\graphtalk\\env\\aiadev\\config\\aiadev.ini"
##normal_user = "BMCHARGUE"
describe Gt4r do
it 'initializes' do
rv = Gt4r.gTD_initialize ##normal_user, ##normal_user, ##test_environment
Gt4r.gTD_get_error_message rv, #msg
#msg.should == ""
rv.should == 0
end
end
I expect the error message to be returned in #msg, but when run I get the following:
Gt4r
(eval):5: [BUG] Segmentation fault
ruby 1.8.6 (2008-08-11) [i386-mswin32]
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
And this if I use a symbol (:msg) instead:
C:\code\GraphTalk\gt4r_dl>spec -fs -rgt4r gt4r_spec.rb
Gt4r
- initializes (ERROR - 1)
1)
NoMethodError in 'Gt4r initializes'
undefined method `to_ptr' for :msg:Symbol
(eval):5:in `call'
(eval):5:in `gTD_get_error_message'
./gt4r_spec.rb:9:
Finished in 0.046 seconds
1 example, 1 failure
Clearly I am missing something about passing parameters between ruby and C, but what?
The general consensus is you want to avoid DL as much as possible. The (english) documentation is quite sketchy and the interface is difficult to use for anything but trivial examples.
Ruby native C interface is MUCH easier to program against. Or you could use FFI, which fills a similiar niche to DL, originally comes from the rubinius project and has recently been ported to "normal" ruby. It has a nicer interface and is much less painful to use:
http://blog.headius.com/2008/10/ffi-for-ruby-now-available.html
The return value (13) is an actual
return code, meaning an error, but
when I try to add the
gTD_get_error_message call to my
RSPEC, I can't get the parameters to
work.
It might help posting the error instead of the code that worked :)
Basically, once you start having to deal with pointers as in (int, char **), things get ugly.
You need to allocate the data pointer for msg to be written to, since otherise C will have nowhere to write the error messages. Use DL.mallo.