I insist on using lex and not the flex.
am developing an API in lex like the one existing in the flex util ( yy_switch_buffer, yy_create_buffer ...) offering the possibility to switch between multiple buffers .
This is the main difficulty for me until now :
for example when I encounter a #include token i should switch the buffer to the included file. So first i should interrupt the current parsing action( I tried fclose(yyin) FAILED) the parser complete the whole current yyin. NOT good because I should parse the included file to store structures (for example ) used in the main file.
Question is : How can I interrupt immediately a parser ? Is it enough for me to define a new buffer using yyin = fopen(somefile, "r"); ??
It is going to be tough to handle it, if it is doable at all. AFAIK, Lex only allows you to switch input streams on EOF (real or simulated) when it calls yywrap().
Maybe you can fake things so that when you find the 'include' directive, you fake an EOF on the current stream and then have yywrap() fix things so that the new input comes from the included file, and then when you reach EOF on the included file, you have yywrap() restore input from the original input stream at the original position. Clearly, this works for nested includes (if it works at all) unless you arbitrarily restrict the number of levels of inclusion.
There's no portable way to do this with POSIX lex -- different implementations have different internal arrangements of how they deal with and buffer input, and during lexing, may have read ahead of the currently processing token and buffered a bunch of the input. So you need to get it to save what it has currently buffered and switch to a different input, and then restore the buffered stuff (so it will be read next) after you're done with the #include or whatever. This is precisely what flex's buffer management calls are for, but if you insist on using lex, you'll need to (effectively) port these routines to understand the internals of whatever versions of lex you need to support.
The solution to the "included input files" is part of flex documentation, which provides an example how to switch between flex inputs ftp://ftp.gnu.org/old-gnu/Manuals/flex-2.5.4/html_mono/flex.html#SEC12 ("Multiple Input Buffers")
You can find flex tool ported to windows system here http://sourceforge.net/projects/winflexbison/
Related
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 implementing a lexer/parser for the real-time language OpenPEARL. For better struturing of my testsuite I want to implement a include file handling similiar to C/C++. The parser iteself uses the visitors. What would be the best approach to implement this? One thing which concern me when instantiating a nested parser the included file does not need to contain a complete program depending where it is included.
Cheers
Marcel
I can't speak for ANTLR, but in general one implements a C-like preprocessor in the lexer.
You accomplish this by having a stack of input streams, with the base of the stack being the source file. You read input from the stream on top of the stack.
When an include is encountered in the lexer, a new stream is pushed on top of the stack, and reading continues (now from the new stream). When a stream encounters EOF, you pop the stack and continue; if the stack is empty, the lexer emits an EOF token.
You can abuse these streams to implement macros. On macro call, simply push a new stream that represents the macro body. When you encounter a macro parameter name, push a stream for the argument supplied to the corresponding macro.
I have seen implementations where include handling has been done in the (parser) grammar. Doing it in the lexer like Ira suggests is certainly possible, but with some extra work.
However, full include handling is more than simply switching input streams, namely macro handling, line splicing, trigraph handling, charizing and stringizing + as evaluator for #if(def) commands. All that I have implemented in my Windows Resource File Parser, which was written for ANTLR 2.7 and hence needs an update, but is certainly good for getting ideas.
In this project I handle include files outside of the normal ANTLR parsing chain, which follows more the preprocessor approach you often see for C/C++.
I'm currently trying to do some real-time signal-processing and I would like to use "gnuradio". I will be processing multiple channels of EEG which come in trough a custom interface (namely "Lab Streaming Layer"; LSL) in python.
Now my question is if there is an existing block already where you can kind of "push" samples into the signal-processing-graph during run-time? The only blocks I've found so far offer support for audio hardware, TCP-streams and files.
You will have to write your own block; that can be done in Python or C++, whatever is better for your case.
The GNU Radio Guided Tutorials (you should really read them in order from 1 to 5, at least) do explain how to do that.
Because we all know that people are lazy at reading, here's a rough preview of what you'll learn:
make a new Out-of-tree module: gr_modtool newmod sensorinterface, change into the newly generated directory: cd gr-sensorinterface
add a new source block: gr_modtool add eeg_sensor_source; the block type you'll want is "source"; you will be asked to fill in some block details.
edit the generated source file (in lib/ or python/, depending on which language you chose:
add a proper io signature: your output will probably have the size of float
edit the central work function; add code to get new samples, and copy those to the output_items buffer.
The guided tutorials are really nice!
The most flexible method is to write your own GNU Radio block, but there are several options for getting data into a flow graph without using any custom blocks. (Naming from the Python perspective.)
gnuradio.blocks.message_source, which takes data from a gnuradio.gr.msg_queue.
You can use a gnuradio.blocks.file_descriptor_source where the file descriptor is one end of a pipe.
I want to know the sample code for sending message to server and get back response to verifone vx520 terminal using ISO 8583.
As noted in a comment on your question, this is not a code sharing site, so such an open-ended question is a bit difficult to answer, but perhaps I can get you started on the right foot.
First of all, let me start by suggesting that if you have control over the terminal code and the server that it will be talking to, I suggest you NOT use ISO8583. Yes, it's an industry standard and yes, it communicates data efficiently, BUT it is much more difficult to use than, say, VISA-1 or XML, or JSON etc. That means you have more opportunities for bugs to creep into your code. It also means that if something goes wrong, it takes a lot more effort to try and figure out what happened and try and fix it. I have used all these protocols and others besides and I'll tell you that ISO8583 is one of my least favorite to work with.
Assuming you do not have a choice and you must use ISO8583 then it's worth noting that ISO8583 is nothing but a specification on how to assemble data packets in order to communicate. There is nothing special about the Vx520 terminal (or any other VeriFone terminal) that would change how you would implement it verses how you might do so on any other C++ platform EXCEPT that VeriFone DOES provide you with a library for working with this spec that you are free to use or ignore as you see fit.
You don't need to use this library at all. You can roll your own and be just fine. You can find more information on the specification itself at Wikipedia, Code Project, and several other places (just ask your favorite search engine). Note that when I did my 8583 project, this library was not available to me. Perhaps I wouldn't have hated this protocol so much if I had had access to it... who knows?
If you are still reading this, then I'll assume that ISO8583 is a requirement (or you are a glutton for punishment) and that you are interested in trying out this engine that VeriFone has provided.
The first thing you will need to do (and hopefully, you have already done it) is to install ACT as part of the development suite (I also suggest you head over to DevNet and get the latest version of ACT before you get started...). Once installed, the library header can be found at %evoact%\include\iso8583.h. Documentation on how to use it can be found at %evoact%\docs. In particular, see chapter 6 of DOC00310_Verix_eVo_ACT_Programmers_Guide.pdf.
Obviously, trying to include a whole chapter's worth of information here would be out of scope, but to give you a high-level idea of how the engine works, allow me to share a couple excerpts:
This engine is designed to be table driven. A single routine is used
for the assembly and disassembly of ISO 8583 packets. The assembly and
disassembly of ISO 8583 packets is driven by the following structures:
Maps One or more collections of 64 bits that drive packet assembly and
indicate what is in a message.
Field table Defines all the fields used
by the application.
Convert table Defines data-conversion routines.
Variant tables Optional tables used to define variant fields.
The process_8583() routine is used for the assembly and disassembly of ISO
8583 packets.
An example of using process_8583() is given elsewhere as follows:
#include "appl8583.h"
int packet_sz;
void assemble_packet ()
{
packet_sz = process_8583 (0, field_table, test_map, buffer, sizeof( buffer));
printf ("\ fOUTPUT SIZE %d", packet_sz);
}
void disassemble_packet ()
{
packet_sz = process_8583 (1, field_table, test_map, buffer, packet_sz);
printf ("\ fINPUT NOT PROCESSED %d", packet_sz);
}
To incorporate this engine into an application, modify the APPL8583.C
and APPL8583.H files so that each has all the application variables
required in the bit map and set up the map properly. Compile
APPL8583.C and link it with your application and the ISO 8583 library.
Use the following procedures to transmit or receive an ISO 8583 packet
using the ISO 8583 Interface Engine:
To transmit an ISO 8583 packet
1 Set data values in the application variables for those to transmit.
2 Call the prot8583_main() routine. This constructs the complete
message and returns the number of bytes in the constructed message.
3 Call write() to transmit the message.
To receive a message
1 Call read() to receive the message.
2 Call the process_8583() routine. This results in all fields being
deposited into the application variables.
3 Use the values in the application variables.
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.