I need to invoke Lua/Python Scripts from a String or a File with the possibility to bind Java objects, so I can use them directly inside the script.
Something like:
e.bind("varname", object);
e.call("object.toString()");
Unfortunately Jython, which is perfect for my purposes, does not work on the dalvik vm.
I also tried kahlua, but it seems that I can´t bind objects to scripts there.
Assuming SL4A does not meet your needs, you will need to turn Python into a library (Lua already is one) and attach it your your application via the NDK.
And, as neither Lua nor Python know anything about Java, so you will have to write the glue code to connect your Java objects up to the Lua and Python scripts. I am guessing that this is possible, but that is just a guess.
This work will not be trivial, in all likelihood.
I finally found a scripting language, which also fits my purposes well.
It is called BeanShell and itself is as simple as it could be. Almost like Java.
Just checkout the official site:
BeanShell
It is not longer developed by the orinigal programmer, but an active project on google-code called beanshell2 is the follower of BeanShell.
You can find it here: BeanShell2
Related
we have some COBOL Caller Handlers which are executed/called by external applications built in VB/Java. what we are looking is instead of going through other applications, is there way to call those caller handlers directly from Python so we can test them directly from Python automation framework
I have a CICS program/transaction bound to a web interface in CICS, so that i can drive my transaction via http post/put/get, maybe you are looking for a tighter bind though?
For the Java APIs I would recommend, ditching python and wrting the tests in Groovy.
This is a scripting language that runs on a JVM, which means it can call all java APIs natively.
As well as support the normal builtin scripting stuff like dictionarys, currying functions, regex support -- all valid java code is also valid Groovy code. So you can cut and paste your java API calls into your testing scripts.
Python is available for z/OS in two distributions: from Rocket Software and (in beta form at the moment) from IBM. They're both free of charge. Here are the relevant links:
https://www.rocketsoftware.com/zos-open-source
https://developer.ibm.com/mainframe/2020/04/29/python-z-os-beta-is-ready/
Either one should give you the flexibility you need to invoke whatever other z/OS-hosted program you wish to invoke, whatever its programming language, without requiring any sort of network interface or other such configuration. Then you just decide how you'd like to interact with that program. As Cschneid suggested, do you want that to be via REST/JSON APIs? Great, CICS Transaction Server for z/OS supports that. So does Db2 for z/OS ("Db2 Native REST"), which addresses the COBOL part of your question if you're trying to invoke a Db2 stored procedure that happens to be written in COBOL. So does Python.
Another way to figure out a possible path is to figure out how the Visual Basic and Java applications are invoking these COBOL programs. That may not necessarily be the best way, but if it's still a reasonable way then perhaps you could adopt the same basic approach from Python.
CICS supports SOAP and REST, since 2008 I think. COBOL natively parses XML (and has for over a decade) and JSON (this is relatively new).
I want to create an app that will be extensible via plugins.
I know that I have 2 options.
I can create my own interpreted language and app with a built-in interpreter for this language.
I can use one of the existing languages such as Python, Lua or another scripting language.
I want to use option 2. And I know that I must create a layer for external language to enable communication between this language and my app. But I don't know how to do it. Maybe I must use interprocess communication or something like that.
Let's assume that I have an application written in C++. In the beginning, it may be even a simple console app that displays a few options. And I want to write a plugin in Python like this:
option = "additional option"
myApp.addOption(option)
And then:
I launch my app
My app loads the plugin
I see my app with this additional option displayed
I want to do this simple thing to understand how it works and then I will be able to do something more complicated.
You could start by looking at the languages' documentation(if you're new):
Python -->https://docs.python.org/3/
Lua --> https://www.lua.org/docs.html
C++ libraries can also be called in C(If you're careful enough),you could look at this too
https://www.teddy.ch/c++_library_in_c/
You should be aware that, with care, a C++ library can be called from a C program, mostly by appropriately using extern "C" to disable name mangling. On Linux, read also the C++ dlopen mini Howto.
Then you need to read the chapter Extending and embedding the Python interpreter
At last, Python is open source, so please study its source code.
I can use one of the existing languages such as Python, Lua or another scripting language.
I strongly recommend considering using GNU Guile or extending Ocaml.
And both TensorFlow or NumPy could inspire you, since they are open source libraries (coded in C and/or C++) usable from Python.
Currently I'm doing a project in Golang which need to call to Python.
In Python it's a library of singleton-like instance.
But I can't modify those library because It's too complicated. (for me)
Most thing I can do is wrap it with my own Python script.
So I'm finding a way to create multiple Python interpreter in Go.
Or maybe multiple sub-interpreter in Python.
Which mean I can create many python instance(same application).
Any ways I can do this?
As Chris Townsend and pie-o-pah said,
Trying to implement sub-interpreter is much more complicate.
Try to create the language interface is make senses to my case.
In this situation os/exec is the way to go.
And can even create ssh to remote my python module if my main server is overload.
I would like to build a "live coding framework".
I should explain what is meant by "live coding framework". I'll do so by comparing live coding to traditional coding.
Generally put, in traditional programming you write code, sometimes compile it, then launch an executable or open a script in some sort of interpreter. If you want to modify your application you must repeat this process. A live coding framework enables code to be updated while the application is running and reloaded on demand. Perhaps this reloading happens each time a file containing code is changed or by some other action. Changes in the code are then reflected in the application as it is running. There is no need to close the program and to recompile and relaunch it.
In this case, the application is a windowed app that has an update/draw loop, is most likely using OpenGL for graphics, an audio library for sound processing ( SuperCollider? ) and ideally a networking lib.
Of course I have preferred languages, though I'm not certain that any of them would be well suited for this kind of architecture. Ideally I would use Python, Lua, Ruby or another higher level language. However, a friend recently suggested Clojure as a possibility, so I am considering it as well.
I would like to know not only what languages would be suitable for this kind of framework but, generally, what language features would make a framework such as this possible.
I have implemented a live coding feature in Lua as part of the ZeroBrane Studio IDE. It works exactly as you described by reloading the application when a change in the code is made. I'm working on possible improvements to modify values at run-time to avoid full reload of the application. It's a pure Lua-based solution and doesn't require any modifications to the VM.
You can see the demo of the live coding as currently implemented here: http://notebook.kulchenko.com/zerobrane/live-coding-in-lua-bret-victor-style.
In terms of language features used/required, I rely on:
the ability to interrupt/resume a running application (this is based on debug.hook and error() calls),
the ability to interact with the (unmodified) application remotely (this is done based on debug.hook, TCP interactions with select() support to detect if a new request is being sent from the host machine, as well and on coroutines to switch between the main application and the live coding module), and
the ability to inject new code into the application (this mechanism is also using co-routines, but I'm sure there are alternatives). There is also a possibility to inject just a modified fragment, but it need to be at the level of a function, and if this function is a local to some other function, you need to include that too and so on.
Clojure has pretty much everything you are likely to want as a live coding language. Main highlights:
Interactive REPL - so you can interact directly with your running program. Even when I'm doing "traditional programming" I tend to write code interactively and copy the bits I like into a source file later. Clojure is just designed to work this way - pretty much everything in your program is inspectable, modifiable and replaceable at runtime.
Great concurrency support - you can kick off concurrent background tasks trivially with code like (future (some-function)). More importantly, Clojure's STM and emphasis on high performance immutable data structures will take care of the more subtle concurrency aspects (e.g. what happens if I update a live data structure while it is in the middle of being rendered??)
Library availability - it's a JVM language so you can pull in all the audio, visual, IO or computational tools you require from the Java ecosystem. It's easy to wrap these in a line or two of Clojure so that you get a concise interface to the functions that you need
Macros - as Clojure is a homoiconic language you can take advantage of the Lisp ability to write powerful macros that extend the language. You can effectively build the exact syntax that you want to use in the live environment, and let the compiler do all the hard work of creating the complete code behind the scenes.
Dynamic typing - the benefits of this can be argued both ways, but it's certainly a huge benefit when trying to write code quickly and concisely.
Active community with a lot of cool projects - you're likely to find a lot of people interested in similar live coding techniques in the Clojure community.
A couple of links you might find interesting:
Paul Graham on Lisp - beating the averages
Live Clojure coding example with the Overtone sound synthesizer (a frontend to SuperCollider)
The only thing that’s necessary to make this work is a form of dynamic binding, e.g., message passing in Erlang or eval in many other languages.
If you have dynamic binding, then you can change the target of a message without affecting the message, or a message without affecting the target—provided that a target is defined when you try to send a message to it, and a message is defined for the targets to which you send it, when you send it.
When changing a target, all you have to do is serve messages to the previous version until the new version is in place, then do a small locked update to transition to the new version. Similarly, when changing a message, you just serve the old version till the new one is available.
Readily hot-swappable code must still be designed as such, however—the application must be modular enough that replacing the implementation of a component does not cause an interruption, and that can only come from careful programming.
It's well and good to have 'live coding' on your dev box, but a way to directly interact with a deployed server takes it a lot closer to being 'real'. For this you need a network aware REPL.
clojure provides this nicely in the form of a socket repl. This allows you to remotely attach to the running version of your code on your deployed tomcat server (for instance). You can then attach your favorite swank-enabled development tool and hack away.
Smalltalk is probably the best bet for this. As unlike the others, it has a whole IDE for live coding, not just a REPL
Tcl has such a thing already. For example, you can write a gui program that creates a separate window that has an interactive prompt. From there you can reload your code, type in new code, etc.
You can do this with any gui toolkit, though some will be much harder than others. It should be easy with python, though the indentation thing -- IMHO -- makes interactive use challenging. I'm reasonably certain most other dynamic languages can do this without too much trouble.
Look at it this way: if your toolkit lets you open more than one window, there's no reason why one of those windows can't be an interactive prompt. All you need is the ability to open a window, and some sort of "eval" command that runs code fed to it as a string.
python on google appengine has repote_api_shell.py. this is not a full live-coding suite - clojure on emacs w/ swank-clojure has had much more real-life use as far as integrating 'livecoding' into everyday development rhythms - but a lot of people don't realize this is possible in certain python environments.
$ PYTHONPATH=. remote_api_shell.py -s dustin-getz.appspot.com
App Engine remote_api shell
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)]
The db, users, urlfetch, and memcache modules are imported.
dustin-getz> import models
dustin-getz> models.BlogPost(title='a modern take on automated testing', link='https://docs.google.com/document/pub?id=1DUxQogBg45rOTK4c5_SfEHiQcvL5c207Ivcy-gDNx2s', dont_publish_feed=False).put()
dustin-getz> items = models.BlogPost.all().filter('dont_publish_feed =', False).order('-published_date').fetch(100)
dustin-getz> len(items)
58
dustin-getz> for item in items[:5]: print item.title
a modern take on automated testing
Notes: Running a startup on haskell
the [un]necessity of superstar middle management in bigcos
"everything priced above its proper value"
stages of growth as a software engineer
I'm working on a live coding feature for PyDev's Python editor. It was inspired by Bret Victor's Inventing on Principle talk, and I've implemented a program state display as well as turtle graphics. They both update as you type your Python code in Eclipse.
The project is hosted on GitHub, and I've posted a demo video, as well as a tutorial.
The main features of Python that I used were abstract syntax trees and dynamic code execution. I take the user's code, parse it into a tree, then instrument any assignment statements, loop iterations, and function calls. Once I've instrumented the tree, I execute it and display the report or draw the requested turtle graphics.
I haven't implemented the swapping feature that other answers discuss. Instead, I always run the code to completion or a time out. I envision live coding as an enhancement to test-driven development, not as a way to hack on a live application. However, I will think more about what swapping out pieces of a live application would let me do.
Ok, so I really love HAML. Particularly, I love the integration with RedCloth and BlueCloth, so I can use Markdown and Textile intermixed with my HAML.
I also love Python and Django.
So, I would like to use HAML with Django. Now, I already understand that there are some attempts at cloning HAML-like syntax in Python (SHPAML and others). I've tried these, and while they aren't bad, I've found that I really just want the real HAML. Partially for its syntax, but also for things like RedCloth and BlueCloth.
So, my question is, how to make HAML and Django work together?
One solution, I think, would be to create HAML templates, and then compile them into HTML using the command line tool every time they're updated.
Quesiton 1: Will I run into any problems here?
I also wonder if there's a way to get Python and Ruby to play together a little more. One idea I had was actually forking out Ruby processes. This is probably a bad idea, but anyone have any thoughts about this?
Question 2: What about using Python to call the real Ruby HAML?
Finally, if anyone knows of a Python implementation of HAML that is complete, and that supports either Textile or Markdown, as well as plaintext passthru, then let me know.
Question 3: Is there a full translation of HAML to Python including Markdown or Textile support?
Thanks!
Question 1: static HTML files should work finely (unless you plan to use HAML's ruby evaluation feature to dynamically content). I use a similar way on a php website with SASS stylesheets. Just make sure you start HAML in directory watch mode before starting to hack ;)
Question 2: while forking a ruby process to create HTML code is possible, but I don't recommend it you, because initializing a ruby interpreter, and loading required files takes a lot of cpu times, so you better stick with static files. If you need the ruby evaluation feature to include runtime created data into the document, you'd better have a look at eventmachine, and make it a server (so your Django application can connect to it, and request HTML generation, without forking a new interpreter each time).
Question 3: maybe this is the hardest. There's GHRML which is abandoned; SHPAML which only implements a small subset of HAML, DMSL which is currently very experimental, but already supports most of HAML and also calling python code, but lacks Markdown or Textile support. But apparently there's no alternative (yet) to Ruby HAML that supports all the required features.
Try: http://github.com/fitoria/django-haml
I strongly recommend that you do not fork any processes out of your django views, because the overhead is significant.
You should have a persistent ruby process to serve your templates for you, and invoke it from your django code. I leave the IPC technology to you, but the obvious choices would either be some kind of message queuing technology, or speaking HTTP over a socket to the ruby process.
While this could end up being more trouble than it is worth, it is PROBABLY possible to leverage the Java or .NET platform and still run your Django application in Jython or IronPython (with some minor adjustments I'm sure) and also be able to leverage Ruby's HAML gem via jRuby or IronRuby.
I'm sure there will be some quirks in getting this to work, but I'm sure it would be possible.
Again, this is probably a lot more trouble than it's worth (considering that you'd have to move your application to a completely new platform), but it would be a pretty fun project to work on.