-
-
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
Make by-value struct passing work properly #7906
Conversation
Fixed size arrays can now be emulated by tuples. Anyway, I think we should merge this right after we tag 0.3. There is outstanding questions about the interface for cfunction, but since we intend 0.4 to be breaking anyway, we can figure that out later. |
*mostly emulated by tuples – someone still should make that true for tuples inside of types. (hint, hint) i meant to add the 0.4 tag, since i was intending to have this ready to merge this shortly into that...done now julep proposal for the interface changes: https://gist.github.com/vtjnash/7296634 |
Yeah, we need to do that. |
@@ -182,3 +182,8 @@ function function_module(f::Function, types=(Any...)) | |||
end | |||
m[1].func.code.module | |||
end | |||
|
|||
# |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[edit] ❌
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a green X?
but yes, that's a good reminder that we need to scan through this and remove any debug code
@@ -49,7 +49,7 @@ object_id(x::ANY) = ccall(:jl_object_id, Uint, (Any,), x) | |||
|
|||
# type predicates | |||
const isimmutable = x->(isa(x,Tuple) || !typeof(x).mutable) | |||
isstructtype(t::DataType) = t.names!=() || (t.size==0 && !t.abstract) | |||
isstructtype(t::DataType) = (t.names!=() || t.size==0) && !t.abstract |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Keno which was correct? I suspect this wasn't supposed to change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure right now. I seem to recall this function also being implemented in C, so we should match whatever is done there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line 542 in 31eb8d4
STATIC_INLINE int jl_is_structtype(void *v) |
seems to indicate this change was correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JeffBezanson thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that matches my recollection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
t.names!=()
implies !t.abstract
, so I believe the two versions are equivalent.
Nice!! +1 |
I'd like to go ahead and merge this very soon, so we have as much time as possible to encounter and fix any possible issues. |
I assumed you would, which is why I wrote in big letters that more work needs to be done over the next few weeks to finish this (WIP tag added also) |
Well, let's sit down via IRC this weekend and hammer out the cfunction changes then. That's what's been blocking this for about a year, so we should finally just do it. |
i'm busy this weekend. either comment on the gist, propose your own, or wait for next weekend. i don't think the API questions were blocking this, I just didn't want to steal your pull request to make the necessary additions, since I couldn't be sure if you were going to get back to it. |
Well, the reason this wasn't merged a year ago is that the cfunction API wasn't done. |
6c7c7e3
to
1a4c02f
Compare
Any progress on this? |
Lots. It's currently blocked by a number of other PRs that are needed first however. |
b8db56e
to
00756be
Compare
Awesome job improving the ccall docs, Jameson. |
Bool, FloatingPoint, Float16, Float32, Float64, Number, Integer, Int, Int8, Int16, | ||
Int32, Int64, Int128, Ref, Ptr, Real, Signed, UInt, UInt8, UInt16, UInt32, | ||
UInt64, UInt128, Unsigned, | ||
Real, Complex, Number, Integer, Bool, Ref, Ptr, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Complex
shouldn't be here; it's not in this module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i wonder if it should move here (or had at some points in the life of this PR), since it is now an influential type on ccall ABI generation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big deal; the run time system already refers to some stuff in Base.
This is epic. Especially love the wonderfully detailed documentation. |
any expression, such as ``&0`` or ``&f(x)``. | ||
Notice that we have to be careful about the return type: ``qsort`` expects a function | ||
returning a C ``int``, so we must be sure to return ``Cint`` via a call to ``convert`` | ||
and a ``typeassert``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I wish that cfunction
would just call convert
and add the typeassert for you.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you edit the top post and add it as future work? It wouldn't actually be that hard to add anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Typo?
|
Addresses comments: #7906 (comment) #7906 (comment)
this is
a first cut at(done)rebasing #3466 onto master(also done) ready-to-merge patch to improve ccall/cfunction compatibility. @Keno let me know if you see anything that looks wrong.To keep track of issues (from comments) from the previous PR:
Need to figure out what to do with fixed-size arrays.(will be done later)(only cfunction updates remain)future work:
jl_apply_generic
call (possible sketch of implementation : https://gist.github.com/vtjnash/019b4d5d63b64a772a31)cfunction(f, T, ...)
to automatically callconvert(T, ...)::T
on the return value off
.convert(::Type{T}, x::Ref{T})
methodNOTE: please DO NOT merge this until the cfunction API changes are finalized. (i don't want to need to update Gtk.jl twice)