I got mono 3.0.6 working with G-WAN and now I am trying to use G-WAN persistent pointers and KV Store using mono but don't know how to do it.
G-WAN does expose some functions on gwan_api.cs but the KV function and get_env is not there.
Is it possible to access this in mono?
Is it possible to access G-WAN's KV store in C# scripts?
No, and here is why.
We initially tried the wrappers we wrote but, like for JNI, the mandatory conversion overhead is defeating the purpose of light and fast calls.
Like Java, C# offers a plethora of solutions for almost everything G-WAN does natively and this is what should be used if you use either language.
Note that part of your application can be written in C/C++/D/Objective-C/Objective-C++ and call all the native G-WAN API directly while the rest of your application may use C# or Java.
That's the advantage for an Application Server to support different programming languages.
Related
While reading Kotlin to JavaScript tutorial, I'm just wondered what's the benefits of writing JavaScript code using Kotlin?
Beside,
there are already great tools for Javascript developing, like package-manager, Webpack, Gulp...
The benefit is similar to using javascript for server and client. A common language with shared code.
Kotlin can be used for server and client, and aspects of code can be shared. Can use JVM for back-end, and JS tools/frameworks for front-end.
I'm not necessarily recommending this approach, but can see value in it. If you already know Kotlin, it means you don't have to learn JS.
Kotlin is also officially supported for creating Android apps, and Jetbrains are in the process of allowing for development of iOS apps in Kotlin.
So, can use one language across all platforms.
I have a 64 bit cocoa project that needs to use a 32-bit rendering library, which I cannot port to 64-bit.
I decided to separate it to a rendering service, which will be compiled in 32-bit and will provide an interface for the library, and the main project, which will be compiled in 64-bit and will access the rendering service.
I am wondering what is the best way to do the interprocess communication. I am looking for a solution that will provide fast communication and easy api.
It seems that XPC (and specifically, NSXPCConnection) is the recommended solution nowadays. However, I'm not sure - is it implemented for 32-bit applications?
In addition, I need to pass a fairly large quantity of data (max ~5MB), and so I worry about the performance and speed of the XPC. Is shared memory mapping is possible/recommended in this situation? can it work in conjunction with xpc?
For 32-to-64-bit APIs, Apple does use XPC services in their own apps, like Pages, to migrate old data to a more recent API.
Although I have yet to get it to work using NSXPCConnection, and Apple's own apps use the functions found in xpc/xpc.h.
Our new iPhone project consists of a native app and a server it needs to communicate with. I'd like the server to be written in Python/Django.
The last time we created something similar, the server was in written in asp.net and it exposed relevant methods as a SOAP-based web service. This was very convenient, since we were able to generate almost all server communication code from the WSDL using http://sudzc.com/. Now I basically want to do the same, but with Django instead of asp.net. More specifically, I want to expose methods and objects over an API and I'd really like to have some automatic Objective-C code generation at the other end.
I've looked at a few libraries for Django that are supposed to expose RESTful APIs, and most people seem to recommend django-piston or django-rest-framework. Will either of them have a WSDL-style description that I can use to auto-generate ObjC-code, though? Is there another set of tools for achieving what I'm after that I should be investigating?
In my personal experience I don't know of anything that exists to generate client-side stubs in Objective-C for a REST service. However, there's a very good library called RESTKit that features a JSON or XML to object mapping layer, and nice features like CoreData integration and local caching. There are number of useful Stackoverflow questions on it.
So that can get you part of the way, since it will handle communication and object mapping. If you need to build code-generation, it could output code that sets up RESTKit's mapping structures.
Another REST client lib for iOS that I like a lot is LRResty, for its clean API, but it's lower level than RESTKit in that it doesn't have any built-in parsing/object mapping features.
In this similar stackoverflow question there's a link to something called wsdl2objc which sounds like it's in line with what you need on the iOS side (I've no personal experience with it, so ymmv, etc...)
Whenever I ask people about the difference between an API and a library, I get different opinions. Some give this kind of definition, saying that an API is a spec and a library is an implementation...
Some will tell you this type of definition, that an API is a bunch of mapped out functions, and a Library is just the distribution in compiled form.
All this makes me wonder, in a world of web code, frameworks and open-source, is there really a practical difference anymore? Could a library like jQuery or cURL crossover into the definition of an API?
Also, do frameworks cross over into this category at all? Is there part of Rails or Zend that could be more "API-like," or "libraryesque"?
Really looking forward to some enlightening thoughts :)
My view is that when I speak of an API, it means only the parts that are exposed to the programmer. If I speak of a 'library' then I also mean everything that is working "under the hood", though part of the library nevertheless.
A library contains re-usable chunks of code (a software program).
These re-usable codes of library is linked to your program through APIs
(Application Programming Interfaces). That is, this API is an interface to library through which re-usable codes are linked to your application program.
In simple term it can be said that an API is an interface between two software programs which facilitates the interaction between them.
For example, in procedural languages like C, the library math.c contains the implementations of mathematical function, such as sqrt, exp, log etc. It contains the definition of all these functions.
These function can be referenced by using the API math.h which describes and prescribes the expected behavior.
That being said, an API is a specification (math.h explains about all the functions it provides, their arguments and data they return etc.) and a library is an implementation (math.c contains all the definitions of these functions).
API is part of library that defines how it will interact with external code. Every library has API, API is sum of all public/exported stuff. Nowadays meaning of API is widened. we might call the way web site/service interact with code as API also. You can also tell that some device has API - the set of commands you can call.
Sometimes this terms can be mixed together. For example you have some server app (like TFS for example). It has API with it, and this API is implemented as a library. But this library is just a middle layer between you and not the one who executes your calls. But if library itself contains all action code then we can't say that this library is API.
I think that Library is a set of all classes and functions that can be used from our code to do our task easily. But the library can contain some of its private functions for its usage which it does not want to expose.
API is a part of library which is exposed to the user. So whatever documentation we have regarding a library, we call it an API Documentation because it contains only those classes and functions to which we have access.
we have first to define an interface ...
Interface :is the means by which 2 "things" talk to each other and exchange information. "things" could be a (1) human or (2) a running code of any sort (e.g. library ,desktop application , OS , web service ... etc).
if a human want to talks to a program he need Graphical user interface (GUI) or command line interface (CLI). both are types of interfaces that humans (but not programs) would like to use.
if however a running code (of any sort) want to talk to another running code (of any sort) it doesn't need or want a GUI or CLI ,it rather need an Application Programming Interface (API).
so to answer the original poster question : library is a type of running code and the API is the means by which this running code talk to other running codes.
In Clear and concise language
Library: Collection of all classes and methods stored for re-usability
API: Part of library classes and methods which can be used by a user in his/her code.
According to my perspective, whatever the functions are accessible to invoker , we can called as api in library file, library file having some of the functions which is private , we cannot access them ..
There are two cases when we speak or think of API
Computer program using library
Everything else (wider meaning)
I think, that in the first case, thinking in terms of API is confusing. It's because we always use a library. There are only libraries. API without library doesn't exist, while there's a tendency to think in such terms.
How about The Standard Template Library (STL) in C++? It's a software library.
You can have different libraries with the same API, meaning set of available classes, objects, methods, functions, procedures or whatever terms you like in some programming language. But it can be said, that we have different implementation of some "standard" library.
Some analogy may be that: SQL is a standard but can have different implementations. What you use is always some SQL engine which implements SQL. You may follow only standard set of features or use some extended, specific to that implementation.
And what "under the hood" in library is not your concern, except in terms of differences in efficiency by different implementations of such library.
Of course I'm aware, that this way of thinking is not what is a "generally binding standard". Just a lot of new terms have been created, that are not always clear, precise, intuitive, that brings some confusion. When Oracle speaks about Collections. It's not library, it's not API, it's a "Collections Framework".
Hello brothers and sisters.
Without using technical terms I would like to share my understanding regarding API and library.
The way I distinguish 'library' and 'API' is imagining a situation where I go to a book library. When I go there, I request a book which I need to a 'librarian' without knowing how a entire library is managed.
I make a simple relation between them like this.
Library = A book library which has a whole system and staffs to manage books.
API = A librarian who provides me a simple access to a book which I need.
Since MS appears to have killed Managed JavaScript in the latest DLR for both server-side (ASP.NET Futures) and client-side (Silverlight), has anyone successfully used non-obsolete APIs to allow scripting of their application objects with JScript.NET and/or can explain how to do so? A Mono/JScript solution might also be acceptable, if it is stable and meets the requriements below.
We are interested in upgrading off of a script host which uses the Microsoft JScript engine and ActiveScript APIs to something with more performance and easier extensibility. We have over 16,000 server-side scripts weighing in at over 42MB of source, so rewriting into another scripting language is out of the question.
Our specific requirements are:
Noteably better performance than the Microsoft JScript (ActiveScript) engine
Better runtime performance and/or
Retention of pre-parsed or compiled scripts (don't reparse on every run)
Lower or equal memory consumption
Full ECMA-262 ECMAScript compatibility
a little porting can be tolerated
Injection of custom objects into the script namespace
.NET objects (not a hard requirement)
COM objects or COM objects wrapped in .NET
Instantiation of COM objects from Script
à la "new ActiveXObject(progid)"
Low priority given the preceeding
Include files
Pre-loading of "helper scripts" into a script execution context
An "include" function or statement (easy to create, given the above)
Support for code at global-scope
Execution of code the global scope
Retention of values initialized at global scope
Extraction of values from the global scope
Injection and replacement of values at the global scope
Calling of script-defined functions
with parameters
and with access to the previously initialized global scope
Source-level debugging
Commercial or Open Source Support
Non-obsolete APIs
I answered a similar question here. Have a look at IronJS, an implementation of JavaScript in F# running on the DLR.
Sooner or later, I imagine someone will write a DLR Javascript. I know that's not very convenient for you right now, but maybe you could start the project. I suspect it would have a better cost/benefit analysis to using JScript.NET.
If moving away from .NET and Microsoft is ok for you then you should try Mozilla's Rhino. It is an open-source implementation of JavaScript written entirely in Java. Alot of modern server side js libraries target this platform.
I have used CSScript.net as it will allow you to run C# as a scripting platform. From the site:
CS-Script combines the power and
richness of C# and FCL with the
flexibility of a scripting system.
CS-Script can be useful for system and
network administrators, developers and
testers. For any one who needs an
automation for solving variety of
programming tasks.
CS Script satisfies all the conditions that you laid out. I have used it in production as a substitute for Boo it has performed really well. You can see it in action here.
The use of Com interop means you are limited to an MS solution Java and Opensource want as little as possible to do with it.
I dont see any solution that supports all your requirements either you ditch all the COM/.NET stuff and go Java (Rhino) /Linux/Open source or you question the use of Javascript as your server language even in the Linux world we use PHP/Python/Ruby more on the server if we cant run Java. Your not going to see big performance gains with Java script as the language is the main barrier.
I wouldnt count on people writing a new DLR as server Java script is dying fast.
Considering you want performance ,what about F# , Microsoft will keep the Jscript engine supported for at least 5 years giving you time to create new stuff in F# while you slowly migrate the code.
Have you seen ROScript?
http://www.remobjects.com/script.aspx
Supports both PascalScript and ECMAScript (Javascript) syntax
The Jurrassic-Engine is alive and kicking.
From their codeplex site:
Supports all ECMAScript 3 and ECMAScript 5 functionality, including ES5 strict mode
Well tested - passes over five thousand unit tests (with over thirty thousand asserts)
Simple yet powerful API
Compiles JavaScript into .NET bytecode (CIL); not an interpreter
Deployed as a single .NET assembly (no native code)
Basic support for integrated debugging within Visual Studio
Uses light-weight code generation, so generated code is fully garbage collected
Tested on .NET 3.5, .NET 4 and Silverlight