mikedoub at gmail.com
Mon Mar 23 16:41:46 EDT 2015
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.
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:
>>> 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
>>> 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 .
>> It's in there.
> 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
> return tExitStatus
> end if
> end handler"
> to hook onto an API . . .
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode