Pack

[domasz]

Very nice!

[O]

Pack new website has been released.

https://pack.ac/

Please check, and let me know what you think.

[domasz]

Interesting design! All the information I'd expect to see on such a website is there.

[O]

Thank you very much!

[AlexTP]

New site is very good!

>--press=[hard] Ask for a harder press

What other values are here? Maybe "store" or "none" value will be good here if I want to store (300) MP3s into single .pack file.

[AlexTP]

>--include Specifying a file or folder in a Pack file to unpack or list.

Is it analog of RAR's @ListFile param? ie "pack --include filelist.txt" to handle filesnames saved in filelist.txt?

[AlexTP]

Do app show the error-msg if I 'pack' 3000 MP3s into single .pack and 4Gb FAT32 limit if overflown?

[O]

Thank you, Alex!

Only Hard. No worries about not compressible files. Pack will detect them and skip them automatically. Try it, and you will see that it processes 1GB of MP3, much faster than 1GB of TXT. I should note that it does not work based on file extension, so any file that it tries and sees cannot be compressed; it will be processed faster.

And for compressable files, like the previous point you showed about compressing to tar, it will still be faster to press them to store them.

--include lets you choose a file or folder inside the .pack file to unpack. So for example if you have a pack of Lazarus project, you can unpack only a pas file instead of all the project.


Yes, it throws an error if it reaches the end of the disk or file system limit. You will not get an incomplete file.

[O]

On HackerNews, someone posted Pack, and there is a good discussion happening around Pascal, that people here may enjoy reading or contributing to https://news.ycombinator.com/item?id=39793805
One of the points of making Pack with Pascal was to show again that you can write fast and readable codes with it. I know it is obvious to us, but people sometimes need a reminder.

[Gustavo 'Gus' Carreno]

Hey O,

I know it is obvious to us, but people sometimes need a reminder.

Could not agree more with this statement!!!

Cheers,
Gus

[AlexTP]

Ru site openNet.Ru writes:
https://www.opennet.ru/opennews/art.shtml?num=60842

It writes:
There is no mention of the effect of the file cache on the test results. Probably, the low speed of ZIP is due to the order in which the tests were launched without regard to data caching in memory - the test with zip was launched with a cold cache, and the rest of the tests with a warm cache. Under normal conditions, Zstandard exhibits 3-5 times faster compression speeds than zlib and 2 times faster decompression, with 10-15% higher compression levels.

[O]

Thank you, Alex, for the heads-up.
I read the comment and try to answer them if possible.
About the note you quoted, on the footer of the post, there is a note at https://pack.ac/note/pack
"All corresponding official programs were used in an out-of-the-box configuration at the time of writing in a warm state."

[O]

My answer: https://www.opennet.ru/opennews/art.shtml?num=60842#55
If something is missing, please let me know.

[AlexTP]

Your answer is great and clear, thanks. Good luck with Pack.

[O]

Thank you very much for your kindness. Call for me if there happens to be a need. Such sites are not easy to find, and I like to give people a chance to understand Pack correctly.