It is difficult to find an appropriate title because I do not understand why I have the following issue.
When I require my package, I would like to assign a specific function according to some packages. The idea is to set a variable as follow:
(cond ((find-package 'foo) (setf *special-function* #'foo:foo-function))
((find-package 'bar) (setf *special-function* #'bar:bar-function))
(t (warn "The package FOO or BAR is required to enable the special function.")))
Then, the evaluation of this piece of code returns:
There is no package named "FOO" with CCL
Package FOO does not exist with SBCL
The main reason I want to do that is that it exists different packages which provide the same function, and I want to let the user be free to make its own choice by loading the package FOO or BAR (with a preference according to the order in the condition clauses).
Think about the execution/evaluation of the following form:
(if (find-package 'foo)
(foo:foo-function))
Lisp
reads the code
and then evaluates the code.
Your error happens in phase 1: Reading. The form can't be read, when the package does not exist.
A typical way around it would be this:
(if (find-package 'foo)
(funcall (find-symbol "FOO-FUNCTION" "FOO")))
We are then looking up the symbol at runtime. Note that function and package names are by default in uppercase.
In your case you would need to call
(symbol-function (find-symbol "FOO-FUNCTION" "FOO"))
to get the function object. Note though that sometimes it's preferred to just get the symbol.
funcall and apply can call global functions as function object or as symbol:
(funcall 'sin 2.1d0)
or
(funcall #'sin 2.1d0)
Thus when the thing needs to be called later, a symbol offers another source of indirection and will point to the current definition, where the function object can also be an older version of the function.
This almost looks like you want to define a wrapper function for functionality available under different names in different implementations.
Since, as Rainer wrote, we need to distinguish the cases already at read time, we can use reader conditionals for that. Conveniently, all implementations push their name onto *features*, so that we can do it like this:
(defun special-function (&rest args)
#+sbcl (apply #'foo:foo-function args)
#+ccl (apply #'bar:bar-function args)
#-(or sbcl ccl) (error "not implemented))
If instead you want to allow different libraries to fill in your functionality, you can either rely on the user to load one of those before loading your system, if those libraries push their own symbols to *features*, or you can define little wrapper systems that add the optional dependency:
Example: your (asdf) system is named yoursys, then you could define another system yoursys/foo-backend and yoursys/bar-backend, both of which would set your special-function to their respective implementations, and depend on the needed library.
Related
I'm writing a small tool that should be able to inspect an arbitrary process of interest and check if any of its statically linked functions were trampolined. (An example of a trampoline could be what Microsoft Detours does to a process.)
For that I parse the PE header of the target process and retrieve all of its imported DLLs with all imported functions in them. Then I can compare the following between DLLs on disk and the DLLs loaded in the target process memory:
A. Entries in the Import Address Table for each imported function.
B. First N bytes of each function's machine code.
And if any of the above do not match, this will most certainly mean that a trampoline was applied to a particular function (or WinAPI.)
This works well, except of one situation when a target process can import a global variable instead of a function. For example _acmdln is such global variable. You can still find it in msvcrt.dll and use it as such:
//I'm not sure why you'd want to do it this way,
//but it will give you the current command line.
//So just to prove the concept ...
HMODULE hMod = ::GetModuleHandle(L"msvcrt.dll");
char* pVar = (char*)::GetProcAddress(hMod, "_acmdln");
char* pCmdLine = pVar ? *(char**)pVar : NULL;
So, what this means for my trampoline checking tool is that I need to differentiate between an imported function (WinAPI) and a global variable. Any idea how?
PS. If I don't do that, my algorithm that I described above will compare a global variable's "code bytes" as if it was a function, which is just a pointer to a command line that will most certainly be different, and then flag it as a trampolined function.
PS2. Not exactly my code, but a similar way to parse PE header can be found here. (Search for DumpImports function for extracting DLL imports.)
Global variables will be in the .data section not the .text section, in addition the section will not have execute permissions if it's not a function. Therefore you can use both of these characteristics to filter.
I am writing an XS module. I allocate some resource (e.g. malloc() or SvREFCNT_inc()) then do some operations involving the Perl API, then free the resource. This is fine in normal C because C has no exceptions, but code using the Perl API may croak(), thus preventing normal cleanup and leaking the resources. It therefore seems impossible to write correct XS code except for fairly simple cases.
When I croak() myself I can clean up any resources allocated so far, but I may be calling functions that croak() directly which would sidestep any cleanup code I write.
Pseudo-code to illustrate my concern:
static void some_other_function(pTHX_ Data* d) {
...
if (perhaps) croak("Could not frobnicate the data");
}
MODULE = Example PACKAGE = Example
void
xs(UV n)
CODE:
{
/* Allocate resources needed for this function */
Data* object_graph;
Newx(object_graph, 1, Data);
Data_init(object_graph, n);
/* Call functions which use the Perl API */
some_other_function(aTHX_ object_graph);
/* Clean up before returning.
* Not run if above code croak()s!
* Can this be put into the XS equivalent of a "try...finally" block?
*/
Data_destroy(object_graph);
Safefree(object_graph);
}
So how do I safely clean up resources in XS code? How can I register some destructor that is run when exceptions are thrown, or when I return from XS code back to Perl code?
My ideas and findings so far:
I can create a class that runs necessary cleanup in the destructor, then create a mortal SV containing an instance of this class. At some point in the future Perl will free that SV and run my destructor. However, this seems rather backwards, and there has to be a better way.
XSAWYERX's XS Fun booklet seems to discuss DESTROY methods at great length, but not the handling of exceptions that originate within XS code.
LEONT's Scope::OnExit module features XS code using SAVEDESTRUCTOR() and SAVEDESTRUCTOR_X() macros. These do not seem to be documented.
The Perl API lists save_destructor() and save_destructor_x() functions as public but undocumented.
Perl's scope.h header (included by perl.h) declares SAVEDESTRUCTOR(f,p) and SAVEDESTRUCTOR_X(f,p) macros, without any further explanation. Judging from context and the Scope::OnExit code, f is a function pointer and p a void pointer that will be passed to f. The _X version is for functions that are declared with the pTHX_ macro parameter.
Am I on the right track with this? Should I use these macros as appropriate? In which Perl version were they introduced? Is there any further guidance available on their use? When precisely are the destructors triggered? Presumably at a point related to the FREETMPS or LEAVE macros?
Upon further research, it turns out that SAVEDESTRUCTOR is in fact documented – in perlguts rather than perlapi. The exact semantics are documented there.
I therefore assume that SAVEDESTRUCTOR is supposed to be used as a "finally" block for cleanup, and is sufficiently safe and stable.
Excerpt from Localizing changes in perlguts, which discusses the equivalent to { local $foo; ... } blocks:
There is a way to achieve a similar task from C via Perl API: create a pseudo-block, and arrange for some changes to be automatically undone at the end of it, either explicit, or via a non-local exit (via die()). A block-like construct is created by a pair of ENTER/LEAVE macros (see Returning a Scalar in perlcall). Such a construct may be created specially for some important localized task, or an existing one (like boundaries of enclosing Perl subroutine/block, or an existing pair for freeing TMPs) may be used. (In the second case the overhead of additional localization must be almost negligible.) Note that any XSUB is automatically enclosed in an ENTER/LEAVE pair.
Inside such a pseudo-block the following service is available:
[…]
SAVEDESTRUCTOR(DESTRUCTORFUNC_NOCONTEXT_t f, void *p)
At the end of pseudo-block the function f is called with the only argument p.
SAVEDESTRUCTOR_X(DESTRUCTORFUNC_t f, void *p)
At the end of pseudo-block the function f is called with the implicit context argument (if any), and p.
The section also lists a couple of specialized destructors, like SAVEFREESV(SV *sv) and SAVEMORTALIZESV(SV *sv) that may be more correct than a premature sv_2mortal() in some cases.
These macros have basically been available since effectively forever, at least Perl 5.6 or older.
What are some use cases of do nothing function (in C) like:
dummy() {}
I am reading "The C programming Language" by K&R and in chapter 4 (Functions & Program Structures) , it mentions that
A do-nothing function like this (shown above) sometimes useful as a place holder during program development.
Can anyone explain what author means by that and uses of these types of functions?
A function that does nothing (yet) is an indicator that something should be done, but hasn't been implemented yet.
Have a look at programming idioms like "Skeleton", "dummy code", "mock objects", etc. It is a very common technic that let you test the whole architecture of your program without having implement every details.
Suppose you have an application that is able to save results in a file by calling a function save(), you would like to be able to test the application without the necessity to really save results into a file. So the function save() can be, in a first approximation an empty one! It is very common to write like (pseudo-code here):
save() {
print "save() not yet implemented";
}
to be able to track the calls.
You already have received the answer(s), but just to elaborate on why part, let me add my two cents.
If you try to use a function (call a function) which does not have a definition, linker will throw undefined reference error, because it will not able able to find the actual function definition anywhere in the given object file(s) to link to.
So, sometimes in the development phase, when you need to call an API which is yet to be implemented (or not available till time), a dummy function definition is added, which
either does nothing meaningful
or returns a fixed value
just to compile and check (test) the working of the caller function (module). Without the dummy function definition, the code for the caller function will throw the error.
When you're writing code to explain something, it is better to omit secondary functions, so the reader focuses on the problem and not on the details.
Instead when you write a real program I prefer to create the secondary functions first, test them and alter set all focus on the mainstream.
Assume I have two packages in R, the first named foo, the second named bar. I want to include a C function in foo and share that functionality with bar in a way that is platform independent and consistent with the CRAN policies.
What is the preferred method of doing this, and how should I go about using function registration and dynamic libraries?
The purpose of my question is that, even though I read through all the documentation I could find, there is nothing that occured to me as the obvious thing to do, and I am unsure what the most sustainable course of action is.
Example:
Assume that in one package foo, I define a C function addinc which adds two numbers.
#include <R.h>
#include <Rinternals.h>
SEXP addinc(SEXP x_, SEXP y_) {
double x = asReal(x_);
double y = asReal(y_);
double sum = x + y;
return ScalarReal(sum);
}
In the same package, I can try calling addinc in an R function named addinr via the .Call interface.
addinr <- function(x,y){
.Call("addinc", x, y, PACKAGE="foo")
}
However, when building, checking and installing the package, running addinr returns the error below, presumably because the function is not yet registered within R.
library(foo)
addinr(1,2)
Error in .Call("addinc", x, y, PACKAGE = "foo") :
"addinc" not available for .Call() for package "foo"
As it seems to me, the easiest way to solve this is to build a dynamic library for the compiled code by adding useDynLib(foo) to foos NAMESPACE file.
This appears to solve the problem because I can now call addinr() without problems. Moreover, I can run .Call("addinc", ..., PACKAGE="foo") directly from within R.
My real question, however, occurs when a second package, say bar, is supposed to use foos addinc. For example, assume that bar defines a function multiplyinr as follows.
multiplyinr <- function(x,y){
ans <- 0
for(i in 1:y) ans <- .Call("addinc", ans, x, PACKAGE="foo")
ans
}
This, in fact, works completely fine, and I can call multiplyinr within R. However, when building and checking bar, I receive a Note complaining about the fact that bar is calling foreign language functions from a different package.
Foreign function call to a different package:
.Call("addinc", ..., PACKAGE = "foo")
See chapter ‘System and foreign language interfaces’ in the ‘Writing R Extensions’ manual.
According to this question, the package bar would not be suitable for submission to CRAN because using .Call() in this way is not considered "portable" as explained in the Writing R Extensions manual.
In conclusion, the simple solution of having foo include a useDynLib(foo) in its NAMESPACE file does not quite seem to cut it. Therefore my question: What is the preferred method to share a C function with other packages?
Moreover:
Is using useDynLib() truly dangerous or inconsistent with the CRAN policies? What is the purpose of declaring useDynLib() in the NAMESPACE file as an alternative to registering and building the shared library manually?
Would manually registering the C function and bulding the shared library change anything (i.e., using R_RegisterCCallable() or R_registerRoutines())?
The general idea is that the 'native symbol info' objects created by using e.g. useDynLib(<pkg>, <symbol>) are not part of the public API of a package, and so client packages should not be calling them directly (it's assumed they could be changed in future revisions of the package).
There are two ways to 'export' a compiled routine for use by client packages:
Just export an R wrapper function in foo that calls the native routine directly, or
Use the R_RegisterCCallable() / R_GetCCallable() pair of functions to get a pointer to the function you want. (Package foo would call R_RegisterCCallable() to make some function available; client package bar would call R_GetCCallable() to get a pointer to that function)
In other words, if a package author 'registers' their C functions, they're declaring that to be part of the public C API of their package, and allow client packages to use / call that through this interface.
I've written a function which calculates the eigenvalues of a 2*2 matrix. It takes a 2*2 matrix as an argument and returns 2 eigenvalues via a 2-element array. I have declared the function in the program unit like this:
real, dimension(2), external :: eigenvalues
But it won't compile, it comes up with this error:
Error: EXTERNAL attribute conflicts with DIMENSION attribute
Is it just not possible to have functions that return arrays, or am I doing something wrong?
Any help/suggestions are appreciated, thanks. If it helps, I'm using fortran 90 with the gfortran compiler
Modestly extending the other two answers, I think other approaches are typically preferable to the old "external". (The "Fortran 2003 Handbook" lists at least one case in which "external" must be used.) As already suggested, for your own source code, place the procedures (functions & subroutines) into a contains section of a module and then use it. This will automatically make the interface of your procedures explicit so that the compiler can check compatibility between arguments in calls and the dummy arguments of the procedure -- this can catch a lot of programmer mistakes. If for some reason you don't have access to Fortran source code, for example, you are linking to a library or calling C, then I would write an interface statement describing the procedure. This will inform that compiler that the declared name is a function or program and specify the interface to allow argument check. I would only do this when the module method isn't possible because it is more work and prone to mistakes when changes are made because two items have to be changed.
Probably the reason this isn't working is, that according to the "Fortran 2003 Handbook", the use of the external attribute does not provide an explicit interface, and an explicit interface is required for a function returning an array argument. I don't know why the interface is considered to be non-explicit in this case.
The Intel Fortran compiler documentation tells me that EXTERNAL is incompatible with DIMENSION, which is roughly what your compiler is telling you. I've had a quick look at the standard for Fortran 2003 but have failed to interpret it unambiguously on this point -- so I'll agree with Intel and assert that what your are trying to do is non-standard.
You certainly can write functions which return arrays.
It looks a little odd to me that you have written the function EIGENVALUES and are then trying to declare it to be EXTERNAL. I would normally put my function definitions either in a CONTAINS section within a larger program unit or in a MODULE which the calling unit USEs. In neither case do I need to declare anything EXTERNAL.
Where is the source of EIGENVALUES wrt the source of the calling program ?