In a first phase, i collect a list of constraints. Then, i would like to store this "session", i.e. All the constraints but all the associated variables as well in a file so that I can, in a second phase, read back the constraints and assert them, or even negate some of them before asserting.
What is the best way (fast and reliable) to store such a "session" in a file, and read it back ? Would the Z3_parse_smtlib2_file() API be the right way ? I have tried the Z3_open_log() API, but I don't find the API to read the log file generated by Z3_open_log(). And what about z3_log_replay(). This API does not seem to be exposed yet.
Thanks in advance.
AG
The log file created by Z3_open_log() can be replayed with Z3.exe (stand alone interpreter, not the lib) through the command line option /log myfile. As of today, I haven't seen any API in Z3 library that allows such a replay. For the time being, I have understood that the replay is deemed for debug analysis.
However, you can hack the library (just expose the z3_replayer class in z3_replayer.h) and use it to replay any log file, it is quite easy. The source code of my little feasibility-proof is given below, and is working fine as far as I know. I think it is very nice to be able to do that because sometimes I need to replay a session for debugging purpose. It is good to be able to replay it from a file, rather than from my whole program which is a bit heavy.
Any feedback would be very welcome. Also I would be interested to know whether this functionality could be integrated in the lib, or not.
AG.
#include <fstream>
#include <iostream>
#include "api/z3_replayer.h"
int main(int argc, char * argv[])
{
const char * filename = argv[1];
std::ifstream in(filename);
if (in.bad() || in.fail()) {
std::cerr << "Error: failed to open file: " << filename << "\n";
exit(EXIT_FAILURE);
}
z3_replayer r(in);
r.parse();
Z3_context ctx = reinterpret_cast<Z3_context>(r.get_obj(0));
check(ctx,Z3_L_TRUE); // this function is taken from the c examples
return 0;
}
I have a situation where disk becomes full and my program hangs because of fflush being used on stdout. I have put down a small code to mimic the problem. We have to redirect this programs stdout to a file in a disk whose size is full already.
while(1){
cout << "a big data to be written here";
int ret = fflush(stdout);
if(ret != 0){
cerr << "get error : " << strerror(errno) << endl;
exit(1);
}
}
And this code hangs forever. I tried to use fcntl with O_NONBLOCK for stdout. Even that doesn`t work somehow. Please note I can not use write system call here though that avoids this kinda hang problem when disk is full. As my system widely uses library calls in many places if I use write system call only in this place it would create output in mixed manner. Can anyone suggest how to avoid hanging ?
I have tried fsync, fdatasync also. Same hanging with those functions too.
Update: fcntl fixed this problem even with cout and fflush combination.
You are mixing C++ stream I/O and C stdio functions. Instead of using fflush(stdout), use cout.flush() if needed. Instead of checking the return code from fflush, you should instead check cout.good() or use cout.rdstate(). I assume the cout operations are failing but fflush is not the part seeing the failure.
I am writing a code in Lua to read from a serial port, but when I read I receive an echo back with the code :
print("Dragino Uart Test started\n")
while 1 do
serialin=io.open("/dev/ttyS0","r")
print(serialin:read()) --print the data
serialin:close()
end
When I open minicom to send him some data, I enable local echo than I type "text" and I see :
tteexxtt
Then I need to press enter to see my message in my lua script.
I am using a OpenWRT in a Dragino.
It seems that it is like a prompt command that you type every thing that you see and you need to press enter to send you command.
There is any other way to read and write to/from a serial port?
Can somebody help me please? Thank you so much!
The read method with no arguments reads a full line. That's why you need to press enter at the end of the text. Try reading one byte at a time with :read(1) or all of it with :read("*a").
I don know if this is still an issue to someone but maybe this helps a few people. Like lhf said :read(1) is a gread way of doing this. I had a few problems with :read("*a") though. In my opinion the easiest way of doing this is to append the answer piece by piece like:
rserial=io.open("/dev/ttyS0",'r')
lines = ""
repeat
local line=rserial:read(1)
if string.sub(line, 0, 3) == "OED" then --OED is here the stream ending. This can vary
EOD = true
rserial:close()
elseif line then
lines = lines .. line
end
until EOD == true
print (lines)
does anybody knows how to handle connection lost situation in exmpp library?
Any examples are welcome!
So, all you have to do is to add condition in receive loop. Something like this:
receive
% Here is you code
{stream_error,'system-shutdown'} ->
do_something;
% Here is you code
end.
Hello there fellow Stackers!
I wonder if anybody could tell me what the following file format is? If you print it as-is then your print out will be, er, as-is BUT if you send it directly to the printer (for example using NET USE in a DOS/Windows batch file) it will actually print a very nice Parcelforce posting label:
:Printer Setting...
WN
N
R0,0
N
I8,0,061
S2
D9
ZT
Q1242,020
:Carrier Logo...
GG50,1060,"BLOB400"
:Service Indicator...
A775,1160,2,A,1,1,N,""
LO530,975,290,4
LO530,975,4,232
:739 bullet (type 1)...
A125,1005,1,1,1,1,N,"739"
A455,1030,2,4,1,1,N,"PB PI3749824 001"
:Despatch Date...
A270,935,2,3,1,1,N,"Despatch Date/Day"
A270,915,2,3,1,1,N,"16/09/10, Thu"
:Address Info...
A795,915,2,4,1,1,N,"MR STACK OVERFLOW"
A795,885,2,4,1,1,N,"CPU LANE"
A795,855,2,4,1,1,N,"COMPUTER CASE"
A795,825,2,4,1,1,N,"UK "
A795,795,2,5,1,1,N,"90210"
:Parcel Number...
A460,980,2,4,1,2,N,"1"
A360,980,2,4,1,2,N,"1"
A400,980,2,4,1,1,N,"OF"
:Bar-coded Postcode...
B330,885,2,1,3,4,170,N,"*90210*"
Is it XPS or PCL or something? Printer-specific? Any thoughts or answers would be appreciated! Thanks guys.
I don't think it's XPS or PCL.
It appears to have a lot in common with HPGL.
I think I found it; it appears to be EPL.