I have written a console application in D programming language. It executes some process and reads from its stdout (I use ProcessPipes):
foreach (line; pipes.stdout.byLine)
{
writeln(line);
}
I'd like to detect a 10 seconds timeout (no new lines received). What approach should I use?
I would probably use select if your are on a unix box and WaitForSingleObject on Windows to check for available input on the stdin handle, specifying a timeout value. The return value of the calls will tell you if input was available or if it actually timed out.
It might not work right with the buffering that byLine (and underneath that, FILE*) does inside... but it might, I'd say try it first. Just put the call to select/WaitForSingleObject at the end of the loop and see if it fails when it isn't supposed to.
But to be really sure, you can use the lower-level read functions on the input yourself, and break it into lines yourself (or better yet, avoid breaking it into lines if you don't really have to and just use random sized blocks of data as returned from the lower level read functions). Then there will be no weird buffering that the wait functions don't know about, so all will work brilliantly.
You can find examples for these functions from C easily like the official docs https://learn.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-waitforsingleobject or random stack overflow questions with relevant examples How to use select to read input from stdin?
just in D it is import core.sys.posix.unistd; or import core.sys.windows.windows; instead of the C #include<unistd.h> etc.
Related
I'm working with gnuradio 3.10.4 and usrp B200mini.
My flowgraph is very simple:
usrp source -> head block -> file sink
I want to store a fixed amount of data to file sink, then reconfigure usrp and start it to store again.
My Python program likes:
tb.start()
tb.wait()
tb.lock()
...reconfigure usrp...
tb.unlock()
tb.start()
...
But the second time when tb.start() is used, the file can be created successfully but no data is written to it.
Can anyone tell me what's wrong with the program or provide any relevant docmutation becaouse I find little about it.
Thanks for your support.
When you're not sure how to get a block to do what you want, or if it can, it can be useful to consult the source code of the block, because GNU Radio blocks are not always thoroughly documented.
Starting from this wiki page on Head we can see all the code. It's C++, but fairly simple, and you can ignore all the setup and just look at the lines that seem to be doing the work.
In head_impl::work in head_impl.cc, we can see that the way the block works is counting the number of items it has passed in d_ncopied_items and comparing that against d_nitems (the value you provided). There's nothing here that restarts the count.
We have to also check the header file, head_impl.h, because code may be there too. And there we find what you need:
void reset() override { d_ncopied_items = 0; }
So, call reset() on the head block and it will forget about how many items it has already copied.
I have an input to a Threshold block, which I have verified is working with a QT GUI number sink.
I want to print the output of the Threshold block to console, preferably using the Message Debug block.
However, the output of the Threshold block is a float stream, which doesn't match the input of the Message Debug block.
Is there a way to convert a float stream into message, or am I going down the wrong hole?
My general aim is: when the input exceeds a certain threshold, print to console. Another program will monitor the console and when there is a print out, this triggers another action. I'm also not sure how to output ONLY when the threshold is exceeded, but one problem at a time.
I'm also not sure how to output ONLY when the threshold is exceeded, but one problem at a time.
Yes, but that problem is a blocker: Std output is a shared thing across all things in the GNU Radio process, so you can't generally guarantee exclusivity.
Let's not go down that route!
Instead, use something designed for exactly for this kind of things decades ago in UNIX!
Named pipes. These are FIFOs that you can handle like files.
So, use a file source to write to a FIFO, and pipe that FIFO into your other program.
It's really simple:
mkfifo /path/to/where/you/want/to/named/pipe
add a file sink that writes to /path/to/where/you/want/to/named/pipe
either make your other software open that /path/to/where/you/want/to/named/pipe, or do something like other_program < /path/to/where/you/want/to/named/pipe (that actually makes the standard (==console-equivalent) input of your other program what you write to that file sink)
I am working on TI-TM4C129X ARM board and trying to write a LOG mechanism.It works good when I call it from the Tasks although I faced a problem when I called it with a timer.As I understand that, printf like functions works with Hwi and this causes the error. My aim is to format strings together with the operations like sprintf(),vsprintf(),memcpy() and memset(). How can I solve this problem ? Is there any equivalent methods that success sprintf() operation ?
Thanks for your answers,
Best Regards.
It sounds like the printf is the problem, not sprintf. Assuming your Log message uses an interrupt (UARTs do), and your timer is called from an interrupt, then your options are limited.
I would set a flag in the timer that your task code can check, once outside the context of the timer. This flag could indicate one of several messages to print, even include a time stamp if that helps to resort things afterwards, since your printed messages will not be in order.
Or, with SWO output (like the Segger j-link), you should be able to just send the data. But to avoid scrambled sentences, you need to halt interrupts while sending out a debug message, which obviously can affect the real-time behavior.
I encountered a problem while working with the TextIO structure,
because every input waites for a newline chacter and for the buffer to be full...
How can i work with BinIO and stdIn to solve that problem?
Any helpfull input is appreciated.
BTW: I am using MLTton so there is nothing more than the usual standard libs.
As a last resort, you could write it yourself in C, and then call it from SML using the foreign function interface. You can find out more info about MLton's FFI here: http://mlton.org/ForeignFunctionInterface
I encountered a problem while working with the TextIO structure, because every input waites for a newline chacter and for the buffer to be full... How can i work with BinIO and stdIn to solve that problem?
BinIO, like TextIO, implements buffered I/O. (They both implement the IMPERATIVE_IO signature.) For unbuffered I/O, you need to go "down" a level in abstraction, and use an implementation of PRIMITIVE_IO or POSIX_IO.
Specifically, Posix.IO.readVec lets you read unbufferedly from a file descriptor. (In the case of standard input, the file descriptor is Posix.FileSys.stdin.)
However, if your standard input is from the console (as opposed to being redirected from a file, or taken from a pipe, or whatnot), then there's a very good chance that the console only provides input to MLton after the user hits Enter. Using Posix.IO will bypass the line-buffering functionality that MLton provides, but if you also need to bypass your console's line buffering, then you'll likely need to use special C libraries (specific to your operating system), with the foreign function interface that Matt mentions in his answer.
My work is to write a value which will be sent by arduino to processing IDE and processing IDE must write it into a specified text file.
I used This as reference and tried a code. But, nothing is written into the specified file.
Can anyone suggest me some solution?
First off: no you don't. The Processing IDE doesn't do anything, a processing program you write will listen and write. The PDE is just a glorified text editor =)
That said, if you can get your signal into your plain processing application, then you can write that data to a file using the standard file writing functions, see http://processing.org/reference/createWriter_.html for these.
If you can't get your data into your processing application, that's a very different problem, and there are a number of SO questions that already cover this topic (you will find them with a normal search).