I am trying to use multi in my Raku code that wraps a function in C.
Here I am calling lchoose function in shared libray Rmath.
This is my code which works:
use NativeCall;
constant RMATH = "./Rmath"; # shared library
sub lchoose(num64, num64) returns num64
is native( RMATH ) { * };
# The C function signature is
# double lchoose(double, double);
sub r_lchoose($n,$r) {
return lchoose($n.Num, $r.Num)
}
say r_lchoose(9,8) # 2.1972245773362196
But this does not work. The code keeps on running/hanging. Neither dies nor throws any output:
use NativeCall;
constant RMATH = "./Rmath"; # shared library
multi lchoose(num64, num64) returns num64
is native( RMATH ) { * };
multi lchoose($n,$r) {
lchoose($n.Num, $r.Num)
}
say lchoose(9,8) # Neither dies nor throws any output
My expectation is when I call lchoose(9,8) it should call second multi as the arguments are definitely not num64. If it had used second function, then it would have called the first function and given the output.
Or atleast I expected the program to throw error rather than hang.
OS information
Windows 11 64-bit
Raku information
Welcome to Rakudo™ v2022.04.0000.1.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2022.04-3-ga9fcd5a74.
A num64 in a signature indicate that it MUST have a num64 for a multi dispatch to work. Otherwise you could not set up candidates for a Num:D and have a candidate for num64 or num32.
And because there is no candidate for Num in your example, it will dispatch back to the original candidate, causing the infiniloop.
I would therefore write the "catch-all" lchoose candidate as:
multi lchoose(Num() $n, Num() $r) {
lchoose(my num64 $ = $n, my num64 $ = $r)
}
In the signature we convert everything to Num, and then we assign these to nameless native num64 variables in the call the other candidate (which will now dispatch correctly).
Related
I'm trying to implement a simple function in pure lodash way.
function forward(i) => {
return (j) => {
return String.fromCharCode(i + j)
}
}
So that I can do _.range(26).map(forward(65)). Take me some time to make this work:
function a = _.wrap(String.fromCharCode, (fn, a, b) => fn(a + b))
function b = _.ary(a, 2)
function forward = _.curry(b)
Now my question is is there an easier way to do this? and how do I use sum to construct (fn, a, b) => fn(a + b)?
One last thing is I couldn't find wrap function file in Lodash repo.
The function _.curry(...) is kind of strange when it comes to calling functions with various parameters. Let me guide you with an example below.
The ary-function (_.ary(..., 2)) takes any function and ensures its never called with more than a specific amount of arguments (in this case two). Less arguments than specified, will just end up calling the underlying function with less arguments. A definition of this function could look like this:
function ary() {
const args = arguments;
// implementation
}
There is no way to tell how many arguments the function is expecting, as you would with a function with actual parameters (function(a, b) { }). If you would define const forward1 = _.curry(_.ary(target, 2)), and call it with forward1(42)(2), the curry function would just pass down the first argument to ary as it thinks its done.
We can get around this by using an overload of curry that specifies how many parameters the underlying function is expecting (const forward2 = _.curry(target, 2)). Only in the case where forward2 is called in a curry-style (not sure what its even called) with two parameters, it passes it down to target. A call with one argument will just return a new function, waiting for it to be called with the second argument. Now we can get rid of the ary-call, as it serves us no purpose anymore.
As for chaining actions, there's a helper for that. For example: c(b(a(...) can be rewritten to _.flow([a, b, c]). Lodash also provides a function for a + b, which is _.add().
Together your problem can be rewritten to:
const forward = _.curry(_.flow([_.add, String.fromCharCode]), 2);
or more verbose:
const methods = _.flow([
_.add,
String.fromCharCode
]);
const forward = _.curry(methods, 2);
Note that the 2 corresponds to the amount of parameters the _.add method expects.
I am writing a native C++ project with a managed C++ wrapper that can receive and invoke callbacks from C#. The managed side should be able to retrieve back that callback and trigger on the managed environment as well.
The signature of the said callback is:
// Native C++
typedef EvaluateResult (*NativeFunction) (std::vector<EvaluateResult> args);
// Managed C++ wrapper
delegate EvaluateResultWrapper^ ManagedFunction (List<EvaluateResultWrapper^> args);
The EvaluateResultWrapper is the managed wrapper class for the native class EvaluateResult. The conversion between the EvaluateResult is:
EvaluateResult result;
EvaluateResultWrapper^ wrapper = gcnew EvaluateResultWrapper (result);
result = EvaluateResult (*wrapper.original);
I want to implement the constructor EvaluateResultWrapper::EvaluateResultWrapper (ManagedFunction^ func) that can roughly do the following:
// NOTE: Pseudo code
void EvaluateResultWrapper::EvaluateResultWrapper (ManagedFunction^ func) {
this->func = func; // Store the func as a member to avoid GC
// original is the pointer to the EvaluateResult that this object is wrapping around
this->original = new EvaluateResult ([&func](std::vector<EvaluateResult> args) -> EvaluateResult {
List<EvaluateResultWrapper^>^ argsList; // Convert args from vector to List. Assuming it is done under the hood
EvaluateResultWrapper^ wrapper = func->Invoke (argsList); // Invoke the managed callback
return EvaluateResult (wrapper.GetOriginal ()); // Convert the managed result to the native counterpart
});
}
I know the above code will not work, but the idea I should be able to wrap the managed callback with codes that able to do conversion of both the callback arguments and return types, so that it is native friendly.
Ideally, I can also do the other way around (not important)
// NOTE: Pseudo code
ManagedFunction^ EvaluateResultWrapper::GetFunction (ManagedFunction^ func) {
// if the callback is set by the managed side, return the same callback back
if (this->func != nullptr) return this->func;
// Otherwise, the callback is a native one
NativeFunction nativeFunc = this->original->GetFunction ();
return gcnew ManagedFunction ([&nativeFunc] (List<EvaluateResultWrapper^>^ args) -> EvaluaResultWrapper {
std::vector argsList; // Convert the args from List back to vector. Assuming it is done under the hood
EvaluateResult result = nativeFunc (argsList); // Invoke the native function
return gcnew EvaluateResultWrapper (result); // Convert the native result into the managed one
});
}
I wonder whether this can be done?
A little bit of context: I am writing an external scripting system on native C++ for our games (similar to Lua scripting). The EvaluateResult is a class representing an evaluation result of any statement. It is basically a value coupled with the type. The type can be either number, boolean, string, array, object, or in this case: function callback.
The function callback can be either set within the native C++ (when the interpreter pass the user-defined function in the scripts) or a function set by the host (managed side).
The idea is the host (C# side) should be able to define and set functions into the memory (defining print() function to print into the host console for example). The callback is wrapped as an EvaluateResult class before storing into the the scripting memory.
For inspection purpose, C# side must be able to get the function callback. Therefor, the ability to get the function is nice to have (but not important, since I can always instruct the native side to execute the function for me)
libc's error handling is usually to return something < 0 in case of an error. I find myself doing this over and over:
let pid = fork()
if pid < 0 {
// Please disregard the fact that `Err(pid)`
// should be a `&str` or an enum
return Err(pid);
}
I find it ugly that this needs 3 lines of error handling, especially considering that these tests are quite frequent in this kind of code.
Is there a way to return an Err in case fork() returns < 0?
I found two things which are close:
assert_eq!. This needs another line and it panics so the caller cannot handle the error.
Using traits like these:
pub trait LibcResult<T> {
fn to_option(&self) -> Option<T>;
}
impl LibcResult<i64> for i32 {
fn to_option(&self) -> Option<i64> {
if *self < 0 { None } else { Some(*self) }
}
}
I could write fork().to_option().expect("could not fork"). This is now only one line, but it panics instead of returning an Err. I guess this could be solved using ok_or.
Some functions of libc have < 0 as sentinel (e.g. fork), while others use > 0 (e.g. pthread_attr_init), so this would need another argument.
Is there something out there which solves this?
As indicated in the other answer, use pre-made wrappers whenever possible. Where such wrappers do not exist, the following guidelines might help.
Return Result to indicate errors
The idiomatic Rust return type that includes error information is Result (std::result::Result). For most functions from POSIX libc, the specialized type std::io::Result is a perfect fit because it uses std::io::Error to encode errors, and it includes all standard system errors represented by errno values. A good way to avoid repetition is using a utility function such as:
use std::io::{Result, Error};
fn check_err<T: Ord + Default>(num: T) -> Result<T> {
if num < T::default() {
return Err(Error::last_os_error());
}
Ok(num)
}
Wrapping fork() would look like this:
pub fn fork() -> Result<u32> {
check_err(unsafe { libc::fork() }).map(|pid| pid as u32)
}
The use of Result allows idiomatic usage such as:
let pid = fork()?; // ? means return if Err, unwrap if Ok
if pid == 0 {
// child
...
}
Restrict the return type
The function will be easier to use if the return type is modified so that only "possible" values are included. For example, if a function logically has no return value, but returns an int only to communicate the presence of error, the Rust wrapper should return nothing:
pub fn dup2(oldfd: i32, newfd: i32) -> Result<()> {
check_err(unsafe { libc::dup2(oldfd, newfd) })?;
Ok(())
}
Another example are functions that logically return an unsigned integer, such as a PID or a file descriptor, but still declare their result as signed to include the -1 error return value. In that case, consider returning an unsigned value in Rust, as in the fork() example above. nix takes this one step further by having fork() return Result<ForkResult>, where ForkResult is a real enum with methods such as is_child(), and from which the PID is extracted using pattern matching.
Use options and other enums
Rust has a rich type system that allows expressing things that have to be encoded as magic values in C. To return to the fork() example, that function returns 0 to indicate the child return. This would be naturally expressed with an Option and can be combined with the Result shown above:
pub fn fork() -> Result<Option<u32>> {
let pid = check_err(unsafe { libc::fork() })? as u32;
if pid != 0 {
Some(pid)
} else {
None
}
}
The user of this API would no longer need to compare with the magic value, but would use pattern matching, for example:
if let Some(child_pid) = fork()? {
// execute parent code
} else {
// execute child code
}
Return values instead of using output parameters
C often returns values using output parameters, pointer parameters into which the results are stored. This is either because the actual return value is reserved for the error indicator, or because more than one value needs to be returned, and returning structs was badly supported by historical C compilers.
In contrast, Rust's Result supports return value independent of error information, and has no problem whatsoever with returning multiple values. Multiple values returned as a tuple are much more ergonomic than output parameters because they can be used in expressions or captured using pattern matching.
Wrap system resources in owned objects
When returning handles to system resources, such as file descriptors or Windows handles, it good practice to return them wrapped in an object that implements Drop to release them. This will make it less likely that a user of the wrapper will make a mistake, and it makes the use of return values more idiomatic, removing the need for awkward invocations of close() and resource leaks coming from failing to do so.
Taking pipe() as an example:
use std::fs::File;
use std::os::unix::io::FromRawFd;
pub fn pipe() -> Result<(File, File)> {
let mut fds = [0 as libc::c_int; 2];
check_err(unsafe { libc::pipe(fds.as_mut_ptr()) })?;
Ok(unsafe { (File::from_raw_fd(fds[0]), File::from_raw_fd(fds[1])) })
}
// Usage:
// let (r, w) = pipe()?;
// ... use R and W as normal File object
This pipe() wrapper returns multiple values and uses a wrapper object to refer to a system resource. Also, it returns the File objects defined in the Rust standard library and accepted by Rust's IO layer.
The best option is to not reimplement the universe. Instead, use nix, which wraps everything for you and has done the hard work of converting all the error types and handling the sentinel values:
pub fn fork() -> Result<ForkResult>
Then just use normal error handling like try! or ?.
Of course, you could rewrite all of nix by converting your trait to returning Results and including the specific error codes and then use try! or ?, but why would you?
There's nothing magical in Rust that converts negative or positive numbers into a domain specific error type for you. The code you already have is the correct approach, once you've enhanced it to use a Result either by creating it directly or via something like ok_or.
An intermediate solution would be to reuse nix's Errno struct, perhaps with your own trait sugar on top.
so this would need another argument
I'd say it would be better to have different methods: one for negative sentinel values and one for positive sentinel values.
I am in the process of writing a bash clone in Rust. I need to have my program exit when the user types exit. In previous iterations of my program, before I added more complicated features, I used return to get out of the loop that was prompting the user for input. This logic is now in a function, because of the way I am implementing built in shell functions, so when I return it just jumps out of the function back into the control loop, instead of short-circuiting the control loop and ending the program.
I realize that I could probably return a boolean when the user types exit and exit the loop, but I would like to at least know if Rust has a way to terminate programs early, similar to Java's System.exit(), as this is useful for certain types of programs.
Rust 1.0 stable
std::process::exit() does exactly that - it terminates the program with the specified exit code:
use std::process;
fn main() {
for i in 0..10 {
if i == 5 {
process::exit(1);
}
println!("{}", i);
}
}
This function causes the program to terminate immediately, without unwinding and running destructors, so it should be used sparingly.
Alternative (not recommended) solution
You can use C API directly. Add libc = "0.2" to Cargo.toml, and:
fn main() {
for i in 0..10 {
if i == 5 {
unsafe { libc::exit(1); }
}
println!("{}", i);
}
}
Calling C functions cannot be verified by the Rust compiler, so this requires the unsafe block. Resources used by the program will not be freed properly. This may cause problems such as hanging sockets.
As far as I understand, the proper way to exit from the program is to terminate all threads somehow, then the process will exit automatically.
panic!("Oh no something bad has happened!")
Example:
if a * g < 0f32 { panic!("The arithmetric-geometric mean is undefined for numbers less than zero!"); }
In older documentation, you will see this as fail!("Oh no something bad here has happened.")
For some reason, this macro was changed from fail to panic. Panic is the way to fail, if you must.
[edit] I am sorry. It looks like you should be testing input for the string "exit," which would depend on how you are taking input (by line or by args). Then you can have the program break out of the loop on the condition that the exit is detected.
Example:
loop {
if exit_found { break }
else {
// your thing, which also looks for exit_found
}
}
I use value-parameterized tests in gtest. For example, if I write
INSTANTIATE_TEST_CASE_P(InstantiationName,
FooTest,
::testing::Values("meeny", "miny", "moe"));
then in the output I see test names such as
InstantiationName/FooTest.DoesBlah/0 for "meeny"
InstantiationName/FooTest.DoesBlah/1 for "miny"
InstantiationName/FooTest.DoesBlah/2 for "moe"
Is there any way to make these names more meaningful? I'd like to see
InstantiationName/FooTest.DoesBlah/meeny
InstantiationName/FooTest.DoesBlah/miny
InstantiationName/FooTest.DoesBlah/moe
INSTANTIATE_TEST_CASE_P accepts an optional 4th argument which can be used for this purpose. See https://github.com/google/googletest/blob/fbef0711cfce7b8f149aac773d30ae48ce3e166c/googletest/include/gtest/gtest-param-test.h#L444.
This is now available in INSTANTIATE_TEST_SUITE_P.
The optional last argument to INSTANTIATE_TEST_SUITE_P() allows the
user to specify a function or functor that generates custom test name
suffixes based on the test parameters.
Of interest is also this section in the source:
// A user can teach this function how to print a class type T by
// defining either operator<<() or PrintTo() in the namespace that
// defines T. More specifically, the FIRST defined function in the
// following list will be used (assuming T is defined in namespace
// foo):
//
// 1. foo::PrintTo(const T&, ostream*)
// 2. operator<<(ostream&, const T&) defined in either foo or the
// global namespace.
Two ways: (http://osdir.com/ml/googletestframework/2011-09/msg00005.html)
1) Patch the existing PrettyUnitTestPrinter to print test names; something like:
--- a/gtest-1.7.0/src/gtest.cc
+++ b/gtest-1.7.0/src/gtest.cc
## -2774,6 +2774,7 ## void PrettyUnitTestResultPrinter::OnTestCaseStart(const TestCase& test_case) {
void PrettyUnitTestResultPrinter::OnTestStart(const TestInfo& test_info) {
ColoredPrintf(COLOR_GREEN, "[ RUN ] ");
PrintTestName(test_info.test_case_name(), test_info.name());
+ PrintFullTestCommentIfPresent(test_info);
printf("\n");
fflush(stdout);
}
2) Write a new TestListener to print test results however you like. (https://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc) GTest allows registering a new test listener (and un-registering the builtin default), allowing pretty flexible customization of test output. See the link for example code.