I am building an extension API for R in Rust. I annotate my functions with a procedural macro to generate C wrappers with the appropriate conversion and error handling:
use extendr_api::*;
#[export_function]
fn hello() -> &'static str {
"hello"
}
This generates a C function hello__wrapper__ that is callable from R
using the .Call mechanism.
In addition to this, we need to generate a NAMESPACE file for the R
metatdata:
export(hello)
useDynLib(libhello, "__wrap__hello")
And a file lib.R
hello <- function() {
.Call("__wrap__hello")
}
What is the simplest way to extend cargo or rustc
to write this additional information? I'm guessing
that writing a file from the procedural macro code is
a bad idea.
From what I understand, procedural macros generate code at compile time, but it has to be valid Rust code. I do not think that a procedural macro is the way to go in this case.
One possible solution is to create a script that will go through and find your exported functions in the Rust file and generate the 2 extra files you need. You could make a build script that runs before compiling if you want to do all the parsing in Rust, otherwise I would suggest something like Python.
Related
I need to know how to create a library in Julia and where I must keep it in order to call it later. I come from C and matlab, it seems there is no documentation about pratical programming in Julia.
Thanks
If you are new to Julia, you will find it helpful to realize that Julia has two mechanisms for loading code. Stating you "need to know how to create a library in Julia" would imply you most likely will want to create a Julia module docs and possibly a packagedocs. But the first method listed below may also be useful to you.
The two methods to load code in Julia are:
1. Code inclusion via the include("file_path_relative_to_call_or_pwd.jl")docs
The expression include("source.jl") causes the contents of the file source.jl to be evaluated in the global scope of the module where the include call occurs.
Regarding where the "source.jl" file is searched for:
The included path, source.jl, is interpreted relative to the file where the include call occurs. This makes it simple to relocate a subtree of source files. In the REPL, included paths are interpreted relative to the current working directory, pwd().
Including a file is an easy way to pull code from one file into another one. However, the variables, functions, etc. defined in the included file become part of the current namespace. On the other hand, a module provides its own distinct namespace.
2. Package loading via import X or using Xdocs
The import mechanism allows you to load a package—i.e. an independent, reusable collection of Julia code, wrapped in a module—and makes the resulting module available by the name X inside of the importing module.
Regarding the difference between these two methods of code loading:
Code inclusion is quite straightforward: it simply parses and evaluates a source file in the context of the caller. Package loading is built on top of code inclusion and is quite a bit more complex.
Regarding where Julia searches for module files, see docs summary:
The global variable LOAD_PATH contains the directories Julia searches for modules when calling require. It can be extended using push!:
push!(LOAD_PATH, "/Path/To/My/Module/")
Putting this statement in the file ~/.julia/config/startup.jl will extend LOAD_PATH on every Julia startup. Alternatively, the module load path can be extended by defining the environment variable JULIA_LOAD_PATH.
For one of the simplest examples of a Julia module, see Example.jl
module Example
export hello, domath
hello(who::String) = "Hello, $who"
domath(x::Number) = x + 5
end
and for the Example package, see here.
Side Note There is also a planned (future) library capability similar to what you may have used with other languages. See docs:
Library (future work): a compiled binary dependency (not written in Julia) packaged to be used by a Julia project. These are currently typically built in- place by a deps/build.jl script in a project’s source tree, but in the future we plan to make libraries first-class entities directly installed and upgraded by the package manager.
I can run julia script with arguments from Powershell as > julia test.jl 'a' 'b'. I can run a script from REPL with include("test.jl") but include accepts just one argument - the path to the script.
From playing around with include it seems that it runs a script as a code block with all the variables referencing the current(?) scope so if I explicitly redefine ARGS variable in REPL it catches on and displays corresponding script results:
>ARGS="c","d"
>include("test.jl") # prints its arguments in a loop
c
d
This however gives a warning for redefining ARGS and doesn't seem the intended way of doing that. Is there another way to run a script from REPL (or from another script) while stating its arguments explicitly?
You probably don't want to run a self-contained script by includeing it. There are two options:
If the script isn't in your control and calling it from the command-line is the canonical interface, just call it in a separate Julia process. run(`$JULIA_HOME/julia path/to/script.jl arg1 arg2`). See running external commands for more details.
If you have control over the script, it'd probably make more sense to split it up into two parts: a library-like file that just defines Julia functions (but doesn't run any analyses) and a command-line file that parses the arguments and calls the functions defined by the library. Both command-line interface and the second script your writing now can include the library — or better yet make the library-like file a full-fledged package.
This solution is not clean or Julia style of doing things. But if you insist:
To avoid the warning when messing with ARGS use the original ARGS but mutate its contents. Like the following:
empty!(ARGS)
push!(ARGS,"argument1")
push!(ARGS,"argument2")
include("file.jl")
And this question is also a duplicate, or related to: juliapassing-argument-to-the-includefile-jl as #AlexanderMorley pointed to.
Not sure if it helps, but it took me a while to figure this:
On your path "C:\Users\\.julia\config\" there may be a .jl file called startup.jl
The trick is that not always Julia setup will create this. So, if neither the directory nor the .jl file exists, create them.
Julia will treat this .jl file as a command list to be executed every time you run REPL. It is very handy in order to set the directory of your projects (i.e. C:\MyJuliaProject\MyJuliaScript.jl using cd("")) and frequent used libs (like using Pkg, using LinearAlgebra, etc)
I wanted to share this as I didn't find anyone explicit saying this directory might not exist in your Julia device's installation. It took me more than it should to figure this thing out.
I have 3 scripts logs.R, func.R, main.R and I want to log from main and also from func scripts. I know that I can use source, for having the functions in both scripts, but sourcing logs in func and in main, is the same of sourcing it 2 times (I source func in main). Is there any equivalent of #pragma once or #ifndef #define #endif from C++ ?
You can mimic that with a custom variable and a condition.
logs.R
...
log.sourced <- TRUE
func.R
if(!exists("log.sourced")) source("logs.R")
...
main.R
if(!exists("log.sourced")) source("logs.R")
...
Or just test exists("func") where func is defined in logs.R
use the source("otherfile.R") to include the content of other files. (equivalent of include).
As R is directly interpreted and no preprocessed, there is not equivalent of #pragma once or include guards directive.
One way to replace the include guards would be to write in directly in R.
Since there’s no proper solution in base R and other solutions require on hacky mechanisms like include guards, I wrote my own package: ‘box’.
With modules you can for instance write the following code:
box::use(./logs)
And now you can use logs like a package/namespace you’re used to in other languages: logs$log('Some string I’d like to log.'). Or, alternatively, you could do
box::use(./logs[...])
This mimics R’s normal attaching mechanism, and is similar to using namespace foo in C++. See the ‘box’ vignette for a more in-depth introduction.
I'm fairly new to Scilab, and I'm trying to write a simple function and call it.
How can I write a function in a .sci file in some arbitrary directory and then call it? MATLAB does this automatically. I read a ton of posts talking about using "Execute->Load into scilab" and getf, but none of those are present in my version of Scilab (5.3.3). So how in the world can I do this?
exec filelocation\yourFile.sci;
should do it
I have a library which i want to use in my iphone project which uses cpp files as well ... in order to do so i need the unix executable form of .a file..>?
You need to write a program of your own with a main function which uses the functions in the library you want to use. The library doesn't contain any code to exercise its own functions (I won't reiterate what #Steve-o already wrote in the comment -- took the words out of my mouth). It is fairly common for the source code of a library to include a simple demo program, but this is rarely distributed with the binary library.