I found that the naming conversion of node is a little strange. For instance, in the file system module, the read link function's letters are all lower cased:
fs.readlink
But the read file function's name are camelized:
fs.readFile
It confused me. After mistyping for times, I think I shoud ask. So is there a naming convention to help me memorize the api names?
Node's default convention is camelCase.
But functions in file system module named according to their respective POSIX C interface functions.
For example readdir, readlink.
These functions names are well-known by Linux developers and therefore it's often decided to use them as is(as single word), without camelizing.
Always go camel case, almostly everyone does it.
The Node core does have various disparities in this case, like the one you mentioned, process have some too (process.get*() x process.memoryUsage()), and others; but the majority of the core methods are camel cased.
Until you memorize the ones who are not camel cased, I'd say that it's a good tip to always develop with the docs open ;)
Related
Different people have told me that in order to improve my Python programming skills, it helps to go and look how existing projects are implemented. But I am struggeling a bit to navigate through the projects and find the parts of the code I'm interested in.
Let's say I'm using butter of the scipy.signal package, and I want to know how it is implemented, so I'm going to scipy's github repo and move to the signal folder. Now, where is the first place I should start looking for the implementation of butter?
I am also a bit confused about what a module/package/class/function is. Is scipy a module? Or a package? And then what is signal? Is there some kind of pattern like module.class.function? (Or another example: matplotlib.pyplot...)
It sounds like you have two questions here. First, how do you find where scipy.signal.butter is implemented? Second, what are the different hierarchical units of Python code (and how do they relate to that butter thing)?
The first one actually has an easy solution. If you follow the link you gave for the butter function, you will see a [source] link just to the right of the function signature. Clicking on that will take you directly to the source of the function in the github repository (pinned to the commit that matches the version of the docs you were reading, which is probably what you want). Not all API documentation will have that kind of link, but when it does it makes things really easy!
As for the second question, I'm not going to fully explain each level, but here are some broad strokes, starting with the most narrow way of organizing code and moving to the more broad ways.
Functions are reusable chunks of code that you can call from other code. Functions have a local namespace when they are running.
Classes are ways of organizing data together with one or more functions. Functions defined in classes are called methods (but not all functions need to be in a class). Classes have a class namespace, and each instance of a class also has its own instance namespace.
Modules are groups of code, often functions or methods (but sometimes other stuff like data too). Each module has a global namespace. Generally speaking, each .py file will create a module when it is loaded. One module can access another module by using an import statement.
Packages are a special kind of module that's defined by a folder foo/, rather than a foo.py file. This lets you organize whole groups of modules, rather than everything being at the same level. Packages can have further sub-packages (represented with nested folders like foo/bar/). In addition to the modules and subpackages that can be imported, a package will also have its own regular module namespace, which will be populated by running the foo/__init__.py file.
To bring this back around to your specific question, in your case, scipy is a top-level package, and scipy.signal is a sub-package within it. The name butter is a function, but it's actually defined in the scipy/signal/_filter_design.py file. You can access it directly from scipy.signal because scipy/signal/__init__.py imports it (and all the other names defined in its module) with from ._filter_design import * (see here).
The design of implementing something in an inner module and then importing it for use in the package's __init__.py file is a pretty common one. It helps modules that would be excessively large to be subdivided, for ease of their developers, while still having a single place to access a big chuck of the API. It is, however, very confusing to work out for yourself, so don't feel bad if you couldn't figure it out yourself. Sometimes you may need to search the repository to find the definition of something, even if you know where you're importing it from.
What on Earth is findFiles?
It's in the vscode API documentation you didn't read on file-system support.
Choice of weapons
VS Code is a node application, and so are extensions. Everyone knows this. So the first time we need to manipulate a file, we import fs, which works, and we try some file manipulation, which works. At this point we congratulate ourselves and the VS Code team on transfer of skills, and we stop thinking about it because we know exactly how to do this.
Why would anyone doubt this choice? By all appearances Node fs is an outstanding solution. It's well documented, widely understood and cross-platform. Nothing could possibly go wrong.
Everything has gone wrong
Tempora mutantur, nos et mutamur. Things like Docker and WSL mean that even Windows users on a single host are quite likely to use a remote filesystem. But Node fs, and by extension your extension, only knows about the filesystem in which it was launched.
You need file-system redirection. That implies a proxy at the other end, and some sort of indirection so you can specify which filesystem on what host using which authentication. Once you start thinking about this you wonder why the VS Code team doesn't publish an API for whatever magic they use to do this themselves.
Remember those annoying vscode.Uri objects you have to unpick to get fsPath? The ones returned by all the file system UI interaction events? They have all that metadata in them.
Cut to the chase
If you look at vscode.workspace.fs ("fs"?! that's a clue!) you will find it exports all the methods you need to read and write files and directories. All of these methods take a vscode.Uri. At this point I hope you've connected the dots yourself. Yep, remote filesystem access for the masses (if you can call extension writers the masses).
You still haven't answered the question, Pete: what is findFiles?
Oh. Well. Okay. Right, I expect you all know what globby is and what it's for. Obviously you can't use it on a remote filesystem. And your extension depends on it. Guess what this is for:
findFiles(
include: GlobPattern,
exclude?: GlobPattern | null,
maxResults?: number,
token?: CancellationToken
): Thenable<Uri[]>
That's globby for remote filesystems, what's your problem?
My problem is it takes a single pattern, not an array of patterns like globby.
While I can work around that by comma separating patterns and surrounding that with curly braces like so {**/*.dll,**/*.exe} that falls apart when the patterns already use this syntax. You're not allowed to nest it. And my users are very likely to want to use patterns like **/*.{exe,dll,pdb,hex,bin,pdf,png,jpg,jpeg,gif,pfx}
So what is it you want, Pete?
So far this is all just you showing off. What were you hoping for in an answer?
Well, the obvious solution is to expand patterns containing expressions into multiple literal expressions, before combining them into a single non-nested expression. But that's boring and hard. I hate writing Regexes.
Or maybe it's not necessary and there's a solution I haven't noticed. I don't know. Help!
[F]alls apart when the patterns already use this syntax. You're not allowed to nest it.
I think what you can do is just process the nested syntax yourself and output non-nested syntax which has the meaning which you require.
E.g. suppose {{a,b},c}x means {a,b}x cx, which then means ax bx cx.
Observe that {a,b,c}x also means ax bx cx and so under this notion of nesting, {{a,b},c} is equivalent to {a,b,c}.
If that's the desired semantics, you can just parse the nested notations in your pattern, and flatten any nesting.
A brace expansion library already exists for Node. It is mysteriously named braces and is available from npm or from its repository on GitHub.
It operates on a string and returns an array of strings. It can expand recursive brace expressions, so a loop is not necessary for my application.
const toxicExcludes = `{${excludes.join(",")}}`; // may contain nested braces
const safeExcludes = `{${braces.expand(toxicExcludes).join(",")}}`;
I would like to know if it is possible to list files and folders inside a given folder from within the Linux Kernel. I bet there is a way.
I have searched on-line and gave it few shots, but still could not do it.
Thank you!
Reacting your comment: your question isn't about file reading, but getting the entries of a directory. About your last sentence: yes, every filesystem implements the readdir() function, so it would be filesystem-independent.
In my opinion, you need the following steps:
Research, how to write kernel modules. Tthere are very many tutorials on the net, including step-by-step tutorials with well commented examples.
Write a simple module, which printk()-s some simple text in its initialization function.
Research, how can you call system calls from a kernel module. It is probably not so simple, as from user space, but nearly surely possible.
The simplest way to pass through the path to the directory in a module parameter. Linux kernel modules can have multiple parameters, whose processing is very well automatized (essentially, you can directly bind the parameter name to static variables in the module).
After your module can call system calls, and has its input, you can now open this directory in its init function with the opendir() call. Then read its content (see readdir()), and finally output the result with printk().
Probably there will be some obstacles, for example maybe you can't use syscalls from the module init function, or similar, but none of them will be really hard.
I am trying to implement a spin lock using the test_and_set_bit function. I found a bitops.h file which consisted of this function. However, in my current kernel version which is 3.0, the function is not included in that header file i.e, bitops.h. Any anyone provide some references where I can find that?
Not sure if I totally understand your question, but including <linux/bitops.h> should bring in the definition of test_and_set_bit(). The actual definition of the function is not in include/linux/bitops.h but it is picked up via the include of <asm/bitops.h> that is in the linux/ version of the include.
So to see the actual definition of test_and_set_bit() you can look in arch/arm/include/asm/bitops.h or arch/x86/include/asm/bitops.h (or whatever other architecture you're interested in).
By the way, there's no reason to need to implement your own spinlock -- the kernel has (of course) the standard spinlock_t and also functions like bit_spin_lock() that use a single bit as a lock.
I'm having hard time deciding which name to choose for my method. I think they both are pretty much self-explanatory, but the latter is faster to type, so, my current preference is supportedModes(). What do you think?
To me, getSupportedModes implies simple retrieval, whereas if there is some actual logic involved to work them out, something like determineSupportedModes or calculateSupportedModes may be better. The name should describe what the function does. Brevity is not a major consideration with modern IDEs with some form of autocomplete.
Different languages also have their own conventions. For example, a function called calculateSupportedModes in Java would normally be called CalculateSupportedModes in C# or VB.
I would prefer the more explicit which is getSupportedModes. You don't want other developers to second guess what the method does.
Functions that act on more than just their passed arguments should be named as actions.