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.
Related
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.
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 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 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/
I'm writing a Linux kernel module that needs to open and read files. What's the best way to accomplish that?
Can I ask why are you trying to open a file?
I like to follow Linux development (out of curiosity, I'm not a kernel developer, I do Java), and I've seen discussion of this question before. I was able to find a LKML message about this, basically mentioning it's usually a bad idea. I'm almost positive that LWN covered it in the last year, but I'm having trouble finding the article.
If this is a private module (like for some custom hardware and the module won't be distributed) then you can do this, but I'm under the impression that if you are going to submit your code to the mainline then it may not be accepted.
Evan Teran mentioned sysfs, which seems like a good idea to me. If you really need to do harder custom stuff you could always make new ioctrls.
EDIT:
OK, I found the article I was looking for, it's from Linux Journal. It explains why doing this kind of stuff is generally a bad idea, then goes on to tell you exactly how to do it anyway.
assuming you can get pointers to the relavent function pointers to the open/read/close system calls, you can do something like this:
mm_segment_t fs = get_fs();
set_fs(KERNEL_DS);
fd = (*syscall_open)(file, flags, mode);
if(fd != -1) {
(*syscall_read)(fd, buf, size);
(*syscall_close)(fd);
}
set_fs(fs);
you will need to create the "syscall_*" function pointers I have shown though. I am sure there is a better way, but I believe that this would work.
Generally speaking, if you need to read/write files from a kernel module, you're doing something wrong architecturally.
There exist mechanisms (netlink for example - or just register a character device) to allow a kernel module to talk to a userspace helper process. That userspace helper process can do whatever it wants.
You could also implement a system call (or such like) to take a file descriptor opened in userspace and read/write it from the kernel.
This would probably be neater than trying to open files in kernel space.
There are some other things which already open files from kernel space, you could look at them (the loop driver springs to mind?).
/proc filesystem is also good for private use, and it's easy.
http://www.linuxtopia.org/online_books/Linux_Kernel_Module_Programming_Guide/x773.html
All of the kernel developers say that file I/O from kernel space is bad (especially if you're referring to these files by their paths) but the mainstream kernel does this when you load firmware. If you just need to read from files, use the
kernel_read_file_from_path(const char *path, void **buf, loff_t *size, loff_t max_size, enum kernel_read_file_id id)
function, which is what the firmware loader code uses, declared in include/linux/fs.h. This function returns a negative value on error.
I'm not really sure of the point of the id variable at the end, if you look at the code it's not really used, so just put something like READING_FIRMWARE there (no quotes).
buf is not null terminated, instead refer to its size in size. If you need it to be null terminated, create a string size + 1 bytes long and copy it over or rewrite the kernel_read_file() function (used by kernel_read_file_from_path(), defined in fs/exec.c) and add one to i_size where memory is allocated. (If you want to do this, you can redefine the kernel_read_file() function in your module with a different function name to avoid modifying the whole kernel.)
If you need to write to files, there is a kernel_write() function (analogous to kernel_read(), which is used by kernel_read_file() and therefore also by kernel_read_file_from_path()), but there is no kernel_write_file() or kernel_write_file_from_path() function. You can look at the code in the fs/exec.c file in the Linux kernel source tree where kernel_read_file() and kernel_read_file_from_path() are defined to write your own kernel_write_file() and kernel_write_file_from_path() functions that you can include in your module.
And as always, you can store a file's contents in a char pointer instead of a void pointer with this function by casting it.
You can also find some informations about sys_call_open in this Linux Kernel Module Programing Guide.