API

[Michael Doub]

Richmond,

This maybe the blind leading the blind, but here is my take. Hopefully 
someone will correct me.

Take a look at ~/livecode/libscript/src/foreign.mlc.   Here is where 
foreign types are defined.

Now take a look at ~/livecode/libscript/src/math.mlc    Note that "use 
com.livecode.foreign" pulls in the type definitions

Just after the "use com.livecode.foreign" statement you can see where 
the foreign handlers are being defined and their arguments are being 
associated with data types.  I have not quite figured out the details of 
the bind directive, but I think it is providing direction to the 
compiler as to where to find the foreign code.

So line 38 sets up the arguments and data types for 
MCMathEvalSinNumber.  Now look at line 123.  This looks like where the 
sin operator  syntax is being defined for the LCB compiler. Line 129 
looks like where the _LCS_ interface for the sin function is being 
defined.   131 is where the native binding is happening between LCS and 
the native function MCMathEvalSinNumber.   Between all of these pieces 
is where the magic happen.

So if you assume that i am even remotely close to being correct, let's 
go look at ~/livecode/tests/lcb/_testrunner.lcb

line 20 is pulling in the type definitions
line 44 is defining the mapping of the parameter for the __system 
function.  Note that the binding is different.
line 46 is defining the Shell command for LCS
line 48 is where the magic is taking place.

I am still trying to figure out how the "bind to ... " works. Some where 
there has to be a linkage between this "bind" step and the OS level 
library,  So at run time, the library is loaded into memory and the 
final address resolution takes place.

I hope that someone will confirm/correct/ or otherwise educate.

Regards,
     Mike




On 3/23/15 3:19 PM, Richmond wrote:
> On 23/03/15 12:30, Peter TB Brett wrote:
>> On 2015-03-22 22:59, Peter W A Wood wrote:
>>> Richmond
>>>
>>> I believe that Richard’s “providing OS API access” is a
>>> simplification, probably an over simplification, of “providing the
>>> ability to access the OS API”. As I understand, LiveCode Builder will
>>> allow us to write code which can directly call an OS API but, of
>>> course, we will need to define the OS API function in LiveCode
>>> Builder.
>>>
>>> I had a quick scan of the LiveCode Builder files in Github but didn’t
>>> see any examples so the facility may not even be in the current
>>> release .
>>
>> https://github.com/runrev/livecode/blob/develop/tests/lcb/_testrunner.lcb#L44 
>>
>>
>> It's in there.
>>
>>                   Peter
>>
>
> Obviously there is a socking great hole in my education as I cannot 
> for the life of me
> see how I can use that information:
>
> "foreign handler __system(in Command as ZStringNative) returns CInt 
> binds to "system"
> handler Shell(in pCommand as String) returns Number
> variable tExitStatus as Number
> put __system(pCommand) into tExitStatus
> if tExitStatus is in [0, -1] then
> return tExitStatus
> end if
> if the operating system is "linux" then
> -- Basically the WEXITSTATUS macro from C...
> return tExitStatus shifted right by 8 bitwise
> else
> return tExitStatus
> end if
> end handler"
>
> to hook onto an API . . .
>
> Richmond.
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode