I am having great results so far with libraries and widgets. i am just skimming over some of the features as part of my learing process.
Would it be possible for someone to post an example of a "foreign" handler calling a c library? Along with an example of binding to a library.
My main platform is windows where normally one would import lib and or use headers in c++ to call a library.
Skimming the help docs, i simply cannot see the direction LCB will take to do this on windows.
I hear calling libraries is a lot simpler on osx/linux but I don't have much experience with those oses.
Foreign handlers
Re: Foreign handlers
@n.allan: At present the 'foreign handler' mechanism we have is quite basic in that it doesn't do much to help transform from LCB types to low-level (foreign) types beyond the basic ones (pointer, boolean, integer, real). However, that being said, the same formalism is used on all platforms - the only difference with Windows is that the WIn32 ABI has a zoo of calling conventions (the Win64 ABI does not). However, essentially that just comes down to an extra annotation in the binding string.
Despite its immaturity you can still do a fair bit with the foreign handler interface as it is now - I'll see if I can work up a WIn32 example today to give you an idea about how to go about playing around with the feature.
Despite its immaturity you can still do a fair bit with the foreign handler interface as it is now - I'll see if I can work up a WIn32 example today to give you an idea about how to go about playing around with the feature.
Re: Foreign handlers
Great! I am no where near the point of using them in anger yet, but just a taste of how it will work would be good before I continue my initial prodding.
Re: Foreign handlers
@ Mark
I am also interested in the taking advantage of the ability to build wrappers to get access to native libraries. Can you elaborate a bit on how this is envisioned to work at the architectural level. I think I see what you are trying to do at the language level with the data type bindings. What is the mechanism to locate and load the foreign library? Are language elements going to be added to load and remove libraries or are they going to be static.
Thanks
Mike
I am also interested in the taking advantage of the ability to build wrappers to get access to native libraries. Can you elaborate a bit on how this is envisioned to work at the architectural level. I think I see what you are trying to do at the language level with the data type bindings. What is the mechanism to locate and load the foreign library? Are language elements going to be added to load and remove libraries or are they going to be static.
Thanks
Mike
Re: Foreign handlers
@mdoub: You're post on the use list was an accurate assessment of the current implementation of the foreign mechanism. Indeed, most LCB syntax is implemented as foreign handlers. Currently foreign handler bindings occur the first time (at runtime) the handler is used and the VM uses the binding string to locate the symbol. We need to do more work here but if you dig into the script-instance.cpp source file you can see its current syntax... Only C binding is implemented at the moment - and it still needs some work 
You'll be able to access both system libraries and private libraries you've compiled yourself and included in the extensions package. We're still working on the latter though.
You'll be able to access both system libraries and private libraries you've compiled yourself and included in the extensions package. We're still working on the latter though.
Re: Foreign handlers
Thanks Mark. I figured that it was still very early in the implementation and this is one of the more complicated areas.
I do think that you are going need a mechanism to allow the user to specify the path to the desired library. It might be reasonable to make assumptions of the locations of the system libraries, but you are going to need more flexibility for optionally installed packages. You may even need to allow this to be set up in LCB dynamically. What has got me thinking this way is considering testing an app against multiple versions of the same server component. Each version has libraries installed in it's own directory.
Anyway, keep up the good work! This is great stuff.
-= Mike
I do think that you are going need a mechanism to allow the user to specify the path to the desired library. It might be reasonable to make assumptions of the locations of the system libraries, but you are going to need more flexibility for optionally installed packages. You may even need to allow this to be set up in LCB dynamically. What has got me thinking this way is considering testing an app against multiple versions of the same server component. Each version has libraries installed in it's own directory.
Anyway, keep up the good work! This is great stuff.
-= Mike
Re: Foreign handlers
@mdoub: Our current imagining of 'foreign handler' support is that you either bind to libraries which exist on the system already, or to compiled blobs which are within a module's package (and are private to it). All OSes provide suitable means to set the library path search order for the former, whilst the latter would be entirely controlled by the engine / standalone build process.
In terms of truly 'dynamic' access - i.e. loading a shared library at runtime and then dynamically looking up a handler explicitly at that point - then that it is almost covered by LCB's current functionality; the only bit missing is the ability to create an LCB handler value out of an arbitrary pointer. With the latter functionality you could just bind to 'dlopen', and 'dlsym' as foreign handlers and create a handler value out of the result of 'dlsym'.
The way handler values are set up in LCB means that they are all (notionally) of type 'handler', but you have to place them in a specific handler-type variable before being able to use them (since the compiler needs to know the signature ahead-of-time so it can compile in/out/inout arguments correctly).
In terms of truly 'dynamic' access - i.e. loading a shared library at runtime and then dynamically looking up a handler explicitly at that point - then that it is almost covered by LCB's current functionality; the only bit missing is the ability to create an LCB handler value out of an arbitrary pointer. With the latter functionality you could just bind to 'dlopen', and 'dlsym' as foreign handlers and create a handler value out of the result of 'dlsym'.
The way handler values are set up in LCB means that they are all (notionally) of type 'handler', but you have to place them in a specific handler-type variable before being able to use them (since the compiler needs to know the signature ahead-of-time so it can compile in/out/inout arguments correctly).