There's now a new branch on my repository named "linux_alternate_languages".
You can now say things like
Code: Select all
do "--version" as perl
do "/home/mwieder/test.rb" as ruby
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Code: Select all
do "--version" as perl
do "/home/mwieder/test.rb" as ruby
Code: Select all
do <string> as <language>
Code: Select all
do "--version" as perl
Code: Select all
do "--version" as perl
Code: Select all
do myProgram as perl
Code: Select all
get shell("perl" && myProgram)
Code: Select all
do <args> as <language>
and
do <script> as <language>
Code: Select all
do <script> as <language>
Code: Select all
set the dragImage to <filename>
Code: Select all
set the dragImage to <id>
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.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:Rather than:Code: Select all
set the dragImage to <filename>
Indeed, it would mean that you'd have to write separate clauses dependent on platform:Code: Select all
set the dragImage to <id>
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
No doubt I'm missing some nuance here, but isn't that what the alternateLanguages function is for?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.
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."?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.
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.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.