Writing Extensions

Mike Kerner MikeKerner at roadrunner.com
Wed May 24 10:02:28 EDT 2017


It's just difficult to get my brain wrapped around it, still.  Elanor's
course (that I think still has not been released to the public) was a help,
but more of that is needed, since we aren't in your brain.

On Wed, May 24, 2017 at 9:21 AM, Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> On 2017-05-24 14:55, Mike Kerner via use-livecode wrote:
>
>> On the CompileIt thoughts, that was what I was hoping we were going to get
>> with LCB (We already have Double-XX).  You could make any Mac Toolbox call
>> in CompileIt, which meant you could build any XCMD/XFCN to add to your
>> stack, but the syntax was still HC (with some restrictions).
>>
>
> LCB already has the ability to call C functions - which is what CompileIt
> allowed you to do (as far as I understand). However, there is a fair bit of
> glue required to deal with things like C arrays (which are just pointers at
> the end of the day) and structs - that is something we would like to make
> much easier.
>
> [ That being said, many C APIs are moving towards 'opaque pointers with
> accessor functions' rather than exposing C-bound concepts - mainly because
> that way it is much easier to bind to 'higher-level' languages (Python,
> Ruby, JavaScript etc.) - which just mean you have to deal with opaque
> pointers. ]
>
> What we don't have is much documentation as to *how* to use the features
> which already exist. Although there is some usage of the feature littered
> about in some of the engine LCB files, I can appreciate that is not that
> easy to grok.
>
> We also have an almost complete Java FFI system - Ali is currently working
> on the final piece: adding 'Listener' support (essentially callbacks) which
> the Android APIs use ubiquitously - e.g. for event handlers on Views.
>
> I can attest to the fact that LCB FFI (for C) works - our LCFM plugin is
> written in LCB and the FM Plugin API is wrapped in LCB using the current C
> FFI features which are available (doing so has given me some more ideas
> about how to make such things easier *and* safer - which is a critical
> factor these days).
>
> For Mac / iOS APIs we need to add a way to wrap an Obj-C object, and
> implement a Delegate (although you can manipulate Obj-C objects through a C
> API so technically you can do this already, if you don't mind a bit of bit
> munching). However, now we have done Java, Obj-C should follow very
> quickly. Both Obj-C objects and Java objects have very similar (abstract)
> properties in terms of how you access from from native code; and Listeners
> and Delegates are very similar things also.
>
> In terms of actually compiling stuff to native code - it is a goal we
> have; but there are a few more ducks to get in a row before it can become a
> reality.
>
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."



More information about the use-livecode mailing list