Does anybody know about binding two programming languages ? For example, I need to use C++ libraries in my Java code program? What is the solution? I need two different compiles, how can I bind them?
Related
Suppose I have a global function called foo() which I've implemented internally outside of Lua and exposed to the user. Ideally I'd like the user's IDE to be aware of this function for things like autocomplete. The closest thing that comes to mind would be a header file for C/C++, where the function is declared without being defined.
Does Lua have any support for this?
There is no cross IDE mechanism for this in Lua.
There is no way to declare a function prototype in Lua. You can only define function values. So unless you don't provide your functions as Lua code no IDE will be able to parse them for autocompletion. So you would have to provide IDE-specific autocomplete files for your API.
Most Lua development is probably done in a simple text editor anyway.
Provide a good documentation for your API and any Lua developer using it will be happy.
As Piglet mentioned there is no out-of-the-box solution for Lua that works across all IDEs. However, I found a typed variant of Lua called Teal which has support for declaration files. Teal seems fairly analogous to Typescript.
How do I use COM libraries from an F# script? Is it even possible? How do I reference the required COM libraries in an .fsx file?
More specifically, I'd like to use InstallShield Automation from a build script. Despite all my efforts, I could only get it to work with a regular compiled project.
Edit: I already tried the COM type provider project. However, it doesn't seem to find any types in the particular COM library I'm interested in. If it's a bug or intended behavior, I don't know.
I think possibly maybe the COM type provider might help you out:
One advantage of this method is that you can author and deploy F#
scripts without having to pre-generate the interop assemblies. Another
advantage is that you can easily explore all the COM components
installed on your machine via intellisense.
And yes I did just google it, which OP also might have done before asked here.
I know there are a number of projects which can compile F# to JavaScript.
Does any of these projects support this use case:
developing an application in TypeScript
but writing part of the application in F#, as a library
consuming this F# library from the main TypeScript application, optimally in a type-safe way?
WebSharper produces d.ts files for the compiled JS files. You can read about this in the relevant section of the documentation. However this feature is still experimental and uses an older version of TypeScript.
There is FunScript (https://github.com/ZachBray/FunScript) but it does not seem to be widespread, so it may take you more time than the benefits are.
I'm looking into Dart for server-side development and one of the things I'd need to use if I went that direction was LevelDB. There is a port for the JVM that I could use from Java or Groovy but I haven't been able to find anything in Google that points me to a leveldb package for Dart.
I know it's possible to write a native port that uses the C++ API but I'm neither a C++ nor a Dart programmer so while that's theoretically possible, it's out of the question for me personally.
Since LevelDB and Dart are both Google initiatives, surely there's integration somewhere isn't there?
I have written a LevelDB binding for Dart at https://pub.dartlang.org/packages/leveldb. Please try it out and file bugs for any issues you see.
To use LevelDB, which is written in C, you'll need to use the Dart VM's native extensions API. At the time of this writing, there is no open source binding for LevelDB and Dart VM.
Thanks for the question!
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any way to use some Scala for iOS coding?
Would it be possible to use the Scala.NET implementation, and then MonoTouch to run Scala code on an iOS device?
I have not been able to find a page with binaries of Scala.NET that I can test, so the following are just general guidelines as to what you can do with MonoTouch and .NET languages.
MonoTouch can run any ECMA CIL that you feed to it. When you consider using a new language with Monotouch, there are two components that come into play:
Tooling for the IDE
Runtime for the language
The tooling for the IDE is the part responsible for starting the builds, providing intellisense and if you use Interface Builder, it creates a set of helper methods and properties to access the various outlets in your UI. As of today, we have only done the full implementation for C#. What this means for an arbitrary language is that you wont get the full integrated experience until someone does the work to integrate other languages.
This is not as bad as it sound, it just means that you need to give up on using XIB files from your language and you probably wont get syntax highlighting and intellisense. But if you are porting code from another language, you probably dont need it. This also means that you would probably have to build your assembly independently and just reference that from your C# project.
So you compile with FoobarCompiler your code into a .dll and then reference in your main C# project.
The language runtime component only matters for languages that generate calls into a set of supporting routines at runtime and those routines are not part of the base class libraries (BCL). C# makes a few of those calls, but they are part of the BCL.
If your compiler generates calls to a supporting runtime that is not part of the BCL, you need to rebuild your compiler runtime using the Mono Mobile Profile. This is required since most runtimes target a desktop edition of the BCL. There are many other API profiles available, like Silverlight, Mono Mobile, Compact Framework and Micro Framework.
Once you have your runtime compiled with our core assemblies, then you are done
If you had read the MonoTouch FAQ, you would have noticed that it currently supports only C# and no other CLR languages.
Binaries for the Scala.NET library and the compiler can be obtained via SVN, in the bin folder of the preview:
svn co http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap
Bootstrapping has been an important step, and ongoing work will add support for missing features (CLR generics, etc). All that will be done.
For now we're testing Scala.NET on Microsoft implementations only, but we would like our compiler to be useful for as many profiles and runtime implementations as possible.
A survivor's report on using Scala.NET on XNA at http://www.srtsolutions.com/tag/scala
Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaNET/