LC compilation

Mark Smith marksmithhfx at gmail.com
Mon May 29 19:25:21 EDT 2023


Hi Mike, sorry I thought it would have been copied with the reply. The original post from Skip Kimpel was more or less asking if LC is compiled. The exact post was…

	"Wait… what?  I have been away from this list for a while, LC is not currently compilable??

	SKIP”

I do have a question based on your reply. You indicate LC doesn’t compile but then go on to list all of the stuff it compiles into a standalone application (most of which, such as the LC engine, extensions, libraries, etc) are just (I would argue) libraries when it builds an application. Taking the definition of compiler as “a process to convert (a program) into a machine-code <https://www.google.co.uk/search?client=safari&channel=mac_bm&q=machine-code&si=AMnBZoFOMBUphduq9VwZxsuReC7YV6BL3UJP9cGsG2J_mNMPwgWXqX8HuVPC8gyFB81-plMkPkEzmbteRge93xxj5qVwJdYjXSPc2zeY_vz8RKYr_9tAP6Q%3D&expnd=1> or a lower-level <https://www.google.co.uk/search?client=safari&channel=mac_bm&q=lower-level&si=AMnBZoG9fGMZkoPgk-g4eVoaZFdERA6BgFgTvewAwu3qykvLOcqyjsbvyNVL0k7ItNaeg3uetPXhm4wenDJM9iNdxIwXbgNT_MfjGFunU2ur_NpUowaHa-E%3D&expnd=1> form in which the program can be executed.” I would argue it “sort of” does that in that the included scripts (as I understand it) are not in their original editable form but have been converted into something that is more easily interpreted by the engine. I know it’s not ML, nor is it bytecode, but it’s one step removed from the actually editable text in the script editor. Would’t you agree?

The true advantage of the byte code, I believe, is that it brings LC in line with other similar compilers and therefore allows a more sophisticated (and standardised) approach to code optimisation. Or at least that will be one of the advantages. Obfuscation of code, as you mention, is another (although I have never personally worried about anyone wanting to steal my code 😊). 

Mark


> On 29 May 2023, at 5:56 pm, Mike Kerner via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> I don't see the original post, so I can only part-comment on this.
> LC doesn't compile, per se. It builds standalone apps for all
> platforms, but those apps include the LC engine, extensions,
> libraries, and your stack(s). There is an obfuscator, but, no, no
> bytecode or ML, yet. The apps behave as you would expect a standalone
> app to behave, but, with a disassembler, you will have an easier time
> with them than you would with a ML or BC compiled app.
> The good news is that the current architecture makes remote debugging
> from mobes much simpler, and, whether you are on a desktop or mobile
> platform, you can include functionality such as side-loading and
> real-time code execution trivially.
> For example, let's say you have a debug build. If you include a button
> in your debug build, with the following script, you can prompt for a
> command, and execute it, live, in your standalone:
> 
> on mouseUp
>   global gDo
>   ask "Do what?" with gDo
>   if it is not empty then
>      put it into gDo
>      do gDo
>   end if
> end mouseUp
> 
> The above script will also, as I am sure you deduced, store the last
> command you typed, and prompt you with it, the next time you press the
> button.
> This is, of course, especially useful if you want to invoke the
> debugger and then debug some routine. You can do that like by clicking
> the button I just described, and then typing into the dialog:
> breakpoint;send "mouseUp" to button "someButton" # steps you through
> the debug button script, then to the mouseUp handler of "someButton"
> 
> We are all patiently waiting for the script compiler, which, as of
> last conversation with Mark W., is going to be a bytecode compiler,
> not a ML compiler.
> 
> On Mon, May 29, 2023 at 6:27 AM Mark Smith via use-livecode
> <use-livecode at lists.runrev.com> wrote:
>> 
>> Hi Skip,
>> 
>> I’m surprised no one has taken a stab at answering this. I'm certainly no expert on the internal workings of LC or compilers but I can take a stab at articulating what I think the answer is, and when I get it wrong someone else can jump in to correct me (I should probably know this stuff better anyway).
>> 
>> So if I am correct, the current environment converts LC script into some sort of (possibly binary) tree structure that is better organised to be executed by the LC engine. The engine is a big chunk of what I think is mostly Obj C (or some relative thereof) code that interprets the tree structures created in the first phase. So I guess that makes it sort of compiled? Compiled to execute in/on the LC engine, but also interpreted because the tree code is not executed on the target platform directly but is interpreted by the engine to generate the final executable result.
>> 
>> As far as the script compiler project is concerned, I believe the goal is to create a byte code stream that can be interpreted more efficiently by (a possibly new?) engine. Not sure about the new engine part, but the idea is the tree structure thing goes away and in its place is a linear stream of byte codes that can both be executed more effiencetly but also optimised more fully. This particular byte stream (and here I’m going way outside my wheelhouse) is similar to what other compilers like Java, Python, (Pascal? — which I do know was a byte code compiled run time interpreted language… although companies like Borland eventually wrote Pascal compilers that executed directly on the target platform without any interpretation) produce. So, it would bring the LC compiled code more in line with what other compilers are producing which means post compilation the code could be optimised more completely using well developed industry standard approaches. And so everything ends up a little smaller and faster but it also opens the door to doing other things with the script code down the road.
>> 
>> Well, that's my take on Mark Waddinghams’ most recent seminar on this topic. But he assuredly can fill you in much better than I can.
>> 
>> Cheers,
>> Mark
>> 
>> 
>> 
>>> On 28 May 2023, at 3:54 pm, Skip Kimpel via use-livecode <use-livecode at lists.runrev.com> wrote:
>>> 
>>> Wait… what?  I have been away from this list for a while, LC is not currently compilable??
>>> 
>>> SKIP
>>> 
>>>> On May 27, 2023, at 4:39 PM, harrison--- via use-livecode <use-livecode at lists.runrev.com> wrote:
>>>> 
>>>> Hi Skip,
>>>> 
>>>> Doubtful.  I would wait until after we have a compilable version of LC and then it will be more possible.
>>>> 
>>>> Rick
>>>> 
>>>>> On May 27, 2023, at 12:26 PM, Skip Kimpel via use-livecode <use-livecode at lists.runrev.com> wrote:
>>>>> 
>>>>> Has anybody done anything with LC and AR?
>>>>> 
>>>>> Curious minds want to know :)
>>>>> 
>>>>> SKIP
>>>> 
>>>> _______________________________________________
>>>> 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
>>> 
>>> _______________________________________________
>>> 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
>> 
>> 
>> _______________________________________________
>> 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."
> 
> _______________________________________________
> 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



More information about the use-livecode mailing list