OpenGL, GLU, GLUT, and SDL packages (due to o-jasper)

[Rob]

I want to give a huge thank you to o-jasper for the Julia FFI and OpenGL interface that he posted a few months back ( https://groups.google.com/forum/?fromgroups=#!searchin/julia-dev/jasper/julia-dev/TbNqc12OB6Q/lzxHbtOncMQJ ).  With that, we've been able to produce working OpenGL, GLU, GLUT, and SDL packages.  We've gotten to the point that the first ten NeHe tuts run in Julia (and it definitely seems to be the case that at least the first 25 or so should work).  I'm currently packaging everything for Julia (which can be found at https://www.github.com/rennis250 ).   It still needs to be touched up a bit, so it shouldn't be added to METADATA or anything like that yet, but I wanted to get the word out.

All credit goes to o-jasper for the awesome work that he has done.  I am merely a messenger.  He did all of the heavy and important work and this should rightfully be considered his set of packages.

The GLUT interface wouldn't have been possible without the addition of cfunction, so a huge thank you for that, as well.

--rennis250

[Stefan Karpinski]

Amazing stuff. It's very exciting to see this.

You can fork your own copy of METADATA.jl and use that instead of the default while you're working on this. And of course, you can rebase it periodically so that you also get updates to other packages.

--
 
 
 

[John Myles White]

This looks so awesome.

 -- John

--
 
 
 

[Westley Hennigh]

Seeing this just made my day. I am unreasonably excited. 

[Jeff Bezanson]

Fabulous!

> --
>
>
>

[Rob]

I'm just as unreasonably excited!  Jasper has a pure Julia FFI in the works that will take any C header and autogenerate a Julia file that will automatically dlopen the respective library, load all of the functions/constants via ccall using his very useful @get_c_fun macro, and wrap them up in a Julia function, removing much of the work involved in interfacing with a C library.  It's very cool and you can check it out here: https://github.com/o-jasper/julia-ffi

Thanks for the advice, Stefan.  I'll be sure to do that.

Glad to see that everyone is excited about this! I'm hoping to have the packages in a user-friendly form by next Monday.  

[Rob]

As promised, the first version of the packages is complete.  I added a fifth package, GetC.jl, to the list.  It contains Jasper's @get_c_fun macro, which is needed to interface with the FFI output of his parser.  All of the packages have it in their REQUIRE list.  I've been able to add them to my fork of METADATA.jl and add them via Pkg without problems.  However, I would like to ask that we hold off on adding  them to the official repo for a day or two, as we are finalizing some licensing choices and such.  But, don't let that hold you back from playing with them!  I've pulled the latest commit of METADATA.jl and rebased, so you can use https://github.com/rennis250/METADATA.jl.git to try out the packages, while staying relatively up-to-date with the others.  

The GLUT Examples are almost 1-to-1 translations of the NeHe tuts, whereas the SDL Examples are much shorter/simpler and feel more Julian.

At the moment, the GLUT package has full keyboard and mouse functionality, which can be seen in the Examples.  We still need a good, pure Julia approach for implementing keyboard/mouse functionality in the SDL package.

There is one major annoyance: A GLUT/SDL instance can't be closed without quitting the Julia REPL.  I've yet to figure out a way around this.

I've also had some performance hiccups here and there, which I haven't figured out yet.  Please, post if you have issues/find solutions!

--Rob

[Westley Hennigh]

Awesome!

--
 
 
 

[Jasper]

Thanks for the enthousiasm! Sorry that i am a bit slow in replying.

I have no issues with weakening the license for anything under
https://github.com/o-jasper/julia-ffi.(everything concerned here) What
would be best choice? I suppose the MIT license?

I have mostly been getting the new autoffi rolling(in the dev branch),
it basically needs to suppress a little more of the spurious output.
(`gcc -E` outputs some stuff from other header files.)

One thing in particular that i dont see how to do (well)yet is accessing
struct members. With `pack` and `unpack` and you can 1) `(un)pack` at
the first and last moment(julia then has a separate copy), 2) keep it as
object and `(un)pack` whenever an component is changed 3) in the
middle, have some object that can be 'synced' 4) Other? If there is no
clear cut best way, maybe allow multiple.

[Tim Holy]

On Thursday, December 13, 2012 03:50:11 AM Jasper wrote:
> One thing in particular that i dont see how to do (well)yet is accessing
> struct members. With `pack` and `unpack` and you can 1) `(un)pack` at
> the first and last moment(julia then has a separate copy), 2) keep it as
> object and `(un)pack` whenever an component is changed 3) in the
> middle, have some object that can be 'synced' 4) Other? If there is no
> clear cut best way, maybe allow multiple.

I'm sure you're already several steps ahead on this, but (to make the obvious
point) presumably the best answer depends on the usage pattern. If one struct
has a long lifetime with repeated access to the majority of its fields, then it
probably makes sense to unpack it as a type right away. If instead you'll
frequently only need a couple of fields, if you're _really_ concerned about
performance, and if you're willing to go to some effort to get it, maybe it
makes sense to see whether it would be practical to avoid complete unpacking,
and instead auto-generate individual "extraction" functions for the fields:

f::Float64 = MyStruct_field1(buf::Vector{Uint8})
d::Int32 = MyStruct_field2(buf::Vector{Uint8})
etc.

I suspect this would be an ambitious effort, although I bet code in strpack
would serve as a strong foundation.

Julia will eventually have immutable types, which might make interactions with
C structs faster, but given their immutability it's not obvious (at least, to
me) that they will be suitable as outputs from C code: if the C code changes
bytes, it would seem to violate their immutability. But I don't know much
about this, so if you want reliable information you'll have to get it from
others.

Best,
--Tim

[Rob]

Opened a pull request for the packages on METADATA.jl.git.  Check the READMES and the Examples before getting too far into it, but have fun!  I'll add MIT licenses to everything tonight.

--Rob

[Rob]

Actually, is it appropriate to put MIT licenses on these packages, since they essentially implement code from other projects?  I'm thinking that I should put the original licenses on the packages (e.g., the OpenGL.jl package should have the license used by the Khronos Group tacked onto it?).  It appears we may not have to be concerned with this? http://www.sgi.com/products/software/opengl/license.html  I really know nothing of the legal implications.

--Rob

[Westley Hennigh]

I find it interesting that we can walk through a perfectly reasonable set of solutions to problems (making sure people are rewarded for their work, time, etc) and wind up in such absurd circumstances.

I think the only way you're really going to know is if you invest an enormous amount of time reading the licenses and the various interpretations people have had of them... Which sounds like agony personally.

[Patrick O'Leary]

PyOpenGL, for instance, is BSD. I'm not sure that bindings need to follow the licenses of their underlying packages. In the OpenGL case, half the time the implementation is proprietary anyways.

If you're binding a GPL library, you don't have a choice, because using the bindings to access the library would produce a combined work. Otherwise, I'd say MIT or the license of the target library (if it is open-source) are probably the right defaults for Julia bindings.

[Jasper]

I really doubt there will be any problem with licensing it with
the MIT license.

If there is a macro/function `@member struct_ptr member_name` and
`@member struct_ptr member_name=value`, that uses the pointer directly,
is fast, that might be a perfect solution, in the sense that other
options are not really needed for performance. If `Ptr{Something}` with
`isa(Something, CompositeType)` worked that way automatically, there
wouldn't even be a need to do anything on the FFI side.

Before i knew of strpack.jl, the idea was to generate a C file with
getters and setters, and compile and FFI that aswel. The behavior is
similar, but it seems convoluted.(`ccall`s are cheap though, right?)

None of that handles ownership, for that, i suppose you could put the
pointer into some object something, and possibly add a destructor. (If
nothing really needs to be done, `free` should suffice.) Possibly there
are reasons to want that in the autoFFI(I dont see them), but i think
that is a later concern, and somewhat goes along with wanting hooks
into the stuff. Like the current `fun_namer` hook that lowercases the GL
function names. But the 'customization' stuff is there because it aughto
be there, probably very plain FFI just extended with regular Julia in a
separate package keeps things more predictable.

Veering offtopic a just bit, the `@member` macro would perhaps be nice
to put on `.` instead, then you can write `struct_pointer.member_name`
as usual. In general i worry about setters-and-getters. Possibly
they'd make different conventions, and they'd make getters and setters
for members of `CompositeType`s aswel.. Allowing people to just put
them on `.` might be nicer. However, people would have to be trusted
that they dont break the concepts behind it though.. Imo not sufficient
reason not to do it.

Off topic some more, CL has setf-functions that are a bit more general
yet, the 'setf and setf-functions' section about that here
https://github.com/JuliaLang/julia/wiki/common-lisp-rosetta-for-the-devs
I put an untested macro on how you might get that in Julia in the
attachment. On the one hand, how `ref` and `assign`(which is basically
exactly that) works demonstrates there are uses, on the other hand, i
dont see another use at this point.

[Rob]

Yea, it appears we will be fine with the MIT license.  For most of the projects, It's only once you include the actual libraries in the package that you need to use the same license as the project.

The packages are now on the official METADATA.jl (thanks, Stefan), so clone away!  Thanks again for the help and advice, everyone!  I look forward to seeing what people make.

Jasper, I've been wondering about an easy way to handle structs, also.  At the moment, I've been writing custom functions to handle special cases (e.g., when dealing with SDL's event system).  I agree that the C approach might be a bit much, but I like the idea of the @member macro.  However, we're quickly entering territory, of which I only know a marginal amount.

--Rob

[Tim Holy]

On Friday, December 14, 2012 01:24:43 AM Jasper wrote:
> None of that handles ownership, for that, i suppose you could put the
> pointer into some object something, and possibly add a destructor. (If
> nothing really needs to be done, `free` should suffice.)

You should be able to use an Array{Uint8, 1} as a buffer for these kinds of
things. Arrays automatically get converted to pointers in a ccall, and all the
scoping and garbage-collection is handled automatically---you don't have to
worry about a blob of memory getting lost.

There is some overhead to arrays (I think I remember Jeff saying something on
the order of 56 bytes), so if you're really sensitive to this, you can
allocate a much bigger buffer and use it for multiple structs. There are some
nice convenience routines in base/pointer.jl. If you grep base for
"reinterpret" you'll also see some other ways you can sneakily use memory
buffers.

Best,
--Tim

[Stefan Karpinski]

The Regex type uses this approach for storing compiled PCRE data:

julia> dump(r"a+b+")

Regex 

  pattern: ASCIIString "a+b+"

  options: Int32 2048

  regex: Array(Uint8,(59,)) [0x45, 0x52, 0x43, 0x50, 0x3b, 0x00, 0x00  …  0x61, 0x23, 0x62, 0x72, 0x00, 0x07, 0x00]

  extra: Ptr{None} Ptr{Void} @0x0000000000000000

The .regex field is an array of bytes that holds the compiled stuff. This has a nice side-effect that regexes can be serialized and deserialized automatically. Unfortunately, the PCRE "extra" field is a less simple structure, so I couldn't do the same thing for it easily.

--