Is it possible to configure jedi-vim to respect __all__ variable inside a module (like __init__.py)? So, when I use autocomplete on an imported package, anything inside which is not listed in the __all__, and is not a special variable/method, is hidden?
Does not work and will not work in the near future. Reason: I'm the author.
It's quite complicated to understand __all__, because it can basically be generated by any Python code.
I would probably accept a pull request, but only if it works with numpy.
Related
I am attempting to install a package (sldnfdraw) in SWI-Prolog, but I cannot find a way to specify an installation directory (ie where I want it to be installed).
The documentation seems to indicate one can choose the package directory, but I haven't had luck in doing so. Admittedly, I am fairly new to Prolog and may be overlooking something obvious. Nonetheless, I have searched for answers in all the usual places (Stack Overflow, documentation) with no luck.
I attempted to install the package sldnfdraw by calling pack_install(sldnfdraw). This would have created a directory at $HOME/lib/swipl/pack. I then attempted various incarnations of pack_install(sldnfdraw, $PREF_DIR). where $PREF_DIR is the absolute path of the directory where I wanted the package to be installed. The documentation referenced some way of passing options to functions, but it did not specify a method for doing so. Given the limited resources available on Prolog (and this specific implementation) I find myself at a dead end. Hopefully someone can point me in the right direction.
The function for specifying the installation directory is package_directory/1. In order to use this in conjunction with pack_install/2, I needed to enclose it in brackets. Therefore the query to install package sldnfdraw into directory $PREF_DIR looks like
pack_install(sldfndraw, [package_directory($PREF_DIR)]).
I'm working on a library with multiple layers of functionality. I want developers to be able to import only the parts they need, ie mylib-core, mylib-feature1, mylib-feature2, etc. Each lives in its own git repo. I'd also like to provide a simple mylib package which exposes a default set of functionality which is useful for developers new to the library. See d3.js version 4+ for something very similar to what I'm trying to accomplish.
The problems I've run into are
Apparently you can't share a package name between packages. This is a problem because it would be nice to import all the desired repos and then simply have everything available under the mylib name.
I don't see an obvious way to re-export functionality, in order to build the default mylib package.
Are there good solutions or a more idomatic go way to accomplish what I'm shooting for?
Answering your question, there is no idiomatic way of doing what you want. It is common in JavaScript to import a library and export its members without interference. This is not the case in Golang.
I advise you to host your whole library under a single repo, and split the functionality to packages. The Go compiler will only compile and use the imported packages.
And a tip for the future, Go is very different than almost any other language you previously know 😅
I want to make some changes to the Go crypto/tls standard library.
Is making a copy of crypto/tls in the vendor folder a good way to do this?
It almost works, it seems the vendored is copy used when I compile the application (Caddy webserver). Apart from one error I get:
go/src/github.com/user/caddy/caddytls/httphandler.go:40: cannot use "vendor/crypto/tls".Config literal (type *"vendor/crypto/tls".Config) as type *"crypto/tls".Config in field value
Is there a way of casting to get around this one error? Doesn't sound like good practice to me though.
I would have thought that the vendored copy would always be used, but it seems something is still using the standard crypto/tls library? (I think "net/http" is. Do I have to vendor this too?)
I actually had to do that. The most practical way is to copy and modify the package (as well as its internal dependencies) - this includes some import paths. And it is not really vendored (vendoring is basically using unmodified packages, otherwise vendoring tools will not work), it is a fork, under a different name. I would guess that caddy does not need the modified version - if it does, you need to fork and modify caddy as well.
It goes without saying, but be extremely careful when modifying crypto/tls package - I for example has to make a minimal change that does not really modify TLS operation (I needed to be able to derive key material from the session master secret and randoms).
Also, you have to fully realize that this has significant cost - when a new version of go is out, one that potentially has updates for the crypto/tls package or its dependencies, you will have to apply your changes once again, manually. Committing a diff between the vanilla version and your version helps. I don't think this is at all practical for non-trivial changes (mine were quite limited - a new public field in Config, few lines of code in handshakes, a new interface).
I need the same functionality. It seems like the crypto/tls package does not allow the reading of custom TLS extensions added from the client side in the ClientHello payload. It would be great to be able to check for any custom extensions and then marshal them out accordingly.
It is a pity that this is not a separate package as we could then in our go.mod file be able to use replace to specify a custom TLS package.
e.g
replace golang.org/x/crypto/tls => ./tls
Then running go mod vendor.
Where the ./tls is my local version with the changes applied.
I had to create an extension for contacts import into Thunderbird. This part is done, now I need to import tasks. But tasks/calendar are not handled by default in thunderbird, so I need Lightning. Here is my problem. I have no idea if I can detect an other extension and use some of its features.
Easiest way to detect Lightning is checking whether its interfaces are defined, e.g.:
if ("calICalendar" in Components.interfaces)
alert("Lightning is installed!");
Using its features is a different thing - depends on what you are trying to do. For most things importing Lightning's modules and using them should do:
Components.utils.import("resource://calendar/modules/calUtils.jsm");
alert(cal.getCalendarManager().getCalendars());
I don't think it is properly documented however, you will have to look at the source code.
Is there a way to make emacs pull autocompletions of ruby methods the way Eclipse and NetBeans do? That is if I type File. and press CTRL-space in Eclipse I will get a list of File methods. Same with variables. I have installed autocomplete plugin, ruby-mode, rinari and cedet, but so far it will complete local variable and method names, but will not native ones.
I think you need something like RSense. You might also like the more general auto complete mode.
I'm not familiar with ruby, but if by "native methods" you mean stuff in some system library, there are a couple options for extending CEDET to do the work.
If there are ruby files somewhere that have all that code in them, and if ruby supports some sort of "include" or "import" statement, then you need to add that location to the include path for ruby. This probably requires a change the the ruby source code to add a new system include path. You can see examples in semantic-c.el. You may also need to override the function semantic-tag-include-filename to convert the include into a findable filename.
If there are no includes, and there is just some ruby interpreter that knows all this stuff, then you will instead need to code up a full ruby "omniscient" database, similar to semanticdb-el.el. It will need a way to query ruby for various things and return them as answers.
Any such enhancements would be welcome back in the ruby support in CEDET's contrib area.
Ruby is an interpreted language, making it difficult to do certain things, such as autocompletion. How would you know what the object type is, if it's not defined? Therefore, premade solutions are limited or nonexistent. Even the autocompletion in Netbean/Eclipse will only work on class methods (if I'm not mistaken).