Interactve and dynamic plots/charts in clojure - clojure

Does clojure have any libraries for showing dynamic plots/charts, something as simple as oscillating sine wave for example?
Looked at incanter library, but it seems to only provide static plots.

Not really a plotting library, but you could use the quil interface to the Java Processing library.
If you're willing to use Clojurescript, I'd suggest looking at d3.js and the strokes library for using it from Clojurescript. However, this requires learning d3.js's quirky methodology, and will require quite a bit of thinking in terms of HTML, DOM, CSS, and Javascript even if you write most of the code in Clojure. [EDIT: I now think it's simpler to use d3.js directly from Clojurescript; strokes provides little benefit. There are also some Clojurescript chart libraries built on d3.js. I've found NVD3 useful, for example.]
There's also an all-Clojurescript C2 library, designed to implement some of the functionality of d3.js, but doesn't allow dynamic plotting, though you can add dynamic features using custom CSS. (C2 is not really growing, AFAIK, but it's actively maintained.)
Another option, which might actually be easier (or not) would be to use a Java library that does what you want. No doubt there are several, including JFreeChart. This also might require a bit of thinking Java-style, learning about Clojure-Java interop (which ranges from trivially easy to ugly, confusing, and verbose, depending on how the Java library is structured).
For whatever it's worth, there are libraries for interfacing Java with R, which has very nice plotting capabilities through it's built-in plotting, the ggplot2 library, and the lattice library. So in theory, you could use Clojure to control Java to control R, which may not be worth it. See this question for Java-to-R libraries.
You should also ask on the Incanter Google group. Maybe there are some hidden tricks, or something in development that will do what you want.
EDIT: Incanter does provide something called "dynamic plots". Not exactly what you want, I think: These are charts that have parameters attached to sliders so that you can see plot change over time. Nevertheless, the fact that Incanter can do this suggests that it might not be that difficult to create a chart that dynamically changes in response to changes in data.
ONE MORE EDIT: Since JFreeChart is what Incanter uses to draw charts, and JFreeChart is a Java library that is able to generate dynamic charts, an option is to use Java methods on the chart objects that Incanter produces, as this answer suggests.
(EDIT: A search for "clojure jfreechart" turns up a few libraries and tutorials intended to help one use JFreeChart with Clojure.)
Anndd ... one more EDIT: https://github.com/liebke/apogee
looks like it may be exactly what you wanted, jyriand. (I'm interested in related questions, and I keep noticing new potential answers to this one.)

Related

What is the clojure equivalent to google guice?

I came across google guice and could not really understand it and what it did, although there seems to be alot of hype around it. I was hoping to get a clojurian perspective of the library and why it is needed/not needed in clojure applications and if there was anything similar built into the language.
Because of Java's OO and type system, dynamically switching between different underlying implementations (for test (mocking) purposes for instance) can be difficult to manage. Libraries like Google Guice are intended to handle these dependency injections in Java more gracefully.
In Clojure and other functional languages functions can be passed around, which makes using different implementations much easier.
There's several ways this can be done in Clojure:
Using your choice of function as parameters in higher order functions.
(Re)Binding your choice of function to a var.
Encapsulating your choice of function inside closures that can then be passed around and called.
Chapter 12 of Clojure Programming has some nice examples of OO patterns like dependency injection and the alternative ways to handle these in Clojure.
Sean Devlin also has a Full Disclojure video on Dependency Injection in Clojure. His example might have been chosen better, though. Instead of using completely different function implementations in his closure, he uses a factory that returns different 'versions' of a function. The gist stays the same though.
Basically, dependency injection is a pattern that is a necessary evil in OOP, and can be solved easily (or is not even a problem) in FP.
The rough Clojure equivalents are still in development. There are two libraries currently in development (as of Oct '12): Prismatic's Graph (not yet open sourced) and Flow by Stuart Sierra.
Note that I consider Guice to be more than dependency injection. It provides a framework for application configuration / modularization. The above libraries aim to accomplish that goal.

javascript list manipulation library/framework

I'm looking for a javascript library/framework to manipulate lists. Is there anything like this already out there?
Ideally I'd like something equivalent to .NET's List. One of the main requirements is the ability to remove items from anywhere in a list. Some LINQ-like functionality would be great.
Underscore.js
It's not a substitute for a completely functional List replacement, but:
it does get you a long way,
it's well designed,
well documented (and has a very nicely "literate-programming"-style annotated source),
easy to extend,
lightweight.
It has a nice expressiveness and power to memory footprint ratio.
(Note that is was inspired by the two following libraries, FunctionalJS and Data.js.)
FunctionalJS
It shares most of Underscore.js's attributes, and is definitely more oriented towards functional programming. However:
it is less actively maintained,
it is slightly harder to use if you're not familiar with functional concepts.
Data.js
More than a purely functional programming library like FunctionalJS, Data.js also covers storage aspects, graph-like data-structures and other goodies.
(It is funny to note that Data.js now lists Underscore.js has an influence in its newer iteration, while Underscore.js already lists Data.js as its own influence.)
List.js
List.js is for manipulating HTML lists. It may not be what you want, but I thought of adding it here as well as it does its job very well and fits a nice niche in terms of briding data and UI management in one (not necessarily a good idea, but works for some cases).
Others...
Dojo (and many other JS libraries nowadays) supports some of the newer JS APIs or provides substitute implementations if they are missing, with some of them fairly functional by nature and design.
However, they don't push the concept quite as far, and these libraries are more heavyweight, so I wouldn't recommend them if that's all you want out of them.
jLinq, as mentioned by JanusTroelsen in your question's comments, looks very promising as well but I would be more concerned about the maturity of the library and its memory footprint for what it is (but the code seems very "spaced", so a compressed version might be acceptable).
May linq.js what you're looking for ? http://neue.cc/reference.htm
Also, http://microjs.com/ is a good site to find a library corresponding to a specific need :)
Also you can try manipula package that implements all of C# LINQ methods and preserves its syntax:
https://www.npmjs.com/package/manipula

A generic C++ library that provides QtConcurrent functionality?

QtConcurrent is awesome.
I'll let the Qt docs speak for themselves:
QtConcurrent includes functional programming style APIs for parallel list processing, including a MapReduce and FilterReduce implementation for shared-memory (non-distributed) systems, and classes for managing asynchronous computations in GUI applications.
For instance, you give QtConcurrent::map() an iterable sequence and a function that accepts items of the type stored in the sequence, and that function is applied to all the items in the collection. This is done in a multi-threaded manner, with a thread pool equal to the number of logical CPU's on the system.
There are plenty of other function in QtConcurrent, like filter(), filteredReduced() etc. The standard CompSci map/reduce functions and the like.
I'm totally in love with this, but I'm starting work on an OSS project that will not be using the Qt framework. It's a library, and I don't want to force others to depend on such a large framework like Qt. I'm trying to keep external dependencies to a minimum (it's the decent thing to do).
I'm looking for a generic C++ framework that provides the same/similar high-level primitives that QtConcurrent does, and that works with STL collections. AFAIK boost has nothing like this (I may be wrong though). boost::thread is very low-level compared to what I'm looking for (but if the requested lib used boost::thread for the low-level work, that would be great).
I know C# has something very similar with their Parallel Extensions so I know this isn't a Qt-only idea.
What do you suggest I use?
I've heard good things about Intel's Threaded Building Blocks, though I haven't used it
As of Oct 2009, it doesn't seem to have map-reduce specifically. But people have expressed interest and suggested they were going to come up with something:
http://software.intel.com/en-us/forums/showthread.php?t=65053
"map reduce looks like a simple combination of a filter, a sort, and a reduction but it might need some magic to get it to be efficient"
Can you use Boost? I don't think it provides quite as high-abstraction a layer as Qt, but it should be possible to make one as a reasonably thin facade on top of Boost's primitives (indeed, maybe some of the existing add-ons already provide what you require -- I have to admit I'm not familiar with them in detail, which is why I say "maybe";-).
If you find out that existing add-ons are unsuitable, your facade would be an excellent add-on to contribute to the Boost Vault (or other open-source repo) yourself, "giving back" a useful reusable open-source contribution... I hope this motivates you to do this work if needed!-)

Is there a good graph layout library callable from C++?

The (directed) graphs represent finite automata. Up until now my test program has been writing out dot files for testing. This is pretty good both for regression testing (keep the verified output files in subversion, ask it if there has been a change) and for visualisation. However, there are some problems...
Basically, I want something callable from C++ and which plans a layout for my states and transitions but leaves the drawing to me - something that will allow me to draw things however I want and draw on GUI (wxWidgets) windows.
I also want a license which will allow commercial use - I don't need that at present, and I may very well release as open source, but I don't want to limit my options ATM.
The problems with GraphViz are (1) the warnings about building from source on Windows, (2) all the unnecessary dependencies for rendering and parsing, and (3) the (presumed) lack of a documented API specifically and purely for layout.
Basically, I want to be able to specify my states (with bounding rectangle sizes) and transitions, and read out positions for the states and waypoints for each transition, then draw based on those co-ordinates myself. I haven't really figured out how annotations on transitions should be handled, but there should be some kind of provision for specifying bounding-box-sizes for those, associating them with transitions, and reading out positions.
Does anyone know of a library that can handle those requirements?
I'm not necessarily against implementing something for myself, but in this case I'd rather avoid it if possible.
Hmm, GDToolkit (or GDT) looks okay: many of the images in the tutorial look pretty nice, and it doesn't look like it's terribly complicated to use.
Edit: But checking the license, it looks like it's commercial software :-(. Whoops!
OGDF is under the GPL.
Pigale is also under the GPL.
GoVisual is commercial software, but it looks like it starts at $1800 for one developer.
I was dealing with a similar problem earlier this year. One important input parameter for a decision however is the expected number of nodes.
I decided to use the Browser as the GUI and therefore looked for nice Javascript libraries, one i came across was wireit, it is very well suited for technical layouts (and also editing with drag and drop and "on the fly" layouting). You could easily connect that to your c++ by running a small webserver in a thread (You will need some kind of eventloop/thread thingie for GUI anyways).
Well just my 2 cents.
Although the answers so far were worth an upvote, I can't really accept any of them. I've still been searching, though.
One thing I found is AGLO. The code is GPL v1, but there are papers that describe the algorithms, so it should be easy enough to re-implement from scratch if necessary.
There's also the paper by Gansner, Koutsofios, North and Vo - "A Technique for Drawing Directed Graphs" - available from here on the Graphviz site.
I've also been looking closely at the BSD-licensed (but Java) JGraph.
One way or the other, it looks like I might be re-implementing the wheel, if not actually re-inventing it.
Here is a good collection of Graph Libs with comparison and searching functionality:
http://gvsr.polytech.univ-nantes.fr/GVSR/task?action=browse#
Maybe you find a lib which fits for you.

How do you glue Lua to C++ code?

Do you use Luabind, toLua++, or some other library (if so, which one) or none at all?
For each approach, what are the pro's and con's?
I can't really agree with the 'roll your own' vote, binding basic types and static C functions to Lua is trivial, yes, but the picture changes the moment you start dealing with tables and metatables; things go trickier very quickly.
LuaBind seems to do the job, but I have a philosophical issue with it. For me it seems like if your types are already complicated the fact that Luabind is heavily templated is not going to make your code any easier to follow, as a friend of mine said "you'll need Herb Shutter to figure out the compilation messages". Plus it depends on Boost, plus compilation times get a serious hit, etc.
After trying a few bindings, Tolua++ seems the best. Tolua doesn't seem to be very much in development, where as Tolua++ seems to work fine (plus half the 'Tolua' tutorials out there are, in fact, 'Tolua++' tutorials, trust me on that:) Tolua does generate the right stuff, the source can be modified and it seems to deal with complicated cases (like templates, unions, nameless structs, etc, etc)
The biggest issue with Tolua++ seems to be the lack of proper tutorials, pre-set Visual Studio projects, or the fact that the command line is a bit tricky to follow (you path/files can't have white spaces -in Windows at least- and so on) Still, for me it is the winner.
To answer my own question in part:
Luabind: once you know how to bind methods and classes via this awkward template syntax, it's pretty straightforward and easy to add new bindings. However, luabind has a significant performance impact and shouldn't be used for realtime applications. About 5-20 times more overhead than calling C functions that manipulate the stack directly.
I don't use any library. I have used SWIG to expose a C library some time ago, but there was too much overhead, and I stop using it.
The pros are better performance and more control, but its takes more time to write.
Use raw Lua API for your bindings -- and keep them simple. Take inspiration in the API itself (AUX library) and libraries by Lua authors.
With some practice raw API is the best option -- maximum flexibility and minimum of unneeded overhead. You've got what you want and no more, the way you need it to be.
If you must bind large third-party libraries use automated generators like tolua, tolua++ (or even roll your own for the specific case). It would free you from manual work.
I would not recommend using Luabind. At the moment it's development stalled (however starting to come back to life), and if you would meet some corner case, you may be on your own. Also Luabind heavily uses template metaprogramming. This may (and may not) be unacceptable, depending on the point of view.