MikeKerner at roadrunner.com
Wed May 24 16:02:28 CEST 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,
> 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
> Warmest Regards,
> 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:
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