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@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 ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > _______________________________________________ > use-livecode mailing list > use-livecode@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." _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
