I have a few questions on zlib module, to be used with files under 40MB:
What kind of options should be used in zlib.gzipSync() for fastest zipping (compression level does not matter)?
Which default values is used, if options is not passed to the method?
Is this method returns Buffer?
What kind of extension and mime type should be used for final result?
Update: How to pass a file name? (So after unzipping file has name and extension)
Asked because reference is not expressive.
Yeah, not much to go on in that documentation.
I recommend that you look at the zlib manual (the zlib.h source file) for information on the noted parameters and operations.
The fastest compression would be level 1.
The default compression level is 6. Other defaults can be found in zlib.h.
There does not appear to be an interface to deflateSetHeader(), which would be required to insert a file name in a gzip header.
The docs describe the options object used for every zlib call. They also point you to the zlib manual which describes those options in great detail.
The fastest level is 0, which means no compression. However, this would be silly, since you may as well skip gzipping altogether. 1 means "some compression with best speed."
That said, don't use gzipSync. We don't do things synchronously in node. If you're looking to write the compressed data to a file, do:
var compressor = zlib.createGzip({level: 1});
compressor.pipe(fs.createWriteStream('output.gz'));
compressor.end(inputData);
Related
I am creating a npm library where I need to read the files of the folder from where my library function were invoked from command line and then operate on those files.
By operation I mean to check if a variable exist, if a function exists, modifying variable, function,etc.
The files will be a Typescript files.
Any help on how to proceed will be great.
Seems like you need some kind of AST parser like Esprima or babel-parser. These tools can parse the content of JS/TS files, build the abstract syntax tree that can be traversed, modified and converted back to the source code.
There's a lot of useful tools available in Babel toolset that simplifies these operations. For example, babel-traverse simplifies searching the target statement or expression, babel-types that helps to match the type of the AST nodes and babel-generator that generates the source code from the AST.
It's going to be very difficult to get these answers without running the files.
So the best approach is probably to just import the files as usual and see what side-effects running the files had. For example, you can check if a file exported anything.
If this doesn't solve your problem, you will have to parse the files. The best way to do that might be to use the typescript compiler itself:
https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API
In CMake, we can use find_dependency() in an package -config.cmake file to "forwards the correct parameters for QUIET and REQUIRED which were passed to the original find_package() call." So, naturally we'll want to do that instead of calling find_package() in such files.
Also, for dependency on a threads library, CMake offers us the FindThreads module, so that we write include(FindThreads), prepended by some preference commands, and get a bunch of interesting variables set. So, that's preferable to find_package(Threads).
And thus we have a dilemma: What to put in -config.cmake files, for a threads library dependency? The former, or the latter?
Following a discussion in comments with #Tsyarev, it seems that:
find_package(Threads) includes the FindThreads module internally.
... which means it "respects" the preference variables affecting FindThreads behavioe.
so it makes sense, functionally and aesthetically, to just use find_package() in your main CMakeLists.txt and find_dependency() in -config.cmake.
You can find a mention of it here: https://code.visualstudio.com/api/language-extensions/language-server-extension-guide
however without any explanation. I couldn't find information about it by googling.
What is the purpose of a .clientrc file?
As mentioned in the comments, ".clientrc" was just chosen as an example file name.
If you google site:code.visualstudio.com clientrc, that page is the only search result. And googling site:github.com/microsoft/vscode "clientrc", all the results are about example code (and most are about that example code specifically).
The .*rc file name pattern is a common convention for application-specific configuration files. There's a baeldung article on it:
Names including rc often signify files or directories of files with code. Specifically, this code consists of commands that are meant to run when a program is executed. Indeed, that program can be an application, but it can also be a whole operating system.
Because of this, the original rc affix and extension both meant “run commands”. In particular, a widely accepted source of the term is the Compatible Time-Sharing System (CTSS)
I'm trying to get the file extension for the valid "audio/wav" mime type.
Using this code
MimeTypes mimeTypes = TikaConfig.getDefaultConfig().getMimeRepository();
String extension = mimeTypes.getDefaultMimeTypes().forName("audio/wav").getExtension();
The extension I get is the empty string.
However, using the "audio/x-wav" extension works.
Is this the expected behavior?
TL; DR
Yes, this is the expected behavior.
x- MIME subtypes are usually for formats which are not yet standardized. The MIME types corresponding to WAV format are audio/vnd.wave, audio/wav, audio/wave, audio/x-wav (see here). Some browsers accept more or less MIME types. Apache servers usually send WAV as x-wav, even though I don't know why.
The official MIME type is now audio/vnd.wave, so you might try it and see if it works.
Sources: here
This is a bug in older versions of Tika.
You need to use a newer version of Apache Tika to get the correct behaviour. (1.15.1 or 1.16 should do it). As taken from the tika-parsers/src/test/java/org/apache/tika/mime/TestMimeTypes.java unit test:
assertType("audio/vnd.wave", "testWAV.wav");
(That unit test verifies that the official mime type is the one detected, other aliases like audio/wav will generally be transparently mapped onto the canonical one)
Alternately, if you're stuck on an old Tika version, you should largely be OK to swap out the tika-mimetypes.xml file for the latest version, though if you're swapping it out in an much older version of Tika it's best to re-run the unit tests to ensure you haven't broken anything in the process!
recently i've been asked to implement config files for my system, config for each environment.
When i wanted to use the config i noticed that i dont have it typed, at least not in easy way..
So i created an index file which import and export the config adding an interface to it.
I wonder if i can add a type to my config (somehow) which will force the developers to stick to it and also provide us a type at compilation time.
Its like to have a config.ts file instead of config.json (maybe that what i should do?)
Thanks!
Yes you can - use json schema for this purpose.
To ensure your develpers have not messed up the data - use one of many available validators (i find this one to work pretty nice) to verify json object you read from config file.
Some IDE (vscode for example) support json schemas and can validate it on the fly.
You can have your config stored in *.ts file as exported const variable. Then after requiring it verify it with validator. Unfortunately this approach will not give you errors at compilation type.