I tried this example for opening an adapter and capturing packets:
https://www.winpcap.org/docs/docs_412/html/group__wpcap__tut3.html
It prints the adapter list but after that pcap_open does not
return and locks Matlab. I have to quit and restart Matlab to continue.
If I do not pass the correct devicename to pcap_open but
something like "dummy", I get the correct error message.
Windump and WireShark function perfectly, so the installed WinPcap 4.1.3
is o.k.
I use Microsoft Windows SDK 7.1 (C) on Windows 10 and compile
in Matlab with:
mex -I.\WinPcap_developers_pack\Include .\WinPcap_developers_pack\Lib\x64\wpcap.lib ReadPackets.c
The defines and includes are:
#define WIN32 // otherwise the Unix branch is selected in pcap.h
#define HAVE_REMOTE // needed according to Q-23 of the WinPcap FAQ
#include "mex.h" // needed for Matlab
#include "pcap.h" // straight from this WinPcap example
Any ideas?
It only seemed like pcap_open did not return. Everything worked fine - invisibly. The cause was that stdout is buffered heavily so print statements for debugging did print only at the program's end.
The next statement was eventually used to flush and reveal what was going on:
mexEvalString("pause(0.01);");
The standard fflush and _flushall have no effect in mex-files.
Related
I would like to turn a led (character device) of an embedded linux board (BeagleBone Black) on and off with a script written in D.
Via the command line a led can be turned on and off (e.g. for led "USER LEDS D2 0") with:
cd /sys/class/leds/beaglebone:green:usr0
echo none > trigger
echo 1 > brightness
echo 0 > brightness
(echo none > trigger disables the default "heartbeat" flashing)
In the D Cookbook on page 93 I found info about how to make linux system calls via the C interface like follows:
void main(){
import core.sys.posix.unistd; // analogous to #include <unistd.h>
string hello = "Hello, world!";
write(1 /*stdout file descriptor*/, hello.ptr, hello.length);
}
Is that a suitable way to access a character device or are there better alternatives?
The unistd calls are indeed the correct way to do it. A character device in Linux is a special kind of file and is accessed the same way: you open it by path, then read or write to it, and close it when finished.
Note that open is actually inside core.sys.posix.fcntl, while read is in core.sys.posix.unistd.
You could also use std.file.write() from the D standard library to be a bit shorter. There's also chdir in there. So your shell example would literally become:
import std.file;
chdir("/sys/class/leds/beaglebone:green:usr0");
std.file.write("trigger", "none"); // write "filename", "data string"
std.file.write("brightness", "1");
std.file.write("brightness", "0");
You don't strictly have to use std.file.write as the full name with the import, I just like to since write is such a common word it clears up which one we mean.
Anyway, this function just wraps up the unistd calls for you: it opens, writes the string, and closes all in one (just like the shell echo!).
One small difference is shell echo sticks a \n at the end of the string. I didn't do that here. If the code doesn't work, try "1\n" and such instead, maybe the device requires that. But I doubt it.
But the std.file.write vs the core.sys.posix.unistd.write aren't that much different. The former is more convenient, the latter gives more precise control over it.
I'm having a small difficulty with Fortran 90 and Eclipse. I installed the "Photran" plugin to Eclipse, and have managed to compile everything perfect, and overall the program does what it has to do. The problem comes when displaying text in the Eclipse console. The code it self not that important, since it does what it has to do, but more the output generation.
The piece of the code I'm having trouble with is the following:
subroutine main_program
write(*,*) "Program begins!"
<Program that takes ~5mins to run>
write(*,*) "Program ends!"
end subroutine main_program
Specifically, the problem is that in the console, the first message should be shown immediately, "Program begins!", and after ~5 minutes it should show "Program ends!". It happens that both of these messages get displayed only after the program is done running, not while the programs is executing.
I have used:
subroutine main_program
print*, "Program begins!"
<Program that takes ~5mins to run>
print*, "Program ends!"
end subroutine main_program
but it keeps on doing the same thing. I saw a "similar" post earlier (can't find the link though, sorry about that) but it was not really what I was looking for.
OK, here's the answer. Insert the statement
flush 6
after the first write statement to have its output sent immediately to the console. Insert it anywhere else you wish once you understand what it is doing.
It is obvious (to me) from the situation OP describes that the output is being buffered, that is the program issues a write statement and passes the output off to the operating system which does as it damn well pleases -- here it waits until the program ends before writing anything to the console. I guess that its buffering capabilities have some limits and if the program exceeded them the o/s would empty its buffers prior to program end.
Fortran now (since 2003 I think) provides a standard way of telling the o/s to actually flush the buffer to the output device -- the flush statement. In its simplest form flush takes only one argument, the unit number of the output channel to be flushed. I guessed that OP had unit 6 connected to stdout (aka *), since this is a near-universal default configuration, though not one guaranteed by the Fortran language standard.
I don't think that flush * is correct.
If you have a pre-2003 compiler then (a) for Backus' sake update and (b) it is likely that it supports a non-standard way to flush buffers; if memory serves gfortran used to provide a subroutine which would be called something like call flush(6).
There are other ways, outside Fortran, to tell the o/s to write to disk (or console or what have you) immediately. Look at the documentation for your o/s if you are interested in them.
I have a custom nagios plugin which is written in Perl. For complicated political reasons I am required to hide the source code of this plugin. The only way I found to do this was by using perlc (http://marginalhacks.com/Hacks/perlc).
In the words of author:
"Takes a single perl script, converts the block using a simple encoding with an optionally defined key. The script is decoded at runtime and fed to the perl library, to avoid it getting in the hands of the user."
The problem I am getting is that Nagios shows "No output returned from plugin" when I used the compiled version of the plugin. The raw perl source works just fine.
After debugging for a while I narrowed the problem down to using exit in perl. I.e
This works fine when compiled.
print "OK: Everything is working fine.\n";
This however does not work and results in ""No output returned from plugin"
print "OK: Everything is working fine.\n";
exit 1;
It doesn't matter how I exit (0 1 2 or 3) I still get the same problem.
According to the cross-posted PerlMonks thread, the issue was resolved by enabling autoflushing:
$| = 1;
From perlvar:
HANDLE->autoflush( EXPR )
$OUTPUT_AUTOFLUSH
$|
If set to nonzero, forces a flush right away and after every write or
print on the currently selected output channel. Default is 0
(regardless of whether the channel is really buffered by the system or
not; $| tells you only whether you've asked Perl explicitly to flush
after each write). STDOUT will typically be line buffered if output is
to the terminal and block buffered otherwise. Setting this variable is
useful primarily when you are outputting to a pipe or socket, such as
when you are running a Perl program under rsh and want to see the
output as it's happening.
See the article Suffering from Buffering? for more details.
Question
I am an Emacs novice and would like to try the newer MI interface for gdb integration as provided by gdb-mi.el. Based on what I've read, this is now the default that gets used when executing M-x gdb, so I'd hoped that everything would work out of the box.
I'm working on Ubuntu 10.04 LTS.
Using the default gdb-mi.el, I don't seem to get messages related to segfaults (or other reasons for the debugged program stopping) printed to the GUD interface. Using the latest gdb-mi.el, I get the messages, but no command prompt to indicate when commands have finished executing.
So my question is whether there is revision of gdb-mi.el (and related files) that an emacs novice can use to get things running reliably. Similar questions have been asked before, e.g. gud-gdb emacs 24 not working and
Getting gdb to work with emacs 24. It looks like the advice there is to revert back to older GDB interfaces (gdb-ui.el), but I'd really like to get the MI based interface working.
The rest of the question text contains some background information on what I've tried thus far in the hopes that it may help other novices stumbling around in the dark.
I have virtually no experience using Emacs lisp, so I'm probably biting off more than I can chew, but would be more than happy to hack around a bit if anyone is willing to offer advice on where to start.
Things I've tried thus far
In order to get things working, I've been using a simple little program to induce a segmentation fault so I have something to debug.
#include <cstdio>
#include <cstring>
void doCrash()
{
memset(0x0,1,1);
}
int main (int argc, const char ** argv)
{
printf("hello\n");
doCrash();
printf("bye\n");
}
I compiled this using 'g++ -g main.cpp', so I've got debug info for gdb to use.
I then launch gdb via emacs using 'M-x gdb' (and run it like this: 'gdb -i=mi a.out'), and then do 'M-x gdb-many-windows' to get a nice multi-window layout.
Issue #1: No notification of hitting segfaults, breakpoints, etc.
Using the default gdb-mi.el file, when I run the program, there is no message to indicate a segfault occurred.
(gdb) r
Starting program: /tmp/a.out
(gdb) c
Continuing.
(gdb)
There is a hint as to what happened in the 'Threads' buffer window, but that's won't be useful when debugging larger programs in anger:
1 process 31800 stopped in main (argc=1,argv=0x7fffffffe3c8) of main.cpp:11
Issue #2: No command prompt
Upgrading gdb-mi.el to the latest version from github (which I knew in advance was unlikely to work perfectly as it probably relies on other lisp modules), the prompt goes missing very soon after running gdb, but I do get messages on segfaults and the like:
(gdb) r <--- I still have a prompt here
Starting program: /tmp/a.out
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff732efd9 in memset () from /lib/libc.so.6
bt <--- No prompt anymore, but gdb commands work
bt
#0 0x00007ffff732efd9 in memset () from /lib/libc.so.6
#1 0x000000000040066c in doCrash () at main.cpp:6
#2 0x000000000040068c in main (argc=1, argv=0x7fffffffe3c8) at main.cpp:12
The lack of prompt may not seem like a big thing, but it's obviously less than ideal having no indication of when gdb & emacs has finished processing something and is ready for new input.
I have a large project that has many changes not yet checked in. I want to check them in but have them only take effect when a certain symbol is #define'd
CVS does have the ability to format diffs with #ifdef's inserted using the --ifdef argument. However, this does not merge the #ifdef's back into my working file. Even worse, the output includes some ugly header stuff that would need to be removed.
Index: path/to/my/file.h,v
===================================================================
RCS file: /path/to/my/file.h,v
retrieving revision 1.17
diff --ifdef=TEST -r1.17 file.h
Does anyone have a script that would automate the process of doing the CVS diff, removing the header stuff and copying the result back over the working file?
Great thanks if anyone can help.
I'm not sure I understand what you are wanting to do, so I will answer a slightly modified question in case it makes your current problem obsolete.
Generally, #ifdef are only enabled if set at compile time. Even if they are checked out or checked in, the code within the macro will not be included unless a compile time symbol is available. For example:
#ifdef DEBUG
cerr << "Some debug statement" << endl;
#endif
Unless you set a -DDEBUG option (in GCC, see your compiler's documenation) or #define DEBUG 1 somewhere else in your code (that is available to the #ifdef), the debug statement above will not be compiled into the resulting binary.
That being said, heavy use of #ifdef can quickly become a maintanence blackhole and make it more difficult for your code to be portable. I would recommend against such a strategy.