4 ms·

I don't get it. tar is such a simple format you could do this in like 50 lines of C. Most of that would be declaring a struct. And unlike this implementation, i

I don't get it. tar is such a simple format you could do this in like 50 lines of C. Most of that would be declaring a struct. And unlike this implementation, it would be performant.

dagss 4y ago
First time I see Prolog...I thougt that seeing the compiler invert a function automatically is quite impressing. I mean just being able to take only the forwards declaration and figure out the inverse is interesting in itself.
mattkrause 4y ago
The cool thing is that it uses the same code as the reader and writer.In essence, you write one function, taking two arguments: tar(dstTarFile, srcFiles) Next you provide one of the two arguments and query Prolog to find the other: you pass in a tar file as the first argument, and it tells you what `srcFiles` would need to be to create that archive, effectively extracting it. Alternately, you pass in `srcFiles` and it tells you what the corresponding dstTarFile should be, creating an archive. Another way to think about it is that the Prolog code is not directly telling you how to read/write tar files. Instead, imagine it as a cost function that tells you how well this tar file corresponds to the uncompressed representation of those files, which you're minimizing. If you were to write it in C, the code would imperative: do this, then that, then this other thing. Consequently, the reader and writer code are totally different. For example, to process the file size, you would write functions two functions: char* uIntToOctalASCII(unsigned int sz)` and octalASCIIToUInt(char* szstr). Semantically, these are inverses[0]: octalASCIIToUInt(uIntToOctalASCII(x)) == x but the implementations have very little in common. At best, you can use one to test the other. [0] And leaks memory, but whatever....
- xdfgh1112 4y ago
  Similarly if you write a sudoku solver in prolog, you automatically get a solver AND a problem generator, both for unfilled and partially filled grids.
Avshalom 4y ago
You can pack bytes into a structure in prolog succintly enough too open('test.tar',read,TarFile) HSizes = [100,8,8,8,12,12,8,1,100,6,2,32,32,8,8,155,12], maplist(length,HBytes,HSizes), append(HBytes,~read_bytes(TarFile,512)), HBytes is now a list of lists of your bytes, do with them as you please, we can even name them if we want HFields = [ filename, filemode, ownerid, groupid, filesize , modificationtime, checksum, typeflag, linkedfilename , ownerusername, ownergroupname, devicemajornumber , deviceminornumber, filenameprefix, padding], keys_and_values(HFields,HBytes,Header), you could push it off into a predicate and it'd even more or less work relationally and it'd probably be faster than the DCG... but it wouldn't be interesting. And like they said https://news.ycombinator.com/item?id=34431450 https://news.ycombinator.com/item?id=34431450

I don't get it. tar is such a simple format you could do this in like 50 lines of C. Most of that would be declaring a struct. And unlike this implementation, it would be performant.

dagss 4y ago

First time I see Prolog...I thougt that seeing the compiler invert a function automatically is quite impressing. I mean just being able to take only the forwards declaration and figure out the inverse is interesting in itself.

mattkrause 4y ago

The cool thing is that it uses the same code as the reader and writer.In essence, you write one function, taking two arguments: tar(dstTarFile, srcFiles) Next you provide one of the two arguments and query Prolog to find the other: you pass in a tar file as the first argument, and it tells you what `srcFiles` would need to be to create that archive, effectively extracting it. Alternately, you pass in `srcFiles` and it tells you what the corresponding dstTarFile should be, creating an archive. Another way to think about it is that the Prolog code is not directly telling you how to read/write tar files. Instead, imagine it as a cost function that tells you how well this tar file corresponds to the uncompressed representation of those files, which you're minimizing. If you were to write it in C, the code would imperative: do this, then that, then this other thing. Consequently, the reader and writer code are totally different. For example, to process the file size, you would write functions two functions: char* uIntToOctalASCII(unsigned int sz)` and octalASCIIToUInt(char* szstr). Semantically, these are inverses[0]: octalASCIIToUInt(uIntToOctalASCII(x)) == x but the implementations have very little in common. At best, you can use one to test the other. [0] And leaks memory, but whatever....

xdfgh1112 4y ago
Similarly if you write a sudoku solver in prolog, you automatically get a solver AND a problem generator, both for unfilled and partially filled grids.

Avshalom 4y ago

You can pack bytes into a structure in prolog succintly enough too open('test.tar',read,TarFile) HSizes = [100,8,8,8,12,12,8,1,100,6,2,32,32,8,8,155,12], maplist(length,HBytes,HSizes), append(HBytes,~read_bytes(TarFile,512)), HBytes is now a list of lists of your bytes, do with them as you please, we can even name them if we want HFields = [ filename, filemode, ownerid, groupid, filesize , modificationtime, checksum, typeflag, linkedfilename , ownerusername, ownergroupname, devicemajornumber , deviceminornumber, filenameprefix, padding], keys_and_values(HFields,HBytes,Header), you could push it off into a predicate and it'd even more or less work relationally and it'd probably be faster than the DCG... but it wouldn't be interesting. And like they said https://news.ycombinator.com/item?id=34431450 https://news.ycombinator.com/item?id=34431450