Call a function from another gnome extension - gnome-shell

My question is simple, is that possible to call a function declared in another gnome extension from my own gnome extension ?

If using GNOME 3.36, you could use the ExtensionManager to lookup the extension.
const Main = imports.ui.main;
const ExtensionManager = Main.extensionManager;
// Looking up the extension
let someExtension = ExtensionManager.lookup('some#extension');
// Importing a module
const SomeModule = someExtension.imports.someModule;
But as pointed out by ptomato, this is a pretty bad idea, and I would count on this blowing up at some point. If you want to access live classes loaded from their extension you're probably on your own or will have to ask the author directly.

Yes. You just have to make sure the other GNOME Shell extension stashes the function somewhere that your extension can find it, like on the global object.
(But, please don't do this anyway. It's unpredictable whether someone will have a particular extension installed, and there's a reason that there isn't a dependency system for extensions.)

Related

How import a project in another project in golang

I need to call multiple constants found in another go project, already run the command
go install
and create the executable but I don't know how to import it into the project where I need it
You're going to want to read up on go modules pretty extensively - they're used everywhere in the go environment nowadays, and a very important concept to grasp.
Once you feel comfortable with that, if this code you speak of is not in module form yet, you'll need to make it that way. After that, the constants you need will need to be exported (i.e capitalized variable names) like this:
package mymath
// unexported variable - local scope only
var pi = 3.14159265
// exported variable - global scope when in a module
var Pi = 3.14159265
Now, you can call mymath.Pi to get that constant value.
go get project-github-or-smthelse-which-routes-to-source-code

Sourcing data into rstudio [duplicate]

This is meant to be a FAQ question, so please be as complete as possible. The answer is a community answer, so feel free to edit if you think something is missing.
This question was discussed and approved on meta.
I am using R and tried some.function but I got following error message:
Error: could not find function "some.function"
This question comes up very regularly. When you get this type of error in R, how can you solve it?
There are a few things you should check :
Did you write the name of your function correctly? Names are case sensitive.
Did you install the package that contains the function? install.packages("thePackage") (this only needs to be done once)
Did you attach that package to the workspace ?
require(thePackage) (and check its return value) or library(thePackage) (this should be done every time you start a new R session)
Are you using an older R version where this function didn't exist yet?
Are you using a different version of the specific package? This could be in either direction: functions are added and removed over time, and it's possible the code you're referencing is expecting a newer or older version of the package than what you have installed.
If you're not sure in which package that function is situated, you can do a few things.
If you're sure you installed and attached/loaded the right package, type help.search("some.function") or ??some.function to get an information box that can tell you in which package it is contained.
find and getAnywhere can also be used to locate functions.
If you have no clue about the package, you can use findFn in the sos package as explained in this answer.
RSiteSearch("some.function") or searching with rdocumentation or rseek are alternative ways to find the function.
Sometimes you need to use an older version of R, but run code created for a newer version. Newly added functions (eg hasName in R 3.4.0) won't be found then. If you use an older R version and want to use a newer function, you can use the package backports to make such functions available. You also find a list of functions that need to be backported on the git repo of backports. Keep in mind that R versions older than R3.0.0 are incompatible with packages built for R3.0.0 and later versions.
Another problem, in the presence of a NAMESPACE, is that you are trying to run an unexported function from package foo.
For example (contrived, I know, but):
> mod <- prcomp(USArrests, scale = TRUE)
> plot.prcomp(mod)
Error: could not find function "plot.prcomp"
Firstly, you shouldn't be calling S3 methods directly, but lets assume plot.prcomp was actually some useful internal function in package foo. To call such function if you know what you are doing requires the use of :::. You also need to know the namespace in which the function is found. Using getAnywhere() we find that the function is in package stats:
> getAnywhere(plot.prcomp)
A single object matching ‘plot.prcomp’ was found
It was found in the following places
registered S3 method for plot from namespace stats
namespace:stats
with value
function (x, main = deparse(substitute(x)), ...)
screeplot.default(x, main = main, ...)
<environment: namespace:stats>
So we can now call it directly using:
> stats:::plot.prcomp(mod)
I've used plot.prcomp just as an example to illustrate the purpose. In normal use you shouldn't be calling S3 methods like this. But as I said, if the function you want to call exists (it might be a hidden utility function for example), but is in a namespace, R will report that it can't find the function unless you tell it which namespace to look in.
Compare this to the following:
stats::plot.prcomp
The above fails because while stats uses plot.prcomp, it is not exported from stats as the error rightly tells us:
Error: 'plot.prcomp' is not an exported object from 'namespace:stats'
This is documented as follows:
pkg::name returns the value of the exported variable name in namespace pkg, whereas pkg:::name returns the value of the internal variable name.
I can usually resolve this problem when a computer is under my control, but it's more of a nuisance when working with a grid. When a grid is not homogenous, not all libraries may be installed, and my experience has often been that a package wasn't installed because a dependency wasn't installed. To address this, I check the following:
Is Fortran installed? (Look for 'gfortran'.) This affects several major packages in R.
Is Java installed? Are the Java class paths correct?
Check that the package was installed by the admin and available for use by the appropriate user. Sometimes users will install packages in the wrong places or run without appropriate access to the right libraries. .libPaths() is a good check.
Check ldd results for R, to be sure about shared libraries
It's good to periodically run a script that just loads every package needed and does some little test. This catches the package issue as early as possible in the workflow. This is akin to build testing or unit testing, except it's more like a smoke test to make sure that the very basic stuff works.
If packages can be stored in a network-accessible location, are they? If they cannot, is there a way to ensure consistent versions across the machines? (This may seem OT, but correct package installation includes availability of the right version.)
Is the package available for the given OS? Unfortunately, not all packages are available across platforms. This goes back to step 5. If possible, try to find a way to handle a different OS by switching to an appropriate flavor of a package or switch off the dependency in certain cases.
Having encountered this quite a bit, some of these steps become fairly routine. Although #7 might seem like a good starting point, these are listed in approximate order of the frequency that I use them.
If this occurs while you check your package (R CMD check), take a look at your NAMESPACE.
You can solve this by adding the following statement to the NAMESPACE:
exportPattern("^[^\\\\.]")
This exports everything that doesn't start with a dot ("."). This allows you to have your hidden functions, starting with a dot:
.myHiddenFunction <- function(x) cat("my hidden function")
I had the error
Error: could not find function some.function
happen when doing R CMD check of a package I was making with RStudio. I found adding
exportPattern(".")
to the NAMESPACE file did the trick. As a sidenote, I had initially configured RStudio to use ROxygen to make the documentation -- and selected the configuration where ROxygen would write my NAMESPACE file for me, which kept erasing my edits. So, in my instance I unchecked NAMESPACE from the Roxygen configuration and added exportPattern(".") to NAMESPACE to solve this error.
This error can occur even if the name of the function is valid if some mandatory arguments are missing (i.e you did not provide enough arguments).
I got this in an Rcpp context, where I wrote a C++ function with optionnal arguments, and did not provided those arguments in R. It appeared that optionnal arguments from the C++ were seen as mandatory by R. As a result, R could not find a matching function for the correct name but an incorrect number of arguments.
Rcpp Function : SEXP RcppFunction(arg1, arg2=0) {}
R Calls :
RcppFunction(0) raises the error
RcppFunction(0, 0) does not
Rdocumentation.org has a very handy search function that - among other things - lets you find functions - from all the packages on CRAN, as well as from packages from Bioconductor and GitHub.
If you are using parallelMap you'll need to export custom functions to the slave jobs, otherwise you get an error "could not find function ".
If you set a non-missing level on parallelStart the same argument should be passed to parallelExport, else you get the same error. So this should be strictly followed:
parallelStart(mode = "<your mode here>", N, level = "<task.level>")
parallelExport("<myfun>", level = "<task.level>")
You may be able to fix this error by name spacing :: the function call
comparison.cloud(colors = c("red", "green"), max.words = 100)
to
wordcloud::comparison.cloud(colors = c("red", "green"), max.words = 100)
I got the same, error, I was running version .99xxx, I checked for updates from help menu and updated My RStudio to 1.0x, then the error did not come
So simple solution, just update your R Studio

Load a Windows predefined icon with wxIcon

I'm trying to use IDI_INFORMATION with wxWidgets 2.8.11 (from wx/version.h) (for wxMemoryDC::DrawIcon). But first I have to load the icon: wxICON(IDI_INFORMATION) fails, LoadFile(wxT("IDI_INFORMATION")) also fails ( but LoadFile(IDI_INFORMATION) compiles and crashes, IDI_INFORMATION is a fake string pointer too tricky for wxWidgets). Hmmm, then I add some ifdefs to use Windows API: ::LoadIcon(NULL, IDI_INFORMATION) works, then wxIcon::SetHICON. While DrawIcon apparently works, the nasty surprise is that wxIcon::GetWidth, wxIcon::GetHeight return 0. Hmmm, let's get the size and use wxIcon::SetSize. Now it is finally done... wait!, but who's gonna destroy my icon? Not sure, so add the ifdef, SetHICON(NULL) and DestroyIcon.
The small question: do I have to destroy the icon myself?
The big question: is wxIcon entirely useless in this case?
PS After some debugging I discover that LoadFile(wxT("wxICON_INFORMATION")) works, wow!, but is it really multi-platform? Do I have read all the wx sources for drawing a standard icon?
The cross-platform solution is provided by wxArtProvider, just use its GetIcon() method with wxART_INFORMATION argument.

RadRails, Ruby, Content Assist and Methods

I am new to Ruby, and I am currently working with an API which is unfamiliar to me. In order to use code completion, which helps me learn, I installed RadRails in Eclipse. However, I am having trouble with Content Assist: specifically, the Content Assist does not reveal the methods for objects in the API.
For example, one of my objects, ins, represents a loaded XBRL instance document. If I run ins.methods, the list contains all of the methods I want, including those in the API (such as functions that allow me to access items in the instance):
...
item
item_all
item_all_groupby_vocab
item_all_map
item_by_vocab
item_ctx_filter
...
etc.
However, if I just type ins. with Content Assist enabled, it only shows options like:
dclone
gem
gem_original_require
JSON
Pathname(path)
...
etc.
which appear to be system options. As a result, the Content Assist exposes exactly zero of the methods I actually want to use. If I know the methods ahead of time and start typing them, I can get Content Assist to give them to me, eventually, by pressing Ctrl+Space. However, that requires me to know what I want ahead of time; since I am using this to explore the API, that doesn't work for me.
Does anyone know how to get RadRails/Eclipse to show me the correct methods?
Regards,
Matt
This is a general problem inherent to dynamic languages and IDEs/editors. The IDE has to guess at the type of the variable that the code assist is being invoked upon, and from that generate the list of applicable methods.
IRB has type information at runtime, so it knows what methods apply. The IDE is trying to guess the type by analyzing your code statically (not running it).
Having said that, the IDE should often be able to guess correctly. Providing the larger context of the snippet of code that this is being invoked on would be helpful to look into whether or not we could provide helpful content assist on this object. You may want to file a ticket with the version number, and the sample code here: http://aptana.com/r/apbugs

LSM-Howto: Kernelmodule with non exported functions

I'm currently writing a Linux Kernel module which depends on the Linux Security Modules (LSM) at the moment it is nothing really, I just wanted to print out a simple message whenever a file is opened. The problem is: To register to the hook I need the function register_security, which - I found out after googleing - isn't exported anymore and thus can't be used by loadable kernel modules - only by modules which are compiled directly into the kernel.
Of course this makes sense for a security module, but it suckes for me developing.
So now the question to you: Is there a way of patching my module into the kernel? I mean, I don't want to recompile my kernel after every bugfix or for every minor change. I could live with rebooting my pc for every new try, but recompiling would take a little bit to long I guess..
Edit: Hm, noone yet :( I just had an idea, maybe someone can tell me if it's good or not: Can't I just add the EXPORT_SYMBOL in the kernel source for the functions I need, then recompile it and then add my code as a module? Of course this would be just for testing and debugging
Can't you just use fsnotify in kernel, or fanotify from user space?
It's not generally a good idea to export functions that the author didn't think it would be a good idea to export. If you call a function that isn't part of the public interface and that function has a side effect, you will probably break things. Besides, your module won't work on other machines, but maybe you don't care about this.
No, there is not. When a symbol is not exported, the in-kernel linker will not be able to find it. But adding the export to the kernel you use for testing should be OK. You can add your module to the export list by adding it to ./include/linux/Kbuild.
Also if testing in (user-mode-linux)[http://user-mode-linux.sourceforge.net/] or in virtual box, recompiling whole kernel might not be that big problem.
This may be a bit late as I see your question a while back. What I found to be a good solution is to write a module that you compile into the kernel and just exports the couple of functions you what to play with.
For example
//REGISTER FILE_PERMISSION
static void k_register_file_permission(int (*my_file_permission) (struct file *file, int mask)) {
my_file_permission_func = my_file_permission;
}
EXPORT_SYMBOL(k_register_file_permission);
Then you can just call k_register_file_permission from your kernel module, handy durring the development process.
You would also need a function like
int k_file_permission (struct file *file, int mask) {
if(my_file_permission_func == NULL)
{
//do nothing
}
else
{
return my_file_permission_func(file, mask);
}
return 0;
}
That you would register with the LSM at boot time.

Resources