python externals

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

Locked
monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

python externals

Post by monte » Sun Nov 17, 2013 11:09 pm

I just came across this project http://elmer.sourceforge.net and thought I would throw a topic up here incase anyone was keen on python externals. From the looks of things I don't think it would be all that tricky to put together a toolchain for python based lcidl externals. Probably not something I have time for but I just thought I'd throw the idea out there. Making LiveCode an easy GUI toolkit for python could really open some doors I think.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: python externals

Post by malte » Mon Nov 18, 2013 11:02 am

I also think so. And we need as many doors open as we can possibly have. On top of that, there is a boatload of python stuff out there, that is rather interesting. :-)

Best,

Malte

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: python externals

Post by LCMark » Sat Nov 23, 2013 12:43 pm

Elmer looks quite neat - it certainly looks (superficially at least) as if Elmer operates in a way which would be easy to leverage in lcidlc.

Wild
Posts: 5
Joined: Sun Sep 01, 2013 10:58 am

Re: python externals

Post by Wild » Fri Sep 12, 2014 1:14 pm

This does look interesting. Is there any way to promote this to official feature request status? I'm surprised there are so few "me too" posts on this thread.

I learnt programming through Hypercard (and to a lesser extent Psion's OPL) back in the mid nineties and watched sadly as Apple kept kicking it down the drain while everyone else recognised its power. The world wide web used its idea of hyperlinks between stacks to make hyperlinks between websites. Wikipedia was inspired by it technologically (and inspired by The Hitch Hiker's Guide ideologically). Even Spyglass / Internet Explorer mimicked Hypercard' pointing finger cursor for when a user hovers over a hyperlink!

Then for many years I have been a Python programmer, mostly writing command-line scripts because developing a GUI is too much effort compared to the good old Hypercard days.

So we're all used to the Hypercard Script Editor having a popup menu (Windows users: read combobox) saying "Scripting language:" with the options "HyperTalk" and "AppleScript". It would be really awesome for LiveCode to have a popup menu listing "Python" as an available interpreter. Then you could write something like:

Code: Select all

import livecode

def mouseUp(self):
    livecode.beep()
    livecode.put('Hello world')
    livecode.answer('Hello world', 'Awesome!', 'Not bad!')
    livecard.do('put "Brought to you by Python!" into the message box', 'HyperTalk')
Back in 2006 there was PythonCard, but it wasn't as mature as LiveCard. And Elmer would be a good access path to get XCMD / XFCN -type plugin architecture for Python. But listing arbitrary langauges/versions in the "Scripting language" popup menu, corresponding to paths to interpreters supplied by the user in the Preferences, would be the most elegant. And that's really where Hypercard excelled.

Ultimately, xTalk had the world on a plate back in the days of Hypercard, but Apple insisted on ignoring every golden opportunity it presented, and intentionally missed the boat. It is fantastic that enthusiasts have produced various Hypercard clones with colour and cross-platform support. But asking people to learn xTalk now, is a hard sell - when they already know HTML, Javascript, PHP, Python, PERL and similar languages that have filled the market niche left when Hypercard died. Languages which already have demand in the industry. Languages that are perceived as being worthwhile to learn. If a newcomer to LiveCode discovers they can gain from the ease of design LiveCode offers, and yet author in a language they already know, that significantly lowers the barrier to entry and gets LiveCode the recognition and promotion it deserves. This will get xTalk exposure and, in time, acceptance.

With open source and community involvement, there's a great deal more forethought and passion behind LiveCode than Apple ever put behind Hypercard. Apple's priorities against inclusivity invited the market to neglect xTalk the first time around, and most of the world obliged. Now the eWorld is larger so the stakes are higher. It would be nice to see RunRev turn history on its head here, and embrace the languages coders bring with them.

Programmers are a language's best ambassadors.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: python externals

Post by FourthWorld » Fri Sep 12, 2014 3:42 pm

You can call Python from the command line, so you could trigger any Python script using LC's shell function.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Thierry
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 875
Joined: Wed Nov 22, 2006 3:42 pm

Re: python externals

Post by Thierry » Fri Sep 12, 2014 4:17 pm

You can call Python from the command line, so you could trigger any Python script using LC's shell function.
Well, shell() and externals are not really for the same purpose
With externals you can do much powerful things..

I.e, here is a very old script of mine in Perl used behind a Livecode-Perl-external:

Code: Select all

use  RevClass ;

# Let's create few widgets...
my $button   = Rev::Button->new(  { name => "Button1",  } ) ;
my $control2 = Rev::Control->new( { type => "Button",   name => "Button2",  } ) ;
my $control3 = Rev::Control->new( { type => "Field",    name => "Field1", } ) ;
my $control4 = Rev::Field->new(   { name => "Field2",  } ) ;
my $group    = Rev::Group->new(   { name => "GroupA", } ) ;
my $card2    = Rev::Card->new(    { name => "SecondCard",   children => [ $control3, $control4 ]     } ) ;
my $stack    = Rev::Stack->new(   { name => "AlfredStack",   filename => "FFF", children => [ $card2 ] } ) ;
my $card     = Rev::Card->new(    { name => "FirstCard",       owner => $stack             } ) ;

# 2 ways to Set Owner: owner attr in new(), or set_owner() method.
$button->set_owner( $card ) ;
eval { $stack->set_owner( $stack ) } || warn "$@" ;

# 2 ways to Set Child(ren): children attr in new(), or add_child, add_children.
$stack->add_child( $card ) ;
$card->add_child( $group ) ;
$group->add_children( $button, $control2 ) ;

print STDERR "Warning expected: " ; # It's not a container !
eval { $control3->add_child() } || warn "$@" ;

print "DUMPING: ".  $card2->_DUMP() ;
print "Stack tree-like:\n" , $stack->walk_and_print() ;

my $iterCard = Rev::Iterator->new( { root => $card2 } ) ;
print "CardIteration1: ",  $iterCard->get_next() , "\n" ;

my $iter = Rev::Iterator->new( { root => $stack } ) ;

while ( my  $node = $iter->get_next() ) {
  print "StackIteration:" . ". " x  $iter->get_depth() ;
  print " " . $node->get_type() . " ->  $node \n" ;
}
print "CardIteration2: ",  $iterCard->get_next() , "\n" ;
print "CardIteration3: ",  $iterCard->get_next() , "\n" ;

$iter = Rev::Iterator->new( { root => $stack, filter => [ "fIELd","group"] } ) ;
while ( my $node = $iter->get_next() ) {
  print "Iteration with filter: " . $node->get_type() . " ->  $node \n" ;
}

$iter = Rev::Iterator->new( { root => $stack, filter => "card" } ) ;
while ( my $node = $iter->get_next() ) {
  print "Iteration with filter: " . $node->get_type() . " ->  $node \n" ;
}
Regards,

Thierry
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: python externals

Post by FourthWorld » Fri Sep 12, 2014 11:31 pm

Thierry wrote:Well, shell() and externals are not really for the same purpose
With externals you can do much powerful things..
Very true, and if someone has time to write an interface to Python that would be cool.

I mentioned shell because the real value of mixing languages comes from using each for the things it's best at. Right now most of the externals for LC are written in C because of either speed or a need to talk to C-based OS APIs.

Given that LC performs roughly on par with other good scripting languages, I wouldn't anticipate performance to be a draw to interfacing with another scripting language. And with the forthcoming widgets subsystem, we probably won't need any other language for most OS API calls.

That said, one thing some of the best scripting language have is a much longer history of being open source than LC, so over the years they've acquired a wide range of libraries for all sorts of things that'll take our community just as long to write for ourselves. When we can access those other capabilities from within LC, we can sometimes avoid having to reinvent those wheels altogether for some tasks.

R is a favorite example because it's very focused, and in an area that's not LiveCode's focus (though given LC's flexibility I wouldn't be surprised if we saw a growing library of analytics functions in the coming years).

While it would be cool to have an external for R, much of what we'd want to use R for in LC can be done right now through shell.

So yes, using shell isn't a replacement for externals. But for many of the tasks where we'd want to use another language as an incidental part of a LC project, it can be helpful to get some useful results with what we have right now.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Wild
Posts: 5
Joined: Sun Sep 01, 2013 10:58 am

Re: python externals

Post by Wild » Thu Sep 18, 2014 2:21 pm

FourthWorld wrote:You can call Python from the command line, so you could trigger any Python script using LC's shell function.
While that's perfectly fine during the development phase, to be calling out to external interpreters to execute external files, it isn't very elegant, portable, easily distributable. The developer would need to require each end user installs prerequisite dependencies (ie Python 2 or 3), configure PATH, etc and ship the external files too. In addition, there is a significant overhead cost each time the interpreting environment is fired up. If a button's on mouseUp event handler simply called an external Python file, it wouldn't be very responsive. If many/most events were being offloaded to an external interpreter that was launching, running the script passed that time, then quitting, the whole application will seem pretty sluggish.

Besides, such an implementation would either involve an already-competent Python programmer having to learn sufficient xTalk to be able to invoke external script files with whatever environment variables / execution arguments / memory-mapped file regions / etc. they needed in order to get the job done, that we're back to being a high barrier-to-entry OR somebody writes a good-enough cookie-cutter recipe online, then rampant copypasta antipattern ensues, and suboptimal hybrid hackware results.

I think ideally the script editor would have native support for Python -- or any subflavour that would be easier to implement; perhaps Jython so that the compiled Java bytecode can be stored during final packaging and executed in the JVM on the target host system. So when the developer writes def mouseUp(self, Sender): directly into the script editor, that gets recognised as overriding an xTalk signature, automatically and invisibly wrapped up into a suitable structure, and invoked directly by the engine when the user clicks on the object.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: python externals

Post by FourthWorld » Thu Sep 18, 2014 4:15 pm

Wild wrote:
FourthWorld wrote:You can call Python from the command line, so you could trigger any Python script using LC's shell function.
While that's perfectly fine during the development phase, to be calling out to external interpreters to execute external files, it isn't very elegant, portable, easily distributable. The developer would need to require each end user installs prerequisite dependencies (ie Python 2 or 3), configure PATH, etc and ship the external files too. In addition, there is a significant overhead cost each time the interpreting environment is fired up. If a button's on mouseUp event handler simply called an external Python file, it wouldn't be very responsive. If many/most events were being offloaded to an external interpreter that was launching, running the script passed that time, then quitting, the whole application will seem pretty sluggish.

Besides, such an implementation would either involve an already-competent Python programmer having to learn sufficient xTalk to be able to invoke external script files with whatever environment variables / execution arguments / memory-mapped file regions / etc. they needed in order to get the job done, that we're back to being a high barrier-to-entry OR somebody writes a good-enough cookie-cutter recipe online, then rampant copypasta antipattern ensues, and suboptimal hybrid hackware results.
Perhaps I was thrown off by the title of this thread, which seems rather different from what Monte outlined in his post.

Writing externals in any language would require sufficient knowledge of both LiveCode and its externals API, and the resulting module would need to be compiled or at least statically linked into some standalone form.

But it seems the interest here is in using LiveCode as a GUI layout editor for coding in Python:
I think ideally the script editor would have native support for Python -- or any subflavour that would be easier to implement; perhaps Jython so that the compiled Java bytecode can be stored during final packaging and executed in the JVM on the target host system. So when the developer writes def mouseUp(self, Sender): directly into the script editor, that gets recognised as overriding an xTalk signature, automatically and invisibly wrapped up into a suitable structure, and invoked directly by the engine when the user clicks on the object.
An interesting idea, perhaps also expandable to support Java directly, along with JavaScript, C, or other languages.

To be able to mix and match various languages within LiveCode would be nice, but it seems somewhat daunting to consider the scope of work needed for the LiveCode IDE to include compilers/VMs for each of the other languages it might support.

And for many LiveCode users, the language is a big part of the attraction. LiveCode's layout tools are nice enough but given the range of GUI layout toolkits like those for Qt, it seems a lot of work to rewrite the LiveCode engine to include the Python VM when it's easy enough to write "on mouseUp" in native LiveCode.

That said, if there's sufficient interest in this one could probably make a pretty nice IDE for other languages in LiveCode - here's one made for Erlang:
http://lists.runrev.com/pipermail/use-l ... 41172.html

With all of LC's object properties easily exposed, one could translate UI layouts into QTML or whatever definition formats are used by wxWidgets, and tie it all together nicely with shell calls to the VM/compiler. This wouldn't allow mixing LiveCode and Python together in a single app, but would support the goal of providing some of the LiveCode IDE's benefits to those who prefer not to use its native language.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: python externals

Post by monte » Fri Sep 19, 2014 1:58 am

FourthWorld wrote:Perhaps I was thrown off by the title of this thread, which seems rather different from what Monte outlined in his post.
The original post was about using elmer as a step in the compile process of an lcidl python external. The lcidl compiler takes a fairly simple high level language interface definition and pumps out glue code to sit between the actual external code in C,C++,Objective-C or Java (on android) and the engine. The idea was you could say in the lcidl file that the external was implemented in python and you wouldn't need to worry about the generated glue code. This is much more of a baby step than what is being suggested now but quite achievable as a contribution for someone that knows python and C and would like easy access to python libraries etc.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Wild
Posts: 5
Joined: Sun Sep 01, 2013 10:58 am

Re: python externals

Post by Wild » Fri Sep 26, 2014 10:51 am

Indeed, the original post was about linking external Python resources into your LiveCode development.

I'm coming from a standpoint of a LiveCode evangelist trying to convince people to pick up hypertalk and give it a(nother) chance. The challenge is that English-like easy-to-read interpretive scripting is no longer the greenfield available to Hypercard. It's now dominated by other, newer, languages. It's hard to convince someone who already knows (for example) Python that they should spend some hours learning a new language without much industry recognition. Starting, as they see it, right at the bottom and having to learn new ways of doing things they already know how to do in their more familiar language. It's not time efficient to consider for any significant application.

So my enthusiasm recognised an opportunity here. Something like Elmer could bring Python execution within reach of LiveCode, with some considerable degree of user hand-holding along the way... but if a Feature Request were to run with this idea, then Elmer could be used behind the scenes to automatically manage access to Python scripts - no user intervention required. That way the user just sees the Script Editor of a button, and for that button, they can select to write in Python. For another button's script, they might explore some simple xTalk. What starts out with them writing everything in familiar Python will make LiveCode an indispensable part of their toolbox (with all the revenue stream that brings) and that increased exposure will get people experimenting during their leisure time, learning and ultimately embracing xTalk. They just need an 'easy' way in - an excuse to justify trying.

Wild
Posts: 5
Joined: Sun Sep 01, 2013 10:58 am

Re: python externals

Post by Wild » Sat Sep 27, 2014 4:50 am

I've been highlighting Python in this thread mostly because that's what the thread was spawned for. But if you search RunRevPlanet for "Create LiveCode Externals in Pascal" you'll see there is also rrpPascalSDK which uses the rrpAPI glue code to execute Open Pascal via the Externals mechanism. I see tremendous benefit to the whole LiveCode project if the IDE had seamless integration for choosing a scripting language (from a supported list) for each script in a stack. I think once the infrastructure to do so was in place, community effort would utilise it to add support for LUA, Ruby, AutoHotKey, etc. It might not always be the latest version and fully featured, but having that option would still be a significant strength.

PaulDaMacMan
Posts: 616
Joined: Wed Apr 24, 2013 4:53 pm
Contact:

Re: python externals

Post by PaulDaMacMan » Sun Dec 06, 2015 5:29 pm

I know this is an old thread that had gone of topic but I thought I should point out another method for mixing in another script language:
I've been playing around a bit with mixing JavaScript with LC using a web browser instance & revBrowserExecuteScript(tBrowserInstanceID, tMyJavaScipt) or revBrowserCallScript(gBrowserInstanceID, tMyJavaScipt). It's pretty speedy once your browser instance is loaded (which can be HTML/Scripts stored in LC fields or variables). I'm also using this method to use a web plug-in directly from LC so that adds another layer of extending LCs capabilities.
My GitHub Repos: https://github.com/PaulMcClernan/
Related YouTube Videos: PlayList

Locked

Return to “Engine Contributors”