Wrapping existing C libraries

1

Hello,

I’m coming to Haxe via a path of GnuCOBOL → NekoVM which led to Haxe. Main interest is still GnuCOBOL and NekoVM, but Haxe should not be ignored in that sphere it seems.

I started out with a simple goal of embedding the NekoVM in COBOL applications. Initial trials worked well.

https://sourceforge.net/p/open-cobol/discussion/cobol/thread/b0bfda7e/

(The link inside that link with the actual cobweb-neko.cob source listing and small demos, https://open-cobol.sourceforge.io/faq/index.html#can-gnucobol-interface-with-haxe-neko will take a while to load. That book is now a monster piece of HTML (which I’ll be fixing shortly to separate out chapters) and isn’t speedy on load).

GnuCOBOL generates C on way to executable, and embedding Neko was not really that difficult. Building code for samples was not difficult. Being completely green then, I though the Neko programming language was for writing applications on the first day of discovery; didn’t realize that NekoML is more important when it comes to non generated code. NekoML has near zero pages of documentation, and well, I stuck with writing Neko code for samples. Oh well, live, learn, eventually use.

Now the questions start to come up.

I’m also building a libAgar wrapper as a user defined function repository for use with GnuCOBOL and now I’d like to take a stab at building a hxagar package to provide (what I think is a pretty slick GUI) for Neko.

If you haven’t checked out Agar yet, it it’ll be a few minutes well spent. libagar is totally under utilized, like so many of the better technologies that don’t fluke into fame. Agar GUI

Now I’m wondering if the Neko ship is sailing away? Is Hashlink the new VM of choice for Haxe space? Haven’t been able to test much HL. I’m on a 64 bit GNU/Linux machine and all attempts at source builds are giving me bytecode version mismatches or use -m32 messages which I haven’t gotten round to yet. Testing is currently limited to HL 1.0 (no JIT in 64 bit, so only the .c outputs are testing ok here), and Haxe 3.4.7. I’m keen on Hashlink, being a C ABI space, and GnuCOBOL lives and breathes in C ABI space. But, I can’t find enough Help Getting Started information to get started with HL so will bide time until the packages are in distro repositories and there is some documentation beyond look at the code.

This might sound a bit facetious to anyone that actually has a Haxe Knowledge Base floating around in their heads, and can tell forests from trees. I’m still too new to even know what to look for.

End goal is CLI and GUI usage from Haxe and a Haxe space VM embedded in GnuCOBOL for access to features like XML and JSON (and all the other powers).

All of that preamble to ask a few opinion based questions:

  1. What is the sanest option for wrapping a fairly large C library for use from Haxe space? (Assume a CLI, Desktop or Web domain of use). Should it be hxcpp FFI and untyped functions or explicit wrappers with value types for Neko C-FFI? Assume the programmer is still learning Haxe/Neko during the relative chaos of the Haxe 3 to Haxe 4 timing and can’t be trusted to know anything truthful and won’t yet know where to look for relevant documentation.

  2. Does NekoVM have a best before date stamped on it now?
    (for that question, no wishful thinking please - what are the Haxe Foundation’s plans for Neko?)
    If the answer is No, Neko is here to stay, then will it get the love of a first born, or does it get relegated to being treated like the red headed step child? If the answer is Yes, Neko is destined to be completely superseded by HashLink, then when does the planned plug pulling transition start to occur?

  3. Would hscript be worth trying to build into a GnuCOBOL Foreign Language Intrinsic extension? By that I mean, is hscript useful for real work or is it mostly for exploring Haxe space?

  4. Should I even bother trying to convince COBOL programmers that Haxe/Neko/HL is worth looking into? Generalizing, but the 200+ billion lines of COBOL in production around the world is mainly boring, keep the lights on code. COBOL practitioners are as quick to look down nose at anything that seems (to them) to look like a toy, as most computer science programmers seem to be when looking at the practical un-fun computer business programming that is COBOL. GnuCOBOL changes that a bit, as it enters the C ABI world (and is free software), but the perceptions seem stuck (on both sides of the computer science / computer business divide).

Opinions welcome (except for the future of Neko bit; want to know what the Haxe Foundation team is actually planning for that one, if at all possible).

And thanks to Nicolas for the creations, and the Foundation and community for expanding the ecosystem.

Have good, make well

2 Likes
2

Hi,

I am using neko since about 12 years now together with Delphi as a plugin system. So I will try to answer some of your questions:

  1. As always - depends on your taste :slight_smile: I prefer writing wrappers since in neko everything is a value, which doesn’t map nice to native types and second in Delphi the standard calling convention is register and not cdecl. To reduce loading time I use lazy loaders:
private class M {
  static public dynamic function foo(par: Int): Int {
    foo = neko.Lib.load('module', 'foo', 1);
    return foo(par);
  }
}

It’s a bit more to type (or you can write a macro for that) but has the advantage, that the function foo is only loaded and linked when it is used the first time.
What you always must have in mind is, that Haxe/neko is garbage collected - this can cause funny things used together with manual memory manged code. To be safe I explicitly release any external object in my Haxe/neko code. Here it would be nice if Haxe had a try finally syntax.

2.I hope not since I have a lot of Haxe/neko code. But since it is Haxe you have options - HL or Lua or python for example. When I have a bit time I will try HL and if it works for my needs I will go hybrid (neko and HL) and then make a smooth change to HL step by step.

  1. hscript is not Haxe. It is a nice library for simple scripting and accessing your native classes, but you can`t declare any new types in it. So it is limited.

  2. Haxe is always worth looking at it :smiley:

cheers Adrian.

2 Likes
3

Thanks, Adrian

Great information. I’m looking forward to digging in with HL, but I think I’ll still plan a cut of hxagar with Neko.

Have good, make well