I'm currently starting a new language (PROLOG) and I came across with a few issues.
I'm developing a simple board game in which I'm required to print the board. I've developed a PrintBoard and initialBoard predicate (as shown below), and I want to be able to run it from the main predicate, just like so:
printBoard([Head|Tail]) :-
printRow(Head),
printBoard(Tail).
printBoard([]).
printRow([Head|Tail]) :-
write(Head),
write(' '),
printRow(Tail).
printRow([]) :- nl.
initialBoard(Board) :- Board = ([
['b0','b0','b0','b0','b1'],
['b0','b0','b0','b0','b0'],
['b0','b0','b0','b0','b0'],
['b0','b0','b0','b0','b0'],
['b2','b0','b0','b0','b0']
]).
main :- Board = initialBoard(Board), printBoard(Board).
By typing main. in the SICStus PROLOG, the program should output the following:
b0 b0 b0 b0 b1
b0 b0 b0 b0 b0
b0 b0 b0 b0 b0
b0 b0 b0 b0 b0
b2 b0 b0 b0 b0
But, instead, it returns nothing. (Returns no).
The only way it seems to work is by inserting the whole list all over again as the variable, just like so:
main :- printBoard(<insert whole list here>).
Even though I'm looking to run it as:
main :- printBoard(initialBoard(Board)).
The portion of code above works, if main is passed the Board argument, but is it possible without passing it?
Functional code:
main(Board) :- printBoard(initialBoard(Board)).
Related
I want to read utf-16 by 2 bytes in flex and use it.
I will use 2 byte data converted to multibyte.
I opened the file with "rb" and read it.
But I can't read the following.
4C AE C0 C9 20 00 00 B3 9C B0 ...
flex read like this.
4C AE C0 C9 20 00 00 B3 9C B0 ...
I tried to read with this code.
<string>[\x00-\xff][\x00-\xff]{
...
}
How to read 2 bytes at a time in flex?
I couldn't reproduce the problem using the hints in the question. It appears to work perfectly, processed with several different Flex versions (2.6.4, 2.5.39 and 2.5.4) in case you are using some antiquated version. I didn't try any non-default command-line options.
So it's impossible to say what you are doing wrong without seeing everything you are doing. Of course, we don't want to wade through your entire program; instead, we ask that you provide a minimal reproducible example (MRE). Note that a MRE is not your program, nor is it a few lines of your program. It's a complete, compilable program which shows the same problem. Writing a MRE and verifying that it shows the same issue is a good debugging technique; in many cases, the exercise will let you find the problem yourself.
That description might be a bit theoretical, so I'm including the test code I wrote. Had it produced the output you claim to receive, it would have served as an MRE, so it might serve as a starting point for your investigation:
%option noinput nounput noyywrap nodefault
%x U16STRING
%%
u["] { fputs("UTF-16LE string:", stdout);
BEGIN(U16STRING); }
.|\n ; /* Ignore everything else */
<U16STRING>{
\x22\x00 { putchar('\n'); BEGIN(INITIAL); }
[\x00-\xff]{2} { fputs(" <", stdout);
for (int i = 0; i < yyleng; ++i)
printf(" %02hhx", (unsigned char)yytext[i]);
fputs(" >", stdout);
}
[\x00-\xff] { printf(" %02x !!", yytext[0]); BEGIN(INITIAL); }
<<EOF>> { puts(" EOF"); return 0; }
}
That code identifies sequences which start with Ascii/UTF-8 u" and end with a UTF-16LE double quote; the sequences are expected to be UTF-16LE, although the code doesn't check for surrogates. All it does is dump the bytes in hex to demonstrate that the input is being correctly tokenised.
Here's a sample run, including the build commands (the Flex source is called b2.l):
$ flex --version
flex 2.6.4
$ flex -o b2.c b2.l
$ gcc -o b2 -Wall b2.c -lfl
$ printf 'u"\x4c\xae\xc0\xc9\x20\x00\x00\xb3\x9c\xb0\x22\x00' | ./b2
UTF-16LE string: < 4c ae > < c0 c9 > < 20 00 > < 00 b3 > < 9c b0 >
$
I see a few implementations, but I decided to look at exactly how the specification calls out the FCS for encoding.
So say my input is as follows:
dst: 0xAA AA AA AA AA AA
src: 0x55 55 55 55 55 55
len: 0x00 04
msg: 0xDE AD BE EF
concatenating this in the order that seems to be specified in the format (and the order expressed in the spec later on) seems to indicate my input is:
M(x) = 0xAA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF
a) "The first 32 bits of the frame are complemented."
complemented first 32 MSB of M(x): 0x55 55 55 55 AA AA 55 55 55 55 55 55 00 04 DE AD BE EF
b) "The n bits of the protected fields are then considered to be the coefficients of a polynomial M(x) of
degree n – 1. (The first bit of the Destination Address field corresponds to the x(n–1) term and the last
bit of the MAC Client Data field (or Pad field if present) corresponds to the x0 term.)"
I did this in previous. see M(x)
c) "M(x) is multiplied by x^32 and divided by G(x), producing a remainder R(x) of degree <=31."
Some options online seem to ignore the 33rd bit to represent x^32. I am going to ignore those simplified shortcuts for this exercise since it doesn't seem to specify that in the spec.
It says to multiply M(x) by x^32. So this is just padding with 32 zeroes on the LSBs. (i.e. if m(x) = 1x^3 + 1, then m(x) * x^2 = 1x^5 + 1x^2 + 0)
padded: 0x55 55 55 55 AA AA 55 55 55 55 55 55 00 04 DE AD BE EF 00 00 00 00
Next step is to divide. I am dividing the whole M(x) / G(x). Can you use XOR shifting directly? I see some binary division examples have the dividened as 101 and the divisior as 110 and the remainder is 11. Other examples explain that by converting to decimal, you cannot divide. Which one is it for terms for this standard?
My remainder result is for option 1 (using XOR without carry bit consideration, shifting, no padding) was:
0x15 30 B0 FE
d) "The coefficients of R(x) are considered to be a 32-bit sequence."
e) "The bit sequence is complemented and the result is the CRC."
CRC = 0xEA CF 4F 01
so my entire Ethernet Frame should be:
0xAA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF EA CF 4F 01
In which my dst address is its original value.
When I check my work with an online CRC32 BZIP2 calculator, I see this result: 0xCACF4F01
Is there another option or online tool to calculate the Ethernet FCS field? (not just one of many CRC32 calculators)
What steps am I missing? Should I have padded the M(x)? Should I have complemented the 32 LSBs instead?
Update
There was an error in my CRC output in my software. It was a minor issue with copying a vector. My latest result for CRC is (before post-complement) 35 30 B0 FE.
The post-complement is: CA CF 4F 01 (matching most online CRC32 BZIP2 versions).
So my ethernet according to my programming is currently:
0xAA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF CA CF 4F 01
The CRC you need is commonly available in zlib and other libraries as the standard PKZip CRC-32. It is stored in the message in little-endian order. So your frame with the CRC would be:
AA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF B0 5C 5D 85
Here is an online calculator, where the first result listed is the usual CRC-32, 0x855D5CB0.
Here is simple example code in C for calculating that CRC (calling with NULL for mem gives the initial CRC):
unsigned long crc32iso_hdlc(unsigned long crc, void const *mem, size_t len) {
unsigned char const *data = mem;
if (data == NULL)
return 0;
crc ^= 0xffffffff;
while (len--) {
crc ^= *data++;
for (unsigned k = 0; k < 8; k++)
crc = crc & 1 ? (crc >> 1) ^ 0xedb88320 : crc >> 1;
}
return crc ^ 0xffffffff;
}
The 0xedb88320 constant is 0x04c11db7 reflected.
The actual code used in libraries is more complex and faster.
Here is the calculation of that same CRC (in Mathematica), using the approach described in the IEEE 802.3 document with polynomials, so you can see the correct resulting powers of x used for the remainder calculation:
If you click on the image, it will embiggen to make it easier to read the powers.
The confusing factor here is the 802.3 spec. It mentions that first bit is LSB (least significant bit == bit 0) only in one place, in section 3.2.3-b, and it mentions that for CRC, "the first bit of the Destination Address field corresponds to the x^(n-1) term", so each byte input to the CRC calculation is bit reflected.
Using this online calculator:
http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
Select CRC-32 | CRC32, click on custom, input reflected on, result reflected off. With this data:
AA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF
per the spec, the calculated CRC is 0x0D3ABAA1, stored and transmitted as shown:
bit 0 first | bit 7 first
AA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF | 0D 3A BA A1
To simplify the output to always transmit bit 0 first, bit reflect the CRC bytes:
bit 0 first | bit 0 first
AA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF | B0 5C 5D 85
Note that the bit 0 always first method results in transmitted bits identical to the spec.
Change result setting for the CRC calculator, input reflected on, result reflected on. With this data:
AA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF
the calculated CRC is 0x855D5CB0, stored least significant byte first and transmitted as shown:
bit 0 first | bit 0 first
AA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF | B0 5C 5D 85
For verifying received data, rather than compare a calculated CRC of received data versus the received CRC, the process can calculate a CRC on received data and CRC. Assuming the alternative setup where all bytes are received bit 0 first, then with this received frame or any frame without error
bit 0 first | bit 0 first
AA AA AA AA AA AA 55 55 55 55 55 55 00 04 DE AD BE EF | B0 5C 5D 85
the calculated CRC will always be 0x2144DF1C. In the case of a hardware implementation, the post complement of the CRC is usually performed one bit at a time as bits are shifted out, outside of the logic used to calculate the CRC, and in this case, after receiving a frame without error, the CRC register will always contain 0xDEBB20E3 (0x2144DF1C ^ 0xFFFFFFFF). So verification is done by computing CRC on a received frame and comparing the CRC to a 32 bit constant (0x2144DF1C or 0xDEBB20E3).
Need some help on this cause I'm getting an issue
I've this three columns (Time, R1 and R2) and I'm trying to count the mismatches between R1 and R2 but for each month (on the time column)
I already used a formula but I'm having an issue to add 1.
https://docs.google.com/spreadsheets/d/1bVP79Gbd14lO6xunu2K9POT7y55yrXegD-cTF70Fb4k/edit#gid=0 (the spreadsheet with the values)
=iferror(if(EOMONTH($A64,0)=$A64,SUMPRODUCT(month(Database!$C$2:$C) = month($A64),--(Database!G$2:G <> Database!H$2:H)),""),"Error")
This part "month(Database!$C$4:$C) = month($A5)" is where I compare the information of the months, ( but I'm having an issue cause cause "month(Database!$C$4:$C)" only retrieves 4 that is the month of april)
This part "(Database!G$4:G <> Database!H$4:H)" is where I compare the columns R1 and R2
The part "EOMONTH($A5,0)=$A5" is where I take the month to based myself
Time R1 R2
2020-04-30 BA BU
2020-04-30 BU BA
2020-04-29 BA BU
2020-04-29 BU BA
2020-04-28 BA BU
2020-04-28 AA BA
2020-04-25 AA BA
2020-04-22 BU BA
2020-04-19 AA BU
2020-04-19 AA BA
2020-03-27 BA AA
2020-03-27 BA AA
2020-03-26 BU AA
2020-03-18 BA AA
2020-03-18 AA BU
Approach
In order to validate the answer I created a test Spreadsheet from a copy of your. In this sheet I created two support columns, one which contains the month number: MONTH($A1) and the other one a flag if the two values R1 and R2 are different: IF($B1=$C1,"",1).
In this way I can use this two support structure to validate the numbers obtained by the formula which didn't use any. I will use a much simpler formula this time to compute the sum =SUMIF(D:D,month(<DATE_VALUE>),E:E).
I will link here the test sheet. As you can see the values are the same as the ones obtained by the formula. So, I can confirm that if you are expecting different results, your database is not consistent.
In conclusion the formula: if(EOMONTH($A64,0)=$A64,SUMPRODUCT(month(Database!$C$2:$C) = month($A64),--(Database!G$2:G <> Database!H$2:H)),"") is working correctly.
I have a variable list in my Makefile like that:
varglob := a1 a2 a3 a4 a5 a6
I want to create a new variable from varglob but eliminate some specific elements for example "a3".
I thought about foreach but my problem is that I don't know how I test with ifneq inside the foreach. So I tried to use shell like that:
varglobelim := $(foreach y, $(varglob), $(shell if [$(y) != "a3"]; then echo $y;fi))
But this solution doesn't success. I get an empty message.
Is there any other suggestions?
filter-out is your friend here:
varglob := a1 a2 a3 a4 a5 a6 b7 b8 b-whatever
has-no-ticket := a3 b% # a3 and all the b's didn't pay the ride
varglobelim := $(filter-out $(has-no-ticket),$(varglob))
I am trying to understand how Mach-o files work, and have made a good deal of progress with the online resources available (In particular, the Apple page here: http://developer.apple.com/library/mac/#documentation/developertools/conceptual/MachORuntime/Reference/reference.html), but I have hit a roadblock on understanding how symbol stubs work.
Using "otool -l" I see the following section:
Section
sectname __symbolstub1
segname __TEXT
addr 0x00005fc0
size 0x00000040
offset 20416
align 2^2 (4)
reloff 0
nreloc 0
flags 0x80000408
However when I look at the data from the binary file in a hex editor I see the following 4 bytes repeated again and again:
00005FC0 38 F0 9F E5 38 F0 9F E5 38 F0 9F E5 38 F0 9F E5 88
00005FD0 38 F0 9F E5 38 F0 9F E5 38 F0 9F E5 38 F0 9F E5 88
00005FE0 38 F0 9F E5 38 F0 9F E5 38 F0 9F E5 38 F0 9F E5 88
00005FF0 38 F0 9F E5 38 F0 9F E5 38 F0 9F E5 38 F0 9F E5 88
This looks something like a LDR which increases the PC by a fixed amount, but I don't see why the amount is the same for each entry in the symbol table.
If someone can shed light on why this is so, or provide any resources that get this low level, please let me know.
Thanks!
I will describe the situation with the current iOS, it's somewhat different in the old versions.
The symbol stubs indeed load into the PC a function pointer. For the standard "lazy" (on-demand) imports, the pointer resides in the __lazy_symbol section and initially points to a helper routine in the __stub_helper section, e.g.:
__symbolstub1 _AudioServicesAddSystemSoundCompletion
__symbolstub1 LDR PC, _AudioServicesAddSystemSoundCompletion$lazy_ptr
__symbolstub1 ; End of function _AudioServicesAddSystemSoundCompletion
__lazy_symbol _AudioServicesAddSystemSoundCompletion$lazy_ptr DCD _AudioServicesAddSystemSoundCompletion$stubHelper
__stub_helper _AudioServicesAddSystemSoundCompletion$stubHelper
__stub_helper LDR R12, =nnn ; symbol info offset in the lazy bind table
__stub_helper B dyld_stub_binding_helper
The function dyld_stub_binding_helper is the fist one in the __stub_helper section and essentially is just a trampoline to the dyld_stub_binder function in dyld, passing to it what I call "symbol info offset" value. That value is an offset inside the lazy binding info stream (pointed to by the LC_DYLD_INFO or LC_DYLD_INFO_ONLY load command), which is a sort of bytecode stream with commands for dyld. Typical sequence for a lazy import looks like this:
72: BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB(M, 0xYYYYY)
19: BIND_OPCODE_SET_DYLIB_ORDINAL_IMM(NNNN)
40: BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM(0x00, '_AudioServicesAddSystemSoundCompletion')
90: BIND_OPCODE_DO_BIND()
here dyld would do the following:
look up function named '_AudioServicesAddSystemSoundCompletion' from
a dylib number NNNN in the list of dylibs listed in the load
commands.
look up the executable's segment number M (most likely __DATA)
write the function pointer at the offset YYYYY.
jump to the looked up address so that the actual function does its job
The address written to happens to be the _AudioServicesAddSystemSoundCompletion$lazy_ptr slot. So, the next time the _AudioServicesAddSystemSoundCompletion is called, it will jump directly to the imported function, without going via dyld.
N.B.: you should not look at the offset 05fc0 in the file right away. The addr field is the virtual address, you should look up the containing segment command and see at what VA it starts and what is its file offset, then do the math. Usually the __TEXT segment starts at 1000.
However, the actual symbol stubs do look like you pasted, probably you have a fat mach-o with the fat header taking the first 1000 bytes, so the offsets line up.