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.
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 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.
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.
In my CRC8.c I have this function:
BOOL isCRCValid(const UINT8 *ptr, UINT8 Len, UINT8 CRCChar){
return CRCChar == generateCRC(ptr, Len); //generareCRC returns a UINT8
}
It's is declared in CRC8.h, but PC Lint returns me the following.
Info 714: Symbol 'isCRCValid(const unsigned char *, unsigned char, unsigned
char)' not referenced
Info 830: Location cited in prior message
Help says 714 is:
714: Symbol 'Symbol' (Location) not referenced -- The named external
variable or external function was defined but not referenced. This
message is suppressed for unit checkout (-u option).
and 830 is:
830 Location cited in prior message -- Message 830 is a vehicle to
convey in 'canonical form' the location information embedded within
some other message. For example, consider the (somewhat simplified)
message:
file x.c line 37: Declaration for 'x' conflicts with line 22
This contains the location ("line 22") embedded in the text of the
message. Embedded location information is not normally understood by
editors and IDE's (Interactive Development Environments) which can
only position to the nominal location (line 37 in this example). By
adding this additional message with the nominal location of line 22
the user can, by stepping to the next message and, in this case, see
what the 'conflict' is all about. This message and message 831 below
do not follow the ordinary rules for message suppression. If they did
then when the option -w2 was employed to turn the warning level down
to 2 these messages (at level 3) would also vanish. Instead they
continue to function as expected. To inhibit them you need to
explicitly turn them off using one of:
-e830
-e831
They may be restored via +e830 and +e831; they state of suppression
can be saved and restored via the -save -restore options. Options such
as -e8* and -e{831} will have no effect.
As I'm newbie with PC Lint, and relative newbie with C, I'm not achieving resolving this problem.
Can anyone help me with this problem?
The message simply means that PCLint didn't find anything that actually uses this function, so it could be dead code/candidate for removal.
It could also mean that you did not use the input arguments in your function.
I am using VC++ 2008 express edition for C. When I try to run this:
/* Demonstrates printer output. */
#include <stdio.h>
main()
{
float f = 2.0134;
fprintf(stdprn, "This message is printed.\n\n");
fprintf(stdprn, "And now some numbers:\n\n");
fprintf(stdprn, "The square of %f is %f.", f, f*f);
/* Send a form feed */
fprintf(stdprn, "\f");
}
I get four of these errors: error C2065: 'stdprn' : undeclared identifier.
On this forum, they wrote that it works to define the printer as follows:
FILE *printer;
printer = fopen("PRN", "w");
EDIT
It builds with a warning that fopen is unsafe. When it runs the error appears:
Debug Assertion fails.
File: f:\dd\vctools\crt_bld\self_x86\crt\src\fprintf.c
Line: 55
Expression: (str != NULL)
The stdprn stream was an extension provided by Borland compilers - as far as I know, MS have never supported it. Regarding the use of fopen to open the printer device, I don't think this will work with any recent versions of Windows, but a couple of things to try:
use PRN: as the name instead of PRN (note the colon)
try opening the specific device using (for example) LPT1: (once again, note the colon). This will of course not work if you don't have a printer attached.
don't depend on a printer dialog coming up - you are not really using the WIndows printing system when you take this approach (and so it probably won't solve your problem, but is worth a try).
I do not have a printer attached, but I do have the Microsoft XPS document writer installed, s it shoulod at least bring up the standard Windows Print dialog from which one can choose the printer.
No. It wouldn't bring up a dialogue. This is because you are flushing data out to a file. And not going through the circuitous Win32 API.
The print doesn't work because the data is not proper PDL -- something that the printer could understand. For the print to work fine, you need to push in a PDL file, with language specific constructs. This varies from printer to printer, a PS printer will need you to push in a PostScript snippet, a PCL -- a PCL command-set and in case of MXDW you will have to write up XML based page description markup and create a zip file (with all resources embedded in it) i.e. an XPS file to get proper printout.
The PDL constructs are important because otherwise the printer doesn't know where to put the data, which color to print it on, what orientation to use, how many copies to print and so on and so forth.
Edit: I am curious why you are doing this. I understand portability is probably something you are trying to address. But apart from that, I'd like to know, there may be better alternatives available. Win32 Print Subsytem APIs are something that you ought to lookup if you are trying to print programmatically on Windows with any degree of fidelity.
Edit#2:
EDIT It builds with a warning that fopen is unsafe.
This is because MS suggests you use the safer versions nowadays fopen_s . See Security Enhancements in the CRT.
When it runs the error appears:
Debug Assertion fails. File: f:\dd\vctools\crt_bld\self_x86\crt\src\fprintf.c Line: 55
Expression: (str != NULL)
This is because fopen (whose return value you do not check) returns a NULL pointer. The file open failed. Also, if it did succeed a matching fclose call is called for.
There's no such thing as stdprn in ANSI C, it was a nonstandard extension provided by some compilers many years ago.
Today to print you have to use the specific APIs provided on your platform; to print on Windows you have to use the printing APIs to manage the printing of the document and obtain a DC to the printer and the GDI APIs to perform the actual drawing on the DC.
On UNIX-like OSes, instead, usually CUPS is used.
You can substitute the printer using this command with net use, see here on the MSDN kb
NET USE LPT1 \\server_name\printer_name
There is an excellent chapter on printing in DOS using the BIOS, ok, its a bit antiquated but interesting to read purely for nostalgic sake.
Onto your problem, you may need to use CreateFile to open the LPT1 port, see here for an example, I have it duplicated it here, for your benefit.
HANDLE hFile;
hFile = CreateFile("LPT1", GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);
if (hFile == INVALID_HANDLE_VALUE)
{
// handle error
}
OVERLAPPED ov = {};
ov.hEvent = CreateEvent(0, false, false, 0);
char szData[] = "1234567890";
DWORD p;
if (!WriteFile(hFile,szData, 10, &p, &ov))
{
if (GetLastError() != ERROR_IO_PENDING)
{
// handle error
}
}
// Wait for write op to complete (maximum 3 second)
DWORD dwWait = WaitForSingleObject(ov.hEvent, 3000);
if (dwWait == WAIT_TIMEOUT)
{
// it took more than 3 seconds
} else if (dwWait == WAIT_OBJECT_0)
{
// the write op completed,
// call GetOverlappedResult(...)
}
CloseHandle(ov.hEvent);
CloseHandle(hFile);
But if you insist on opening the LPT1 port directly, error checking is omitted...
FILE *prn = fopen("lpt1", "w");
fprintf(prn, "Hello World\n\f");
fclose(prn);
Hope this helps,
Best regards,
Tom.