Skip to content
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

Merged
merged 14 commits into from
Mar 10, 2015
Merged

Make by-value struct passing work properly #7906

merged 14 commits into from
Mar 10, 2015

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Aug 8, 2014

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 add link to LDC
  • Need to figure out what to do with fixed-size arrays. (will be done later)
  • merge the Mutable module from Gtk into base (RFC: change lowering of ccall cconvert arguments and add Ref{T} type #9986)
  • implement https://gist.github.com/vtjnash/7296634 (only cfunction updates remain)
  • build libccalltest on travis
  • update documentation on ccall/cfunction in manual
  • add documentation for Ref type to stdlib
  • more tests for cfunction/ccall/Ref interactions
  • use unsafe_load in cfunction when receiving isbits types
  • update docs again. add docs for cconvert / unsafe_convert
  • add notes to NEWS and email to julia-users list

future work:

  • calling conventions for cfunction
  • types as C-structs #2818 (types as c-structs)
  • emit cfunction stubs for any jl_apply_generic call (possible sketch of implementation : https://gist.github.com/vtjnash/019b4d5d63b64a772a31)
  • more completely use tuples to emulate more stuff, like fixed size arrays
  • change cfunction(f, T, ...) to automatically call convert(T, ...)::T on the return value of f.
  • add convert(::Type{T}, x::Ref{T}) method
  • hide the typetag

NOTE: please DO NOT merge this until the cfunction API changes are finalized. (i don't want to need to update Gtk.jl twice)

@Keno
Copy link
Member

Keno commented Aug 8, 2014

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.

@vtjnash vtjnash added this to the 0.4 milestone Aug 8, 2014
@vtjnash
Copy link
Member Author

vtjnash commented Aug 8, 2014

*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

@Keno
Copy link
Member

Keno commented Aug 8, 2014

Yeah, we need to do that.

@@ -182,3 +182,8 @@ function function_module(f::Function, types=(Any...))
end
m[1].func.code.module
end

#
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[edit] ❌

Copy link
Member Author

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

@vtjnash vtjnash changed the title WIP: Make struct passing work properly #3466 Make struct passing work properly Aug 8, 2014
@@ -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
Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

STATIC_INLINE int jl_is_structtype(void *v)

seems to indicate this change was correct?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JeffBezanson thoughts?

Copy link
Member

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.

Copy link
Member

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.

@JeffBezanson
Copy link
Member

Nice!! +1

@JeffBezanson JeffBezanson modified the milestones: 0.4, 0.4-projects Aug 10, 2014
@Keno
Copy link
Member

Keno commented Aug 14, 2014

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.

@vtjnash
Copy link
Member Author

vtjnash commented Aug 14, 2014

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)

@vtjnash vtjnash changed the title Make struct passing work properly WIP: Make struct passing work properly Aug 14, 2014
@Keno
Copy link
Member

Keno commented Aug 14, 2014

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.

@vtjnash
Copy link
Member Author

vtjnash commented Aug 14, 2014

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.

@Keno
Copy link
Member

Keno commented Aug 14, 2014

Well, the reason this wasn't merged a year ago is that the cfunction API wasn't done.

@zenna
Copy link

zenna commented Jan 21, 2015

Any progress on this?

@vtjnash
Copy link
Member Author

vtjnash commented Jan 21, 2015

Lots. It's currently blocked by a number of other PRs that are needed first however.

@vtjnash vtjnash force-pushed the jn/ccall3 branch 3 times, most recently from b8db56e to 00756be Compare February 2, 2015 05:50
@vtjnash vtjnash merged commit 22490c1 into master Mar 10, 2015
@vtjnash vtjnash deleted the jn/ccall3 branch March 10, 2015 02:36
@johnmyleswhite
Copy link
Member

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,
Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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.

@StefanKarpinski
Copy link
Member

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``.
Copy link
Member

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.)

Copy link
Member Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@zenna
Copy link

zenna commented Mar 26, 2015

Typo?

The function cfunction generates the c-compatible function pointer for a call to a Julia Julia library function. Arguments to cfunction are as follows:

pao added a commit that referenced this pull request Mar 31, 2015
@pao
Copy link
Member

pao commented Mar 31, 2015

@zenna fixed in 36ccc5b; thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.