Memory Mapping Large File Haskell - haskell

I am experimenting with the Haskell mmap package and I am quite new to Haskell, so I am trying to get started by writing a little program to write a small amount of data to a memory mapped file.
This code correctly creates and file size but doesn't seem to flush the data from the vector to the memory mapped file; I verified this using hexdump - it's just all 0s.
What is going wrong?
import Control.Monad
import Data.Vector.Storable
import Foreign.Marshal.Array
import System.Directory
import System.IO
import System.IO.MMap
createFile :: FilePath -> Integer -> IO ()
createFile path size = do
h <- openBinaryFile path WriteMode
hSetFileSize h size
n = 10
size = 10 * 8
path = "test.dat" :: FilePath
main :: IO ()
main = do
createFile "signal.ml" size
let v = generate n (\i -> i) :: Vector Int
putStrLn $ show v
(ptr, s, _, _) <- mmapFilePtr path ReadWrite Nothing
unsafeWith v (\srcPtr -> copyArray ptr srcPtr n)
munmapFilePtr ptr s
Many thanks.

Looks like a typo. If I replace this:
createFile "signal.ml" size
with this:
createFile path size
I get correct result:
$ xxd test.dat
0000000: 0000 0000 0000 0000 0100 0000 0000 0000 ................
0000010: 0200 0000 0000 0000 0300 0000 0000 0000 ................
0000020: 0400 0000 0000 0000 0500 0000 0000 0000 ................
0000030: 0600 0000 0000 0000 0700 0000 0000 0000 ................
0000040: 0800 0000 0000 0000 0900 0000 0000 0000 ................

Related

Is there a way to exploit BitBoard advantages on a 4x16 gameboard?

So basically the title. The gameboard looks like this:
0000 0000 0000 0000
0000 0000 0000 0000
0000 0000 0000 0000
0000 0000 0000 0000
I cant wrap my head around, if it is possible to use the BitBoard logic on this kind of board?
If it is possible is there an advantage doing it?
Or can BitBoard logic only be used for square boards ?

jumping indices of values in buffer

I am currently testing some things with an accelerometer and its iio buffer and there is something that confuses me.
The sensor does have four different scan elements: x, y, z and a timestamp.
The indices of those values are:
x = 0, y = 1, z = 2 and time = 3. So far so good.
If I enable all available scan elements the order of the entries is set according to the description.
everything enabled:
0000010 f758 011c 3f64 c0b0 be90 0bfe 499f 0004
0000020 f724 0134 3f58 c0b0 3f2f 10ab 499f 0004
But once I have gaps, for example if I disable the scan element for y, the z value jumps onto index 1 and my buffer looks like this:
x, z and time:
0000010 f720 3f70 0000 0000 722a 5c13 4946 0004
0000020 f728 3f74 0000 0000 0958 60c0 4946 0004
z and time:
0000010 3f6c 0000 0000 0000 ca0b 6ef1 48be 0004
0000020 3f44 0000 0000 0000 edf7 739e 48be 0004
only x and z:
0000010 f720 3f48 f748 3f54 f744 3f5c f75c 3f68
0000020 f750 3f78 f738 3f80 f718 3f64 f700 3f50
I could not find further information on this but I am a bit confused and surprised that the scan elements do not respect their given index once the timestamp is activated and there is an index gap. Is this the normal behavior or is this some stuff that the current sensor driver mixes up?

How to make the DOS .exe relocation table smaller with OpenWatcom linker?

I've created the following DOS .exe file with OpenWatcom:
$ xxd prog.exe
00000000: 4d5a 8200 0100 0100 0300 4000 ffff 0500 MZ........#.....
00000010: 0204 0000 0000 0000 2000 0000 0000 0000 ........ .......
00000020: 0100 0000 0000 0000 0000 0000 0000 0000 ................
00000030: b804 008e d8e8 0900 b44c cd21 d1e2 01d0 .........L.!....
00000040: c353 52ba 0200 b409 cd21 ba0c 00b4 09cd .SR......!......
00000050: 21ba 0f00 b409 cd21 ba08 00b8 0700 e8db !......!........
00000060: ff89 c3ba 0a00 b809 00e8 d0ff 01d8 5a5b ..............Z[
00000070: c300 4865 6c6c 6f21 0d0a 2400 6162 0063 ..Hello!..$.ab.c
00000080: 6400 d.
Regions:
0x0...0x1c: DOS .exe header.
0x1c...0x20: 4 bytes of padding.
0x20...0x24: 4 bytes containing 1 relocation entry.
0x24...0x30: 12 bytes of padding.
0x30...: code (_TEXT) segment with 16-bit 8086 machine code.
...
How do I get rid of the 4 bytes of padding and the 12 bytes of padding, so that the code starts at offset 0x20? Is there a WLINK flag for this? Should I use a different linker? Should I post-process the generated .exe?
I wasn't able to find a configuration option for this, so I ended up writing my own linker and using it instead of WLINK. This way the .exe header became only 24 (0x18) bytes, and I didn't need any relocations.

Python stops binary reading of file after getting byte 0xa or 0xd

I want to read some binary file. It is a big file so i use maximalOffset variable to stop reading after getting to it. But reading is always ends at one offset - 8199. The last byte i get is 0xa. In xxd it is the part of byte 0a0d.
I am using Ubuntu 18 and Python 3.
I found some info about 0x1A in Windows (it's EOF symbol or something) but the solution was to use binary reading and 0xA is not 0x1A...
maximalOffsetString = "2070"
maximalOffset=int(maximalOffsetString,16)
offset=-16 # first 16 bytes must be on 0x0 offset
line = [ ]
pagefile = open("./pagefile", "rb")
for bytes in pagefile:
for byte in bytes:
if maximalOffset==offset: break
if len(line) == 16:
print(hex(offset))
print(str(offset)+" : "+str(maximalOffset))
print(line)
del line[:]
line.append(hex(byte))
offset=offset+1
break
pagefile.close()
# here i see what was the last symbols in array:
print(hex(offset))
print(str(offset)+" : "+str(maximalOffset))
print(line)
Output:
0x2007
8199 : 8304
['0xf0', '0xa9', '0xc', '0x7', '0x71', '0xc0', '0xa']
as you can see, my maximalOffset is 8304 but the reading stops at 8199. In xxd this line is:
00002010: f0a9 0c07 71c0 0a0d 0000 006c 0105 5c00
All file before this is only zeros. After 0x2000 there are random bytes.
00001fb0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001fc0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001fd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001fe0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00001ff0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00002000: 0104 0000 6f01 005c 0094 008c e026 6469 ....o..\.....&di
00002010: f0a9 0c07 71c0 0a0d 0000 006c 0105 5c00 ....q......l..\.
00002020: 9500 8c20 b800 8040 0001 10ab 0c07 4230 ... ...#......B0
00002030: 0dba 0069 010a 5c00 9600 8ce8 b800 38a7 ...i..\.......8.
00002040: 0c07 fbd0 7b01 6601 0f5c 0097 0008 0020 ....{.f..\.....
00002050: 208c f8b8 0090 940d 0724 0000 7a01 6301 ........$..z.c.
00002060: 0c5c 0098 008c 0027 6469 9892 0d07 f2b9 .\.....'di......
00002070: 0009 0080 4100 4100 6001 115c 0099 008c ....A.A.`..\....
00002080: 08b8 0020 0d0e 072b 7c01 7d01 165c 009a ... ...+|.}..\..
00002090: 008c 10b8 0028 a20c 0727 bc00 8100 4200 .....(...'....B.
000020a0: 7a01 1b5c 009b 008c 18b9 009f 0d07 29bc z..\..........).
000020b0: 0077 0118 5c00 9c00 8c98 b803 6091 0d07 .w..\.......`...
000020c0: 06b0 3b05 4000 0103 7401 1d5c 009d 7801 ..;.#...t..\..x.
000020d0: b800 208f 0d07 10f0 097a 0471 0122 5c00 .. ......z.q."\.
I think you are breaking the outer for loop before reading is finished, remove break at the bottom of the outer for loop.
...
for bytes in pagefile:
for byte in bytes:
...
line.append(hex(byte))
offset=offset+1
break # <- Remove this
pagefile.close()
...

what left and right shift operator and how they works

//((Hello everybody!
i am C# beginner can any one tell me the function of left and right shift operator and their working way w.r.t the following program. I read it somewhere but confuse.
thanks ))
using System;
class clc
{
public static void Main() // the Main method
{
int x = 7, y = 2, z, r;
z = x << y ; //left shift operator
r = x >> y; // right shift operator
Console.WriteLine("\n z={3}\tr={4} ",z,r);
}
}
To understand the shift operations you must understand binary numbers.
Let's take your example for left shift:
z = 7 << 2;
32 bit integer 7 is 0000 0000 0000 0000 0000 0000 0000 0111 in binary. You must move the bits to the left beginning from the right. The bits that are shifted out of either end are discarded.
Shifting it by 1 will result 0000 0000 0000 0000 0000 0000 0000 1110
Shifting it by 1 one more time will result 0000 0000 0000 0000 0000 0000 0001 1100 which is 28 in integer representation.
Read this good wikipedia article Binary number

Resources