-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
using cfunction on a callback wrapper #2700
Comments
Although the code shown is from the NLopt.jl package sketch (at https://github.com/dmbates/NLopt.jl.git) the nature of the Opt type and the rosenbrock function are tangential to the issue. |
Have you tried ever calling the function with dummy parameters. I have found that julia may already know if there is some error in your code (thus the function not returning, since an error is thrown). |
Bug. Not being able to infer the type of something is routine; it shouldn't make it think the function doesn't return. |
Oh nevermind --- the problem is that |
@JeffBezanson Thank you. |
I'm a little further along now but still not there. I have modified the callback wrapper to function nlopt_callback_wrapper(n::Uint32, x::Ptr{Cdouble}, grad::Ptr{Cdouble}, f_::Ptr{Void})
res::Float64 = zero(Float64)
if f_ != C_NULL
f = unsafe_pointer_to_objref(f_)::Function
if grad == C_NULL
res = f(pointer_to_array(x, (int(n),)))
else
res = f(pointer_to_array(x, (n,)), pointer_to_array(grad, (int(n),)))
end
end
res
end so that it is legitimate to call it as
However, now I get
It seems to me that despite my efforts to convince the type inference engine that it can't return anything other than a |
I'm not certain if this fixes it, by this line still throws an error or just make n an int in the first place with the line |
to make this work, it seems we also need to type annotate the return value, otherwise the return value (from inspection of the disassembly) appears to be
|
Yes, I also found in PyCall that I had to annotate the return type; see e.g. You probably also want to call |
Shall I submit a documentation patch stating that type annotation on the return value in the callback is preferred? Unless support for declaring the type of a function is coming soon, I feel that the above must be documented. I just spent a good 20 minutes trying to figure out why I was getting a |
+1 for documentation |
Please do. |
In the "Revised Optimization Functions" thread on julia-dev @stevengj blocked out how to wrap a closure as a callback function for the C optimizer code in the NLopt package. The (slightly modified) wrapper function is
but the call to
cfunction
inproduces
It seems that after the compilation of the method in
jl_function_ptr
the return type is not a Float64. Any suggestions for a workaround? I can appreciate that the return type off
cannot be inferred but is there some way for me to be more explicit about the return type of a call tonlopt_callback_wrapper
?The text was updated successfully, but these errors were encountered: