Converting Python

[Mark Wieder]

Björnke-

Wednesday, September 18, 2013, 4:34:20 AM, you wrote:

> I'm on Waddinghams side here. "Do as <other language>" is
> integrated with the "alternateLanguages". If something isn't in the
> alternateLanguages, it does not belong into "do as <other
> language>". So what you'd probably need to convince him (and me) of,
> is to find a reliable way to get available languages into the
> "alternateLanguages", and then make the execution of the language
> work  with "do" after that.

Well, if I do say so myself, that's a rather simplistic analysis. The
alternatelanguages as it currently exists is not just os-specific,
it's tied to the idea that certain language implementations are bound
into the os. Python, for example has nothing to do with OSX. But there
is a specific implementation of python which has osa bindings, and so
the engine code can query the osa structure to see if it's been bound
in. If you install a different python engine it won't be recognized.

> So the real linux-related problems are therefore:

I don't think this is a linux-related problem, but a more systemic
LiveCode-related problem, that of tying the "do as" function to the
"alternatelanguage" function. Decoupling the two functions allows for
a syntactic sugar over the shell function and insulates the engine
from future changes in os binding.

> 1. Is there any os-suplied way to query available scripting
> languages

There shouldn't be. If I install ruby on a computer, I'm not required
to somehow inform the os of this - ruby will be found in the path, and
and it will run from the commandline without any further prompting.
Yet somehow I'm supposed to inform LiveCode that this has been done.

> 2. Is there a way to run scripting languages without going trough
> a shell-like wrapper (because mark has said he wants it to work the
> same as on other platforms)?

That's what "do as" is for. And indeed, the code I've written first
checks to see if the specified language is in the alternatelanguages
and does the usual thing if so. If not, it creates a wrapper for the
shell command and returns the result. On all desktop platforms. IF the
language you have specified isn't installed on the target system you
get an error returned. This is the same behavior as the current one.

> In the end, wouldn't your goal be easier achieved with a modified
> shell() function that allows to pass fields as if they're files (for
> multi-line scripts)?

...so your thinking is that modifying the shell function is somehow
better than modifying the do as function?

-- 
-Mark Wieder
 mwieder at ahsoftware.net