LiveCode Forums.

And here is, as you might say, the image that makes a certain point re my remarks:
- -
Look to the left!

Ooooo: it's Javascript.

And so it goes;
-

richmond62 wrote: Tue Aug 11, 2020 7:46 am

No constructive point in the OP's original post

I do think a bit more documentation about how one might connect "something" written in LiveCode
with "something" written in another programming language might not be a bad thing.

FourthWorld wrote: Tue Aug 11, 2020 8:14 am Here's a good starting point:
https://livecode.com/resources/api/#liv ... ript/shell

@ Richard -
I have to admit, Richard, I'm not sure how 'shell' would be used as a bridge from Lc to say, any other programming language either, unless you mean to write out and save a code snippet, then use shell to execute it at system level. The question would then be how you get any information back from said execution?

@ Richmond -

Hybrid programming might prove quite useful under certain circumstances; and while that
probably sounds like rediscovering the wheel, a way to make a 'wheel' using LiveCode that was well
documented would be a good thing.

I'd agree with that (the documentation part), but hybrid programming is nothing new. You've had experience with BBC basics, and while I don't know much about that family specifically, I *do* know that lots of other basics (and a few other high level languages) had inline assemblers or even the ability to use straight up binary available in them to speed up things they were just too slow at.

It wouldn't be much of a leap to think Lc could do the same, but I'm not sure of the benefit if it were applied to say, inline scripting of another scripting language

HyperCard of course . . .

All pause for bowing heads and muttering "ॐ, ॐ,ॐ" at mention of HyperCard.

did allow AppleScript inline . . .

That isn't still available in Lc? Shows how little I know

However, I was referring to a completely different scripting language, in this case .js

https://livecode.com/infinite-livecode-an-example/

"The engineering team at LiveCode recently published a technical whitepaper on how we’d like to make LiveCode Builder interoperate better with other languages by improving its so-called ‘foreign function interface’."

Aha . . .

Well, not quite what I meant.

richmond62 wrote: Tue Aug 11, 2020 10:26 am And here is, as you might say, the image that makes a certain point re my remarks:
-
Screenshot 2020-08-11 at 12.22.59.png
-
Look to the left!

Ooooo: it's Javascript.

And so it goes;
-
Screenshot 2020-08-11 at 12.25.49.png

JavaScript is used for the Dictionary, which is displayed using a Browser widget.

bogs wrote: Tue Aug 11, 2020 11:11 am

richmond62 wrote: Tue Aug 11, 2020 7:46 am

No constructive point in the OP's original post

I do think a bit more documentation about how one might connect "something" written in LiveCode
with "something" written in another programming language might not be a bad thing.

FourthWorld wrote: Tue Aug 11, 2020 8:14 am Here's a good starting point:
https://livecode.com/resources/api/#liv ... ript/shell

@ Richard -
I have to admit, Richard, I'm not sure how 'shell' would be used as a bridge from Lc to say, any other programming language either, unless you mean to write out and save a code snippet, then use shell to execute it at system level. The question would then be how you get any information back from said execution?

In LC, shell is a function; any result from executing it will be the return value.

It's fun to play with - consider exploring with bash to get a feel for how it works. Using rsync with it is even more fun (and very practical, since you can make your own rsync GUI to run your backups with it).

richmond62 wrote: Tue Aug 11, 2020 11:19 am HyperCard of course . . .

All pause for bowing heads and muttering "ॐ, ॐ,ॐ" at mention of HyperCard.

did allow AppleScript inline . . .

Similarly, LC offers "do <otherLanguageStatements> as...", where the "as" clause specifies the target language, where the target language can be any of the host-OS-provided options returned with the alternateLanguages function.

richmond62 wrote: Tue Aug 11, 2020 11:40 am https://livecode.com/infinite-livecode-an-example/

"The engineering team at LiveCode recently published a technical whitepaper on how we’d like to make LiveCode Builder interoperate better with other languages by improving its so-called ‘foreign function interface’."

Aha . . .

Well, not quite what I meant.

The list of things not wanted may be infinite. Can you describe what you do want?

FourthWorld wrote: Tue Aug 11, 2020 4:13 pm Similarly, LC offers "do <otherLanguageStatements> as...", where the "as" clause specifies the target language, where the target language can be any of the host-OS-provided options returned with the alternateLanguages function.

Pretty useless on 'nix though, as it is only supported on Mac, Win, and html5.

bogs wrote: Tue Aug 11, 2020 4:24 pm

FourthWorld wrote: Tue Aug 11, 2020 4:13 pm Similarly, LC offers "do <otherLanguageStatements> as...", where the "as" clause specifies the target language, where the target language can be any of the host-OS-provided options returned with the alternateLanguages function.

Pretty useless on 'nix though, as it is only supported on Mac, Win, and html5.

Lot's of things are "useless" on Linux (macOS is a certified Unix), like LC's window registry functions, support for macOS bundles, hardware integration for mobile devices, and other platform-specific features.

Most interoperability on Linux is done with stdin and stdout, where LC's shell function is the natural go-to.

Can you describe what you do want?

Prickle, prickle . . .

Seems I did that earlier:

What I meant is, for the sake of argument, to program a front-end in LiveCode and some of the
"heavy lifting round the back" in another language and be able to "spit out" a standalone application at the end of the work.

the host-OS-provided options returned with the alternateLanguages function

-
Well, yeah:
- -
But that completely misses the point.

I don't want to use Applescript in LiveCode (I want to use LiveCode).

BUT I want, when I "get stuck" with LiveCode (or, far more likely, when I find I can do somethings rather
more easily in, say, LISP), to do part of my programming work outwith the LiveCode IDE and then connect that work with
my LiveCode work into one functioning unit.

A chap who lives in my block of flats is a 'serious programmer' (i.e. not like Richmond)
and regularly does programming on the same project in C, C++, C#, PASCAL and Java.

richmond62 wrote: Tue Aug 11, 2020 5:13 pm

Can you describe what you do want?

Prickle, prickle . . .

Seems I did that earlier:

What I meant is, for the sake of argument, to program a front-end in LiveCode and some of the
"heavy lifting round the back" in another language and be able to "spit out" a standalone application at the end of the work.

I wouldn't want to see the company take on the considerable effort to create a standalone packager for any language that doesn't already have one.

As you say, "I want to use LiveCode".

richmond62 wrote: Tue Aug 11, 2020 5:23 pm A chap who lives in my block of flats is a 'serious programmer' (i.e. not like Richmond)
and regularly does programming on the same project in C, C++, C#, PASCAL and Java.

In practical terms, what does that mean? Has he found a compiler that will let you mix all those languages in source files, and produce a single executable?