Announcing linc, use SDL, OpenAL and more from Haxe

[underscorediscovery]

Today I'm fairly excited to announce a new initiative that has been in the works for some time.
I am looking forward to feedback and what you come up with.

The full announcement and information can be found here:
http://snowkit.org/2015/08/24/announcing-linc/

Thanks to Hugh and the Haxe team for the continued hard work in making Haxe what it is.

[michael solomon]

You are incredible.. man! 0_0

[Raoul Duke]

"without boxing"

hmmmm... last time I looked at HXCPP (long, long ago admittedly!) just
about everything was boxed, like even basic primitive numeric types
such as 'double', no?

has this really changed? great news if so! :-)

[underscorediscovery]

These are externs to c++ types from Haxe definitions, with support from hxcpp types.

The page has more a clear example of what I mean by "without boxing".

[Raoul Duke]

> These are externs to c++ types from Haxe definitions, with support from
> hxcpp types.
> The page has more a clear example of what I mean by "without boxing".

Sounds like there's no extra indirection calling the function, but
there is for all arguments to it?

[Mike Welsh]

Congrats on the release!

- m

[azrafe7]

VoV. Awesome initiative, thanks for this!!

@jcward's post from not long ago (about native file dialogs) made me curious about CFFI and ndll, and this seems to simplify the process quite a bit.

(it seems that @jgranick is in the middle of integrating these nfd features into openfl/lime too).

I'd really love to read more about the semantics of the meta tags used, guidelines, and how to contribute properly.

(yes, I've gone through https://snowkit.github.io/linc/ and browsed the repos... I want MOAR!)

PS: 

 - What about neko support? 

 - Dialogs for Android/iOS via Qt?

[underscorediscovery]

Thanks Mike.

@azrafe7 :
You may note Jeff and I moved the dialog code from snow into the dialogs repo :) I pinged him regarding the work I had already done and he jumped in.
For now the best reference is the code-as-example on top of the notes and talks I linked there.

Neko: Not possible.
This outputs literal c++ calls and thus cannot be compiled against neko - as it says on the repo - hxcpp/cpp only.

Also noted on the guidelines: QT is a monolith and not going to be included as a dependency.
I'd rather just code the 20 lines for iOS and Android but note:
SDL provides basic message dialogs for those platforms already (and most frameworks are using SDL atm).
There are also no File open, save, or folder dialogs on iOS so I'm not sure what dialogs you mean exactly.

Thanks for the feedback!

[Jeff Ward]

This is definitely cool. The linc_dialogs lib was super easy to use in hxScout, and fulfilled my dialog needs (cpp target for win, mac, and linux.) I can't wait to play with the other linc libs! Thanks again, Sven, for walking me through the build.xml stuff - glad I could play along.

Best,

-Jeff

[Juraj Kirchheim]

This is VERY impressive!

About the neko support:

On a scale from somewhat tricky to total brainfuck, how hard would it be to build the C++ libraries + linc glue separately and use the Haxe definitions to generate neko modules that allow calling into them? Also, does this work with cppia, and if not, how hard (on the same scale :D) would it be to do that?

From the looks of it, much of the linc glue actually deals with signatures that take arguments by reference to return stuff. Have you considered using something like `cs.Out` (http://api.haxe.org/cs/Out.html) to avoid this layer? Maybe something like this:

    package cpp;

    

    abstract Out<T>(Pointer<T>) from Pointer<T> {

        @:from @:extern static inline function of<T>(v:T):Out<T> {

            return Pointer.addressOf(v);

        }

    }

And then you could simplify like so

    @:native('linc::sdl::pollEvent')

    static function pollEvent() : sdl.Event;:

    //becomes:

    @:native('SDL_PollEvent')

    static function pollEvent(event:cpp.Out<sdl.Event>):Bool;

No doubt, there's a couple of reasons why it's more complicated than that, but maybe the general idea is worth pursuing :)

Best,

Juraj

[Dan Korostelev]

cpp.Pointer/Reference currently doesn't play well with pointer-to-pointer (you get cast errors from C++ compiler), but I added some utility to cpp.RawPointer/RawConstPointer with this PR https://github.com/HaxeFoundation/haxe/pull/4500 that makes expressing out arguments easier.

вторник, 25 августа 2015 г., 10:04:20 UTC+3 пользователь back2dos написал:

[underscorediscovery]

There is definitely more than just the out arguments to consider, yea. cpp is quite a beast.

Neko or CFFI Prime bindings to all the endpoints is (as it was before) viable but somewhat missing the point of this.
I have considered adding bindings to some libraries but for now,
the focus is purely on native and improving the hxcpp workflow directly.

Cppia also cannot contain literal C++, it's haxe AST output, and doesn't get compiled by c++.

Most important with @:native stuff for me:

hxcpp is the pivot here, it is the thing to be pushed forward.

Solutions and fixes should be done to the existing tools (which are already great).

Once that is well expressive and fluid, looking to solve additional extraneous concerns like other targets makes sense.

There are still things to iron out regarding the externs,

and I think those should be prioritized (which Hugh and I have been up to with this).

[Juraj Kirchheim]

On Tue, Aug 25, 2015 at 11:01 AM, Dan Korostelev <nad...@gmail.com> wrote:

cpp.Pointer/Reference currently doesn't play well with pointer-to-pointer (you get cast errors from C++ compiler), but I added some utility to cpp.RawPointer/RawConstPointer with this PR https://github.com/HaxeFoundation/haxe/pull/4500 that makes expressing out arguments easier.

Ok, I had another look at it and got it working and small thanks to your hint - before I had `Pointer.ofAddress(v).get_raw()` :D

Lo and behold, I got hxcpp to generate `static Void modify_Int(  int *  x,int value);` as seen here: https://gist.github.com/back2dos/1e21fbc3506aec285055#file-main-h-L33

And it works like a charm \o/

On Tue, Aug 25, 2015 at 3:27 PM, underscorediscovery <sv...@underscorediscovery.com> wrote:

There is definitely more than just the out arguments to consider, yea. cpp is quite a beast.

I can't be the judge of that, since cpp just makes me feel like an illiterate. But if people with more experience call it a beast too, then that's reassuring :)

Chances are, I am totally misjudging this. I merely started reading the linc code and it seemed that quite lot of it dealt with out parameters. There's other stuff, that just plainly eludes me, e.g. what a ::cpp::Struct is, how this all can be made to play nicely with the GC and so forth. But maybe there are ways to bridge the gap between cpp and haxe in a less manual way (such as my experiment with out parameters), that reduce friction when interfacing with native cpp libs. 

Firstly, that would align with linc's goal to stay as close as possible to the original API, and secondly it would be far less tedious which makes it easier to add other libs, to maintain existing ones and to avoid errors.

Neko or CFFI Prime bindings to all the endpoints is (as it was before) viable but somewhat missing the point of this. 
I have considered adding bindings to some libraries but for now, 
the focus is purely on native and improving the hxcpp workflow directly.

Cppia also cannot contain literal C++, it's haxe AST output, and doesn't get compiled by c++. 

Most important with @:native stuff for me:

hxcpp is the pivot here, it is the thing to be pushed forward. 

Solutions and fixes should be done to the existing tools (which are already great).

Once that is well expressive and fluid, looking to solve additional extraneous concerns like other targets makes sense.

There are still things to iron out regarding the externs,

and I think those should be prioritized (which Hugh and I have been up to with this). 

Sounds reasonable. I was just wondering ;)

Best,

Juraj

[underscorediscovery]

The other goal is somewhat conflicting but just as relevant :
Being friendly to the Haxe user facing API. It's definitely a balance to strike.

I am not disagreeing about making things more fluid at all - that's in fact my entire goal here.
My key concern is that our efforts should be on making haxe/hxcpp handle the 99% and the library/binding handle the nuances.

The modify function looks quite interesting. Depending on how far it can go (I will play with it soon), 

it could make sense to be somewhere in cpp package as a helper for the use case. 

For info on cpp::Struct and cpp::Reference see the wwx 2015 talk (but it requires understanding those from a cpp perspective as well).

[Rafael Oliveira]

I saw a new "wave" on twitter of people outside the community interested in haxe, so hxcpp is a high priority. And the hxcpp guide on the manual need to be written to show all it can be done with hxcpp. 

[Hugh]

One thing you can do with referring to external out parameters (rather than defining you own) is the extern cpp::Struct/cpp::Reference thing I mentioned in my wwx2015 talk.

The basic idea is that in haxe, you have (then extern) "MyReference" extend (the extern) "MyStruct" - this means you can pass a myStruct to something that takes a MyReference without friction as far as haxe is concerned.  In the c++ implementation code,  MyReference actually wraps a pointer (like it does in c++) and will auto-cast to the pointer (unlike c++).

So you tell the haxe code that the extern is to a "MyReference", but the header file tells the c++ compiler that it is a "My *" - the overall effect is that when you pass a MyStruct to this function, the c++ compiler takes its address.  Using a reference as an outparam is pretty normal in c++.

The key here is that you have to think about how the haxe compiler sees the typing/code vs how the c++ compiler sees them, and then use the @:native meta to mess with the compilers head.

Hugh

[Jeff Ward]

Hugh, I think I followed that but a concrete example would be highly enlightening, especially in contrast to the "defining your own" referenced in the first paragraph.

Meanwhile, I'll go watch your talk. :)

[Sven Bergström]

Yea, that was the strategy I was heading for Hugh, I had only gotten about halfway converting the types to cpp::Struct and friends since!

Good to know that I wasn't too far off base with the thinking.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Hugh]

By "defining your own" I just meant a haxe abstract version.

This example does the opposite - that is, the struct inherits from the reference, which allows easy casting (assigning) from the reference to the struct, but may give you an idea of how you can manage the haxe and c++ compilers to get what you want:

https://github.com/HaxeFoundation/hxcpp/blob/master/test/native/externs/RGB.hx

https://github.com/HaxeFoundation/hxcpp/blob/master/test/native/tests/TestRgb.hx

Hugh

[Jeff Ward]

Thanks for the concrete examples, Hugh!