i am using contiki-os to simulate some motes which would have semantic capabilities. As the contiki-os (erbium) is written in C but our semantic libraries are written in java.
can anyone here guide me if it is possible to exploit these libraries in erbium or contiki-os. or i have to rewrite everything from scratch ?
update
just a minor update to the question. is it possible to use java code on the cooja simulator?
Cooja is indeed written in Java.
You can extend or modify Cooja if you need.
You can find out more about Cooja on the Contiki wiki as well as in numerous papres by Fredrik Österlind. Perhaps you should also take a look at Fredrik's PhD thesis "Improving Low-Power Wireless Protocols with Timing-Accurate Simulation", which is mostly about Cooja.
You might be able to use something like this:
http://www.codemesh.com/products/junction/
It appears to have a code generator that takes a java bytecode and create C code from it... but it might also need a runtime library that's platform specific.
With all that in mind, I don't think you will be successful. Most of the platforms are nearly out of space and/or flash by the time you are working with Erbuim; I doubt you'll have resources to process java code somehow.
And if you did get some success from this approach it would probably take a lot of time and effort to do so. With that time and effort you probably could have written the C code to do what you need instead.
I am curious to know if there is any kind of programming library/framework for the C language for cross-platform programming of course. I mean there are already frameworks like Wxwidgets, Boost, Qt, U++ and etc for C++ available but I have not yet found any for C .
Updated Info:
We are trying to build an underlying Framework/library to be used in our project. We are going to eliminate the dotnet and instead provide a counterpart for those libraries which is fast and less demanding.
We will be working on a server/client based project, and thus the underlying services must be fast and also portable. GUI is not our priority now, but libraries providing threading capabilities is of importance to us.
And for the ANSI part, I think we are fine with that at the moment unless something changes that in the future.
if you write plain ANSI C, it should work on every POSIX system.
The most successful example of cross platform C library is standard C library itself (IMHO).
If you're looking for GUI toolkit GTK is the answer,
if you're looking for terminal UI, ncurses is pretty portable.
If you're looking for general use libraries, as long as they're written in ANSI C, should work almost everywhere, as long as it doesn't use system level APIs.
Can you just tell us, what kind of library/framework you are looking for ?
GTK+ is long established and actively maintained cross-platform C-only (or primarily) toolkit. You'll find not only on-line documentation but also books written about it. It is the framework backing up the GNOME project.
GTK+ is meant to build applications with UI, first of all. However, even if you don't need UI you'll find that some GTK+ components, namely GLib, provide general multiplatform support comparable with Qt. Actually, I needed a framework without UI at first and chose GLib over APR because I was able to find documentation and tutorials easier.
GTK+ was initially developed on UN*X an X-Windows which remains the platform where you can get it running the most easily. I wouldn't say that it is more difficult on Windows; it is just that you have more compiling environment options. I started with prepared GTK+ packages and MinGW but ended up integrating GTK+ with MSVC.
GTK+ exists for a long time and some people may find it old-school. On the other hand, it shows that it has proven to be stable and useful. There are also bindings for C++ and C#.
As with every big framework, the more you need from it the longer you will have to learn. But the other way round it works too; the more you learn the more you'll be able to do with it. Consistent coding style helps getting used to it.
--- Ferda
I have integrated Lua with my ObjC code (iphone game). The setup was pretty easy, but now, I have a little problem with the bridging. I have googled for results, etc... and it seems there isn't anything that could work without modifications. I mean, I have checked luaobjc bridge (it seems pretty old and dicontinued), I heard about LuaCocoa but it seems not to work on iphone, and wax is too thick.
My needs are pretty spare, I just need to be able to call objc methods from lua and don't mind having to do extra work to make it work (I don't need a totally authomatic bridging system).
So, I have decided to build a little bridge myself based on this page http://anti-alias.me/?p=36. It has key information about how to accomplish what I need, but the tutorial is not completed and I have some doubts about how to deal with method overloading when called from lua, etc...
Do anybody know if there exist any working bridge between objc and lua on the iphone or if it could be so hard to complete the bridge the above site offers?
Any information will be welcomed.
Don't reinvent the wheel!
First, you are correct that luaobjc and some other variants are outdated. A good overview can be found on the LuaCocoa page. LuaCocoa is fine but apparently doesn't support iPhone development, so the only other choice is Wax. Both LuaCocoa and Wax are runtime bridges, which means that you can (in theory) access every Objective-C class and method in Lua at the expense of runtime performance.
For games and from my experience the runtime performance overhead is so significant that it doesn't warrant the use of any runtime binding library. From a perspective of why one would use a scripting language, both libraries defy the purpose of favoring a scripting language over a lower-level language: they don't provide a DSL solution - which means you're still going to write what is essentially Objective-C code but with a slightly different syntax, no runtime debugging support, and no code editing support in Xcode. In other words: runtime Lua binding is a questionable solution at best, and has lots of cons going against it. Runtime Lua bindings are particularly unsuited for fast-paced action games aiming at a constantly high framerate.
What you want is a static binding. Static bindings at a minimum require you to declare what kind of methods will be available in Lua code. Some binding libraries scan your header files, others require you to provide a special declaration file similar to a header file. Most binding libraries can use both approaches. The benefit is optimal runtime performance, and being able to actually design what classes, methods and variables Lua scripts have access to.
There are but 3 candidates to bind Lua code to an iPhone app. To be fair, there are a lot more but most have one or more crucial flaws or are simply not stable or for special purposes only, or simply don't work for iPhone apps. The candidates are:
tolua and tolua++
luabind
SWIG
Big disadvantage shared by all Lua static binding libraries: none of them can bind directly to Objective-C code. All require to have an additional C or C++ layer available that ultimately interfaces with your Objective-C code. This has to do with how Objective-C works as a language and how small a role it has played (so far) when it comes to embedding Lua in Objective-C apps.
I recently evaluated all three binding libraries and came to enjoy SWIG. It is very well documented but has a bit of a learning curve. But I believe that learning curve is warranted because SWIG can be used to combine nearly any programming and scripting language, it can be advantageous to know how to use SWIG for future projects. Plus, once you understand their definition file implementation it turns out to be very easy (especially when compared to luabind) and considerably more flexible than tolua.
OK, bit late to the party but in case others come late also to this post here's another approach to add to the choices available: hand-code your LUA APIs.
I did a lecture on this topic where I live coded some basic LUA bindings in an hour. Its not hard. From the lecture I made a set of video tutorials that shows how to get started.
The approach of using a bindings generation tool like SWIG is a good one if you already have exactly the APIs that you need to call written in Objective-C and it makes sense to bring all those same API's over into LUA.
The pros of the hand-coding approach:
your project just compiles with one standard Xcode target
your project is all C & Obj-C
the LUA is just data shipped along with your images
no fiddling with "do I check in generated code" to Git
you create LUA functions for just the things you want
you can easily have hosted scripts that live inside an object
the API is under your control and is well known
dont expose engine APIs to level building team/tools
The last point is just that if you have detail functions that only make sense at the engine level and you don't want to see those when coding the game play you'll need to tell SWIG not to bind those.
Steffens answer is perfect and this approach is just another option, that may suit some folks better depending on the project.
I usually write web apps in PHP, Ruby or Perl. I am starting the study of Scheme and I want to try some web project with this language. But I can't find what is the best environment for this.
I am looking for the following features:
A simple way of get the request parameters (something like: get-get #key, get-post #key, get-cookie #key).
Mysql access.
HTML Form generators, processing, validators, etc.
Helpers for filter user input data (something like htmlentities, escape variables for put in queries, etc).
FLOSS.
And GNU/Linux friendly.
So, thanks in advance to all replies.
Racket has everything that you need. See the Racket web server tutorial and then the documentation. The web server has been around for a while, and it has a lot of features. Probably the only thing that is not included is a mysql interface, but that exists as a package on PLaneT (Racket package distribution tool).
UPDATE: Racket now comes with DB support, works with several DBs including mysql.
You may want to have a look at Clojure:
Clojure is a dynamic programming language that targets the Java Virtual Machine. [...] Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.
Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system.
Interop with Java is straightforward in Clojure, so you can re-use any existing Java libraries as you need. I'm sure there are plenty that are useful for web development.
clojure-contrib has an SQL API, and there is ClojureQL as well, which should cover your DB access needs.
There is a web framework for Clojure called Compojure under development. There may be others, too.
Clojure's source is available on github under the EPL. Getting it running on Linux is easy; I just clone the git repos and run ant.
You can do web development with guile scheme. Its standard library includes the (sxml simple) module that is very useful for html generation, manipulation, and parsing. The guile-www library adds support for http, cgi, etc. The guile-dbi library provides access to MySQL and other databases. With these building blocks, you can implement everything from simple cgi scripts to web applications with their own HTTP server.
Try Weblocks, a Common Lisp web framework:
http://weblocks.viridian-project.de/
I've written a pretty extensive tutorial/ebook on the topic: http://lispwebtales.ppenev.com/
Quick summary:
It uses Common Lisp
It uses the Restas framework
It has examples for pretty much most of basic web development, including DB access, authentication, HTML generation and templating.
Since the Restas documentation is pretty much out of date, my tutorial is the closest thing to up to date docs.
Shows a few of the more advanced features, like policies, which allow you to write pluggable interfaces, for instance you can write a data store layer, and write back-ends for different storage mechanisms with relative ease, the module system which allows you to write reusable components, like auth frameworks and things like that.
It covers things like installing lisp, setting up the ASDF build system and the quicklisp package manager etc.
It's free online, and as soon as I finish it it will be free on leanpub as well. The source is on https://github.com/pvlpenev/lispwebtales under a CC license, the source code is MIT. Not all of it is published yet, and I'm in the process of revising.
This may be what you are looking for.
http://www.plt-scheme.org/
http://docs.plt-scheme.org/web-server/index.html
http://common-lisp.net/project/cl-weblocks/
If you are interested in Common Lisp to be exact and do not want to go the weblocks route I would recommend the following setup:
Use SBCL on Linux but with multiple thread support
Use Hunchentoot as a web server which will provide you with all the server processing required including sessions and cookies
Use ClSql to communicate with MySql it has ample documentation and is very stable.
For the HTMl generation you can use Dr Edi Weitz Cl-WHO (very well documented).
Note all the above are under GPL or similar license (one that works more for lisp programs)
Gambit Scheme has its own solution to web apps as well. It uses the Spork framework, based o the Black Hole module system (both by Per Eckerdal).
Andrew Whaley has an initial tutorial on how to get Gambit, Black Hole and Spork running a web app under Apache using mod_proxy. You might want to take a look at that.
On a (possibly) related note, Gambit will also compile your stuff to C and then to an executable, if you feel so inclined.
Paul Graham (and friends) made a lisp dialect specifically for writing basic web applications. It's called Arc, and you can get it at arclanguage.org.
It's probably not suited for really big complex websites and I'm not sure what state it's database support is at but Paul Graham knows how to write web applications in lisp, so Arc will make the HTTP/HTML part easy for you while you spend most of your brain cycles learning the lisp way.
Weblocks is nice tool for building web apps in Common Lisp, but a bit too heavy-weight for me.
We use the following stack:
OpenMCL (open source Lisp, very nice)
Portable Allegroserve (web server, HTML generator)
Our own Rails-like tools for doing Ajaxy stuff (update: this has now been open sourced as WuWei)
A variety of CL libraries like cl-json, cl-smtp, md5
I use my own, customized version of Scheme, derived from MzScheme. It has a new, simple web-application framework, a built-in web-server (not the one that comes with MzScheme) and ODBC libraries. (http://spark-scheme.wikispot.org/Web_applications). The documentation may not be exhaustive, as this is more of a personal tool. But there are lots of sample code in the code repository.
Clojure is a Lisp dialect which may interest you. At this point there's a pretty decent web development stack. I can recommend a few things:
The leiningen dependency manager which makes is really easy to install and manage libraries that you're using. Pretty nice set of plugins for it too. There's even a plugin for Clojurescript, which is a language based on Clojure that compiles to Javascript.
The ring HTTP server abstraction. Its used in most actual web frameworks. Its a pretty good idea to learn that first before jumping into an actual framework.
hiccup is a HTML dsl/templating language written in Clojure. Its very expressive! Reminds me a bit of Jade, in a sense.
composure would have to be the most popular web framework for Clojure. Its essentially a routing library like express.js.
Let's see what can be done with Common Lisp.
The state of the Common Lisp ecosystem (2015) and the Awesome Common Lisp list show us a couple of modern frameworks (Caveman, Lucerne, all built on the new Clack web application server, an interface for Hunchentoot and other servers). Let's discuss with our own findings.
update 2019: there's a new tutorial on the Common Lisp Cookbook: https://lispcookbook.github.io/cl-cookbook/web.html It covers routing, template engines, building self-contained binaries, deployment, etc.
update: a bit later, I found out Snooze, by the creator of Sly or Emacs' Yasnippet, and had a much better impression than say Caveman. Declaring endpoints is just like declaring functions, so some things that were tedious in Caveman are obvious in Snooze, like accessing the url parameters. I don't have much experience with it but I recommend checking it out.
update june 2018: also don't miss the ongoing rewrite of Weblocks, it's going to be huge ! :D http://40ants.com/weblocks/quickstart.html Weblocks allows to build dynamic webapps, without a line of Javascript, without separating the back and front. It is components-based, like React but server-side. It's very alpha as of writing (june 2018), but in progress, and it's working, I have a couple simple web apps working.
A simple way of get the request parameters (something like: get-get #key, get-post #key, get-cookie #key).
I found easier the Lucerne way, it iss as simple as a with-params macro (real world example):
#route app (:post "/tweet")
(defview tweet ()
(if (lucerne-auth:logged-in-p)
(let ((user (current-user)))
(with-params (tweet)
(utweet.models:tweet user tweet))
(redirect "/"))
(render-template (+index+)
:error "You are not logged in.")))
Caveman's way has been less clear to me.
Mysql access
Caveman advertises database integration (with Fukamachi's Datafly and sxql).
You can just use clsql or the Mito ORM: https://lispcookbook.github.io/cl-cookbook/databases.html
HTML Form generators, processing, validators, etc.
I don't know if there are form generators out there. edit: there are: cl-forms and formlets, or again 1forms, working with Caveman2.
Caveman does not have one (issue raised in 2011).
Helpers for filter user input data (something like htmlentities, escape variables for put in queries, etc).
Ratify is an input validation library, not integrated into a framework though.
FLOSS and GNU/Linux friendly: ✓
Other web stuff
Speaking about web, there are other nice libraries in CL land:
web servers: Woo is a fast HTTP server, faster than Nodejs (beware of charts…), wookie is an async http server,
Dexador is an HTTP client
Plump, lquery and CLSS make it easy to parse html and query the DOM.
cl-bootstrap offers twitter-bootstrap shortcuts for the cl-who templating engine (which kind of replaces Jade/Pug, even though we have usual templates too).
Ajax in Lisp
(remember, with Weblocks, see above, we might not need those)
With ParenScript, we can write JavaScript in Common Lisp, without living our usual workflow, and we can thus use the fetch web API to write Ajax calls.
Clojure would be perfect for this. With some very short, clean code, you can implement some very complex applications, such as blogs or forums.
You might want to consider the awful web framework for Chicken Scheme.
Natively supports PostgreSQL and SQLite
Built-in easy support for sessions
Shortcuts for some webdev idioms, like the (ajax) procedure
Your app can be easily compiled to a static executable (via csc -static) for easier deployment
The collection of all chicken libraries (eggs) isn't as versatile as in some other programming languages, but isn't awful either
Is there a general procedure for programming extensibility capability into your code?
I am wondering what the general procedure is for adding extension-type capability to a system you are writing so that functionality can be extended through some kind of plugin API rather than having to modify the core code of a system.
Do such things tend to be dependent on the language the system was written in, or is there a general method for allowing for this?
I've used event-based APIs for plugins in the past. You can insert hooks for plugins by dispatching events and providing access to the application state.
For example, if you were writing a blogging application, you might want to raise an event just before a new post is saved to the database, and provide the post HTML to the plugin to alter as needed.
This is generally something that you'll have to expose yourself, so yes, it will be dependent on the language your system is written in (though often it's possible to write wrappers for other languages as well).
If, for example, you had a program written in C, for Windows, plugins would be written for your program as DLLs. At runtime, you would manually load these DLLs, and expose some interface to them. For example, the DLLs might expose a gimme_the_interface() function which could accept a structure filled with function pointers. These function pointers would allow the DLL to make calls, register callbacks, etc.
If you were in C++, you would use the DLL system, except you would probably pass an object pointer instead of a struct, and the object would implement an interface which provided functionality (accomplishing the same thing as the struct, but less ugly). For Java, you would load class files on-demand instead of DLLs, but the basic idea would be the same.
In all cases, you'll need to define a standard interface between your code and the plugins, so that you can initialize the plugins, and so the plugins can interact with you.
P.S. If you'd like to see a good example of a C++ plugin system, check out the foobar2000 SDK. I haven't used it in quite a while, but it used to be really well done. I assume it still is.
I'm tempted to point you to the Design Patterns book for this generic question :p
Seriously, I think the answer is no. You can't write extensible code by default, it will be both hard to write/extend and awfully inefficient (Mozilla started with the idea of being very extensible, used XPCOM everywhere, and now they realized it was a mistake and started to remove it where it doesn't make sense).
what makes sense to do is to identify the pieces of your system that can be meaningfully extended and support a proper API for these cases (e.g. language support plug-ins in an editor). You'd use the relevant patterns, but the specific implementation depends on your platform/language choice.
IMO, it also helps to use a dynamic language - makes it possible to tweak the core code at run time (when absolutely necessary). I appreciated that Mozilla's extensibility works that way when writing Firefox extensions.
I think there are two aspects to your question:
The design of the system to be extendable (the design patterns, inversion of control and other architectural aspects) (http://www.martinfowler.com/articles/injection.html). And, at least to me, yes these patterns/techniques are platform/language independent and can be seen as a "general procedure".
Now, their implementation is language and platform dependend (for example in C/C++ you have the dynamic library stuff, etc.)
Several 'frameworks' have been developed to give you a programming environment that provides you pluggability/extensibility but as some other people mention, don't get too crazy making everything pluggable.
In the Java world a good specification to look is OSGi (http://en.wikipedia.org/wiki/OSGi) with several implementations the best one IMHO being Equinox (http://www.eclipse.org/equinox/)
Find out what minimum requrements you want to put on a plugin writer. Then make one or more Interfaces that the writer must implement for your code to know when and where to execute the code.
Make an API the writer can use to access some of the functionality in your code.
You could also make a base class the writer must inherit. This will make wiring up the API easier. Then use some kind of reflection to scan a directory, and load the classes you find that matches your requirements.
Some people also make a scripting language for their system, or implements an interpreter for a subset of an existing language. This is also a possible route to go.
Bottom line is: When you get the code to load, only your imagination should be able to stop you.
Good luck.
If you are using a compiled language such as C or C++, it may be a good idea to look at plugin support via scripting languages. Both Python and Lua are excellent languages that are used to script a large number of applications (Civ4 and blender use Python, Supreme Commander uses Lua, etc).
If you are using C++, check out the boost python library. Otherwise, python ships with headers that can be used in C, and does a fairly good job documenting the C/python API. The documentation seemed less complete for Lua, but I may not have been looking hard enough. Either way, you can offer a fairly solid scripting platform without a terrible amount of work. It still isn't trivial, but it provides you with a very good base to work from.