Is there a way to use a "kind" defined in std.ndll in another ndll?

[Max S]

Hi there.

I'm trying to grab k_socket kind defined in std.ndll in my ndll for Postgres driver (I need it for implementing the poll()/select() on a set of database connections). Defining my own "k_socket" doesn't help since the "val_check_kind(o,k_socket)" in all of the socket low-level C functions determines it's another one and throws an exception. Making it extern just fails on loading the library with undefined symbol.

Thanks.

[Hugh]

There is "kind_share" which is designed to help with this, but if the original lib does not do this, then it is not much use.

So I suggest either not checking the kind, or initializing your library by passing in a new dummy socket, and then use "val_kind" to extract the kind and save it in a local variable.

Hugh

[Max S]

2016-09-07 8:22 GMT+04:00 Hugh <game...@gmail.com>:

There is "kind_share" which is designed to help with this, but if the original lib does not do this, then it is not much use.

I noticed the
        kind_share(&k_socket,"socket");

lines in the init.c for std.ndll, but how do I get something from kind_names list? I don't see any code referencing it in the neko interpreter and it's not even declared extern.

 

So I suggest either not checking the kind, or initializing your library by passing in a new dummy socket, and then use "val_kind" to extract the kind and save it in a local variable.

Option one is not available since it's neko socket code that checks the kind. Option two is... a hack but it should work, thanks.

 

Hugh

On Wednesday, 7 September 2016 00:36:59 UTC+8, Sam wrote:

Hi there.

I'm trying to grab k_socket kind defined in std.ndll in my ndll for Postgres driver (I need it for implementing the poll()/select() on a set of database connections). Defining my own "k_socket" doesn't help since the "val_check_kind(o,k_socket)" in all of the socket low-level C functions determines it's another one and throws an exception. Making it extern just fails on loading the library with undefined symbol.

Thanks.

--
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 the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Max S]

So... what do I do in HXCPP when the module uses neko compatibility layer and needs to return value of k_socket kind? :)

If I include NekoFunc.h, grab the kind of a dummy socket (passed from Haxe level) and use:
  vkind k_socket = val_kind(sock);
  int ret = 10; // actually socket here
  return alloc_abstract(k_socket,(value)(int_val)ret);

This works but won't pass the val_sock() checks in socket functions like poll().

I've tried this:
  Dynamic s = _hx_std_socket_new(false);
  vkind k_socket = val_kind(s);

says s is not "value".

And this:

  #include <hx/StdLibs.h>
  ...

  Dynamic s = _hx_std_socket_new(false);
  vkind k_socket = (vkind)(intptr_t)(s->__GetType());

compiles fine but the application itself won't start with "Error : Could not load module" due to this line "Dynamic s = _hx_std_socket_new(false);"

[Hugh]

This is actually a bit tricky because there are 2 generations of the socket code.

The older code used the std.ndll, and was invoked via the loader functions.

The newer code uses the functions in  NativeSocket.socket and links directly to the code.

The older code is implemented in project/libs/std/Socket.cpp and needs the ndll (or links it in as a .a file)

The newer code is in src/hx/libs/std/Socket.cpp and will pull the cpp directly into the cpp code.

The  _hx_std_socket_new call is from the newer code.

The newer code allocates a "SocketWrapper" class, rather than wrapping the socket-int directly as abstract data.  And in fact it looks like it does not share the vkind variable and this pretty much keeps everything private.

I guess your goals are to be able to

A. create a haxe socket from your ndll file, and

B. get the actual SOCKET out of a haxe socket in you ndll code.

and there are 3 cases:

1. neko

2. older hxcpp

3. newer hxcpp

Does this sound right?

I'm thinking of something like in you haxe code, pass in some functions for "create_socket(Int):Dynamic" and "get_socket(Dynamic):Int" to you ndll and just call those.

These functions will look different on 1, 2, and 3, and I think I will need to add some code to hxcpp to support 3.

[Max S]

2016-09-28 9:10 GMT+04:00 Hugh <game...@gmail.com>:

This is actually a bit tricky because there are 2 generations of the socket code.

The older code used the std.ndll, and was invoked via the loader functions.

The newer code uses the functions in  NativeSocket.socket and links directly to the code.

The older code is implemented in project/libs/std/Socket.cpp and needs the ndll (or links it in as a .a file)

The newer code is in src/hx/libs/std/Socket.cpp and will pull the cpp directly into the cpp code.

The  _hx_std_socket_new call is from the newer code.

The newer code allocates a "SocketWrapper" class, rather than wrapping the socket-int directly as abstract data.  And in fact it looks like it does not share the vkind variable and this pretty much keeps everything private.

I guess your goals are to be able to

A. create a haxe socket from your ndll file, and

B. get the actual SOCKET out of a haxe socket in you ndll code.

Goal A is correct. Goal B I don't need, it was just the way I've solved the problem in cases 1 and 2 - creating a dummy socket and grabbing its kind.

 

and there are 3 cases:

1. neko

2. older hxcpp

3. newer hxcpp

Does this sound right?

Yes, with your previous help I managed to solve cases 1 and 2 passing the dummy socket into ndll code (case 2 is more of a older Haxe like 3.2.1 which does not have the cpp.NativeSocket class) but Haxe 3.3.0-rc1 uses cpp.NativeSocket which explicitly links the new code and that's where it breaks up. The dummy socket that I pass to the ndll code is a SocketWrapper thing and it looks like neko wrapper val_kind() can't get the right kind from it (no runtime errors, though, at least, until I try to use the returned Haxe socket in Poll.poll()).

In the new Haxe version the problem becomes not about getting the kind, but creating the actual SocketWrapper from the low-level socket integer since val_sock() calls everywhere in new socket code do static_cast to SocketWrapper.

 

I'm thinking of something like in you haxe code, pass in some functions for "create_socket(Int):Dynamic" and "get_socket(Dynamic):Int" to you ndll and just call those.

These functions will look different on 1, 2, and 3, and I think I will need to add some code to hxcpp to support 3.

If you mean adding socket_create(Int) to cpp.NativeSocket then yes. I don't need socket_get() but someone surely might.

You want me to make an issue with proper description?

[Hugh]

Ok - I understand this.  An issue will make sure I wont forget it.

[Max S]

Done.