Hello Stackoverflowians -
I'm working with an embedded system that's written in C that communicates over a cell modem to a server written in Ruby on Rails. There message format is fairly simplistic and uses several constants to define messages types.
Right now, the ruby side of things takes the C include file, and scans for the constant definitions, and imports those via const_set.
Is there a better way to keep the ruby side sync'ed up with the C side of this project?
Thanks,
-- Mike
Since you're comfortable with C, my suggestion would be to create a Ruby extension in C that uses the header from the C application to expose the constants. That way you're not stuck to declaring the constants in a specific way or custom parsing routines.
See guides.rubygems.org for a concise introduction to the topic.
Related
Hey so I was thinking about learning Lua and this question struck to me, that can I program a game which only has Lua code no C++,C, Or side-libraries of C, C++?
Lua is an embedded scripting language. Like most scripting languages, it runs inside of some application that actually executes what the language says for it to do. So if you want to get technical, it is impossible to run Lua without first running something involving "C", because that "something" is what makes Lua code possible to execute at all.
Because Lua is an embedded scripting language, what you can do with it is ultimately defined by the environment into which it is embedded. lua.exe is one embedded environment, but there are others.
So this question is probably intended to be this: Can I make a game in Lua written against the lua.exe environment, without adding supplemental, non-Lua modules?
Sure: so long as that game works within the limitations of the text console that lua.exe executes within. The standard Lua environment provides access to all of the Lua standard library, but that library is actually quite tiny. The only IO it provides is access to standard in, standard out, standard error, and files.
That's it.
You can make a text adventure game with that. With some knowledge of how to control the text console more directly (which is platform-specific), you can use the console to display ASCII-art graphics. So you could make an old-school Rogue-like, so long as timing isn't a factor, since the Lua standard library has no mechanism for doing that.
Yes, you can make a game of some kind. But the kinds of games you can make with it are probably not what you're thinking of when you said "game". The Lua standard library offers nothing that would allow you to do audio of any kind or anything visual except for sending text to standard out.
Because Lua standard library is intended for any application that needs to embed Lua, it is quite tiny, providing a small baseline of functionality and nothing more. It isn't intended for you to create graphics-intensive applications.
For that, you would need to explore a Lua environment that is designed for that, which provides functionality specific to those needs.
Of course, there are many games made only in Lua and others where you can program mods or servers inside them with Lua only like Roblox or FiveM. If you want to make an entire game using only Lua scripts, you can try using a proper engine for this as for example GameGuru
You can also try some Lua libraries made to program games like Love2D and CoronaSDK
The official site as well as some other sources describe one of the benefits of Google Protocol Buffers as being highly inter-operable. I know the technology supports different language bindings out of the box, and many more as third party implementations, but what does that mean exactly?
Is my understanding correct in thinking that as long as I have a common schema file, I can run the protoc compiler and generate code for multiple languages, and then write a program in one language using the generated code, serialize some data to a file, and then parse it in another language in another program?
For example, could my client-side application running in Java serialize a Google Protocol Buffer and send it over the wire to a server implemented in C++ which can then parse it and use it readily as long as both sides were generated from the same schema file?
If that is correct, what allows that to happen - is it that their serialization/parsing logic adhere to a common/consistent wire format detailed here?
Yes, you can, and yes, it is because the wire format is fixed (i.e. the same for any language binding).
What are the typical use cases of using an embeddable programming language? Do I understand it correctly that such language should be embedded into some program environment and should be able to be executed from there?
Since you tagged the question as "Lua", I'll give you an answer in the context of this language.
Introduction
Lua is written in C (almost completely compatible with C89 standard; the incompatible features can be easily disabled, if needed, using compile-time switches) and has been designed to be easily integrated with C code. In the the context of Lua, "integrated" means two different, but related, things:
You can easily write C code that can be used as a library by Lua code. The integration is achieved either by static or dynamic linking your C code to Lua engine's code. The linked library can then be referred to in your Lua code using the Lua require function.
Lua engine can be easily embedded in a C application, i.e. linked (again either statically or dynamically) to the C application code. Then the C application can interact with the Lua code using Lua's C application programming interface (Lua C-API).
Note: this can be done, with a little more effort, also with a C++ application.
Advantages of embedding a Lua engine
If your C application embeds Lua many, if not most, operations can be delegated to the Lua engine, i.e. either to code written using the C-API functions or, better yet, Lua code. Lua code could be embedded as C strings inside your C code or be stored as external Lua scripts.
Having part of your code logic implemented using Lua code has several advantages:
Lua is simpler (less tricky) to learn and use than C, and it is much more high-level. It supports powerful abstractions, such as function closures and object orientation (in a peculiar way, using Lua tables and metamethods).
Lua is a dynamic language: it requires no "off-line" compilation. You can modify the text of your Lua script and that's all you need to modify your application behavior (no additional compilation+linking steps needed). This simplifies application development and debugging.
Lua is a safer language than C: it is really difficult to write Lua code that exhibits undefined behavior, as intended in the context of C/C++. If a Lua script fails, it fails "loudly". Moreover Lua supports an exception mechanism (although with a different syntax than C++) which can be employed to implement error management in a much easier way compared to C.
Lua, as most dynamic languages, is garbage collected. This means that the programmer is spared the pain of manually managing dynamic memory, which is a major cause of bugs, leaks, instability and security loopholes in languages that lack garbage collection.
Lua can "eat its own dog food", i.e. you can build a string at runtime (even in Lua itself) and if it is valid Lua code, your program can execute it on the fly. This is something not frequently seen even in other dynamic languages (still it is not LISP, but it gets closer, and with much more readable syntax). This enables Lua scripts to:
employ powerful text-based metaprogramming techniques, where Lua code can generate other Lua code and execute it on the fly;
implement domain specific languages (DSLs) in an easy way; Lua code can load at runtime other Lua code that is crafted so as to reflect the specific problem domain in which it is used (Lua syntax is simple, yet flexible enough to allow such things);
be used as a configuration language with ease: your application (written in a mix of C and Lua) can use some lua files as configuration files without the need to craft an ad-hoc parser for a specific configuration file format. Therefore you don't need to parse *.properties, *.csv, *.ini, or whichever other format you would choose if you hadn't the option of using Lua files for that purpose.
Lua engine has a very small memory footprint (some hundreds kBs), packing powerful capabilities. With very few C code lines and a bunch of Lua files you could create a complete application that would require thousands of C code lines otherwise. The standard Lua standalone interpreter can be seen as just an example of embedding Lua in a C application!
Lua has a very liberal open-source license, which enables its use even in commercial applications without much hassle. This also allows the modification of its source code to adapt it to special needs.
Small memory footprint and easily tweakable C sources make Lua a perfect candidate for porting it on embedded systems or small microcomputer systems (microcontrollers, etc.). Many parts of the standard Lua distributions can be stripped off, reducing the core Lua engine in the ~100kB range. As an example, take the eLua project, a modified distribution of Lua designed for embedded devices.
Lua, and other scripting languages, provide various benefits that are dependant on your needs.
Provide rapid iteration of development.
Allow run-time code changes, such as reloading your UI in World of Warcraft which re-loads all scripts without stopping the game engine itself or logging you out.
Provide a distinct API for your application for users to extend, without exposing critical parts of your system to the public. Such as text editors providing a macro language to allow you to integrate custom behaviour without giving you unfettered access to the internals of the editor itself.
The uses are really quite extensive and depends on the developer.
ok there is no real way to connect to soap within ios5... sadly enough.
I cant really believe that things that take 3 lines of code in php,
$client = new SoapClient("scramble.wsdl");
print($mirror = $client->sendAndGetString("hello_world"));
need 366 lines of code in objective c? And that on a device that has one of the biggest number of ria's and web apps.
Kind of disappointing -
Are there any new libraries I am not aware of?
If I talk to our web developer team they maybe switch to another service type that is more supported by IOS.
What would be a alternative then?
Thanks
The difference between dynamically typed languages such as PHP and statically typed languages such as Objective-C regarding RPC protocols is that while dynamic languages typically allows you to wrap "any" service in run-time by reflecting out their metadata (e.g. WSDL), statically typed languages normally requires a code generation step before the compilation phase.
Two popular code generators seem to be wsdl2objc and sudz-c. See also this question.
Regarding alternatives, I have good experience using both JSON and XML-RPC, as well as the more schema-oriented Thrift and Protocol Buffers (ObjC).
I've written several tutorials about using SOAP services in iOS with Wsdl2Objc: http://brismith66.blogspot.com/search/label/iPhone%20Development
For me the easiest way is to use good tool to generate all required classes. Personally I use this site:
http://easywsdl.com/
It supports quite complex web services and is very easy to use.
I recently wrote a binding for a C library using SWIG. While a good deal of it was straight forward and used only basic SWIG functionality, I ran into trouble when I needed to support one function which took a C callback as an argument, which is not supported for SWIG. I solved this by writing Python-specific code to provide a custom callback in which I called the Python 'eval' function to evaluate a supplied Callable.
While this worked nicely, it was unfortunate for me.. I had been hoping to use SWIG to take advantage of its support for tens of languages, but now I'm stuck having to figure out callbacks in every single language I wish to support. This makes my binding work magnitudes less useful, as I now have to solve the same problem many times, manually--the opposite of the point of using SWIG.
Are there any tool like SWIG that also handles C callbacks?
It's a bit rounadabout but if you recompile the C project in C++ or create a C++ extension, then you can take advantage of virtual function overloading.
Most SWIG language module have support for directors which allow a class in the target language to derive from a class in the C++ library. This way any overridden virtual function act as a callback.