LiveCode Forums.

I fiddled around with lnxspec.cpp and got alternate languages working on linux.
There's now a new branch on my repository named "linux_alternate_languages".

You can now say things like

nice!

Your message contains 5 characters. The minimum number of characters you need to enter is 10.

I don't see why the code I implemented wouldn't work on the other platforms as well, but I'm not in a position to try that out at the moment.

Oops. Apparently I pushed the wrong branch. Backing out of it now.

That is indeed very nice, Mark.

Jan Schenkel.

I pushed the latest changes, and now have this for all three desktop platforms.
In the interest of DRY coding, I'd like to move this out of the separate platform-specific files (lnxspec.cpp, osxspec.cpp, w32spec.cpp) but I could use some guidance as to where might be a more reasonable place to put a function that would be called from all three.

Update: for now, I've moved the common routine into dskspec.cpp, and that seems to do the trick.

Great addition Mark!

Apologies for not getting around to looking at this until now, but I've not had as much time as I'd like to keep an eye on the forums for the last wee while...

While I like the idea of improving the 'do as alternate language' mechanism I do see a slight problem with the current proposed extension to it - it is completely different in semantics from the existing mechanism. At the moment 'do ... as <alternate language>' works with whatever scripting host provider is available to provide a script directly to an interpreter to execute. The new functionality (in its current form) is essentially just syntactic sugar around 'shell()'. This presents two problems, as far as I can see...

The first is that of expectation. At the moment I can query 'the alternateLanguages' to see what languages are available on the platform and then when I do: Then <string> is considered to be a snippet of <language> which then gets executed by the appropriate interpreter. Furthermore, 'the result' of the snippet (however that is defined in the target language) is grabbed and returned in 'the result'.

The second is that of cross-platform compatibility. It is not beyond the realms of possibility that (say) on Windows (where the 'Windows Scripting Host' environment is extensible) that someone might have 'perl' installed as one of the supported languages. In which case: Will work completely differently on that Windows machine (where it will break) from others, and from other platforms.

If we are going to extend the 'do as language' feature then it should work the same on all platforms, and in the same way - if not, then I guess a different syntax would work but at the end of the day, as currently posed: Is no different from shell("perl --version") -- and at least with that it is absolutely clear what is actually going on (i.e. it doesn't lead the scripter to think that something 'magical' is happening).

Now, many other languages are embeddable - perl is, for example (http://www.linuxjournal.com/article/2901) - and using a mechanism such as that (albeit, on a per-language basis) would provide a more natural integration with existing functionality (indeed, the ScriptEnvironment abstraction that is already present is ripe for an 'extension-point', an interface that is exported from the engine that can be implemented in a loadable library that provides access to other languages - the 'CustomPrinter' abstraction is done like this).

@runrevmark- thanks for getting back to me on this. Some thoughts here:

1. yes, it's more or less syntactic sugar around the shell command. I'm opening a process and returning the result. But I disagree and think there is a cognitive difference between
and One difference is that the "do as" form doesn't return an error string if the proposed language doesn't exist, i.e., the result from "do myProgram as grunt" is an empty string. I'm not sure yet whether this is a bug or a feature.

2. The impetus for this addition is the fact that there are no "alternateLanguages" in LC on linux. I'm explicitly separating out the "alternateLanguages" function from the "do as" functionality. I do not think it should be up to LiveCode to determine whether or not a user has installed a given program. It's certainly possible to extend the alternateLanguages to query the system, but having a hard-coded set of available languages is inflexible, doesn't allow for a changing environment, and ignores features that may well be present by default. Currently "do as" is useless on linux... is there any reason *not* to allow this?

3. Tying "do as" to "the alternateLanguages" doesn't ensure compatibility across different operating systems, just that the same feature is available. Doing a particular VBScript may have different results on different Windows systems, for instance. I think ensuring compatibility across environments, if necessary, should be up to the scripter, not up to the mechanism in the engine. Yes, "do xxx as perl" will break (or more precisely will not do anything) on a system that doesn't have perl installed, but as a developer I'd be remiss in not specifying perl as a requirement for that application.

@mwieder:

1) There is certainly a cognitive difference in providing higher-level syntax for an operation than just having to perform the operation itself. However, with this change there would be an actual difference between both the action of the command and what the expressions in the syntax mean: And that difference comes about just by switching platforms.

2) The point here is that you cannot separate 'do ... as ...' from the 'alternateLanguages' feature. The syntax: *Is* the syntax for the alternateLanguages feature - there's nothing in the syntax to be able to distinguish between the semantics you propose and the semantics that exist already on the other platforms.

Whilst the implementations are different on Mac and Windows, the semantics of them are largely the same - you give the engine a script and a language, and it executes that script in that language. Just because the feature is not currently implemented on Linux does not mean that syntax is available there for something that works in a different way - that very much goes against the 'cross-platform' spirit of LiveCode syntax.

To give an analogy, the dragImage isn't currently implemented on Linux, but I don't think anyone would be happy if (on Linux) you had to do: Rather than: Indeed, it would mean that you'd have to write separate clauses dependent on platform: The point here is that by-and-large, the same syntax on all the platforms does work in the same way meaning you don't have to switch on platform. Now, I realize that there are many cases were platform-specific issues do crop up and mean this is necessary, but they should be the exception and not the rule (and gradually removed over time), and wherever possible the situation should not be made any worse.

3) The point here is not about compatibility in the effects of the command, but compatibility in the semantics of the syntax. The action is (of course) tied to platform-specific concerns - you are dealing with large opaque blobs of functionality (i.e. Windows Scripting Host, Open Scripting Architecture) over which LiveCode has no control and so a script that uses this feature has to be written with this in mind.

Certainly ensuring that the necessary pre-requisites are installed that an app requires is beyond the realm of LiveCode, but if they are installed there is an expectation that syntax on one platform will work in the same way as syntax on another platform.

As I pointed out in my previous post - 'perl' is an example of a language that has an embedding API. If someone came along in the future and wanted to add 'perl' to the alternateLanguages on all platforms (the perl embedding API appears to be cross-platform), then they could. However, if they did then programs that are using the variant you propose would break... Indeed, as posed (the proposed functionality being a 'fallback' if a language isn't present) already introduces this problem. On Windows, LiveCode has no control over the list of languages Windows Scripting Host provides so it is perfectly possible that some systems could have 'perl' as one of the alternateLanguages, if it does then a script that relies on the proposed variant would break.

Regardless of functionality, the point here is that we cannot really change the semantics of the syntax 'do <string> as <language>' as they have already been defined. The proposed feature has significantly different semantics so, at the very least, it needs different syntax.

runrevmark wrote:To give an analogy, the dragImage isn't currently implemented on Linux, but I don't think anyone would be happy if (on Linux) you had to do:

Code: Select all

  set the dragImage to <filename>

Rather than:

Code: Select all

  set the dragImage to <id>

Indeed, it would mean that you'd have to write separate clauses dependent on platform:

Code: Select all

  if the platform is "Linux" then
    set the dragImage to the filename of image id <id>
  else
    set the dragImage to <id>
  end if

Well, actually if it meant the difference between not having any option for a dragImage at all I'd welcome it without hesitation.

Sure, it's another OS-specific thang, but it's not like we don't have many already and if there's no other way to solve a problem I'd vote for the closest workaround as opposed to having no means of implementing feature parity across OSes in our apps at all.

As I pointed out in my previous post - 'perl' is an example of a language that has an embedding API. If someone came along in the future and wanted to add 'perl' to the alternateLanguages on all platforms (the perl embedding API appears to be cross-platform), then they could. However, if they did then programs that are using the variant you propose would break... Indeed, as posed (the proposed functionality being a 'fallback' if a language isn't present) already introduces this problem. On Windows, LiveCode has no control over the list of languages Windows Scripting Host provides so it is perfectly possible that some systems could have 'perl' as one of the alternateLanguages, if it does then a script that relies on the proposed variant would break.

No doubt I'm missing some nuance here, but isn't that what the alternateLanguages function is for?

Coming back to this dead horse once again:

Whilst the implementations are different on Mac and Windows, the semantics of them are largely the same - you give the engine a script and a language, and it executes that script in that language.

Er... so on linux if I "give the engine a script and a language" should I not expect that it "executes that script in that language."?

Just because the feature is not currently implemented on Linux does not mean that syntax is available there for something that works in a different way - that very much goes against the 'cross-platform' spirit of LiveCode syntax.

The point, though, is that it does *not* work in a "different" way. Currently the only time the alternatelanguages is checked is when the engine does a "do as" statement, and then the engine checks to see if the specified language has been bound into the OS before execution. I have removed that check, so as to open the "do as" command for more flexibility. On all platforms. You can still look at the alternatelanguages to see what has been bound to the OS if you want to, and it will return empty on linux, but I fail to see any advantage in checking this from a script. And no advantage from the engine's perspective except to enforce a historical limitation with no other useful purpose.

The alternatelanguages property is no magic bullet for idiot-proof external language execution. An example of the current situation:

The developer installs ActivePerl on OSX, which adds an entry to the existing osaxen. Perl then shows up in the alternatelanguages on the developer's system, and she can issue "do as perl" commands in a script. The onus is then on the developer to specify that ActivePerl must be installed on end user's systems to avoid runtime errors.