This may be a totally noob question, but I've been experimenting with openGL in clojure via LWJGL, and while there are plenty of resources for learning both graphics programming and LWJGL, I've found it frustrating to port them to clojure. All of the different static methods representing openGL calls are associated with different java classes (ie. GL11, GL15, etc.), which presents no real problem in java as they can all be imported via something like "import static org.lwjgl.opengl.GL11.*". So I was wondering if there's a way to do the same in clojure (like the way "use" does for clojure namespaces)? And if not, is there an easier way to figure out which class a given method is associated with than stopping to search through the api for each one?
The functionality you describe is not included in clojure.core. It was included in the, now deprecated, clojure-contrib project, but including that as a dependency to your project may cause unintended dependency conflicts.
The code for the import-static macro is located in the old clojure-contrib github repository.
https://github.com/richhickey/clojure-contrib/blob/master/src/main/clojure/clojure/contrib/import_static.clj
You should be able to include the single macro in your project without issue.
Related
This is kind of a beginner question, so please let me know if this is appropriate for this website and if not, where else I should be asking this.
I've just gotten into the basics of C++ (pretty much what's being taught in this video from FreeCodeCamp: https://www.youtube.com/watch?v=vLnPwxZdW4Y). Obviously, not everything there is to know is discussed in this tutorial and I've been running into a couple of things in other demonstration vids that I don't quite get yet.
For example, this quick demonstration of how Tetris can be coded: https://www.youtube.com/watch?v=zH_omFPqMO4&t=0m25s) you can see him use the command 'RenderWindow', which apparently creates a new window the size of his choice (320*480 pixels in this case). This doesn't seem to be a standard function in C++, so I assume he somehow imported it. How can I do this myself? Does it have to with the file inclusions written at the top of the file (#include <SFML/Graphics.hpp>)? If so, how can I learn more about such files, where can I find them (is it anything like the Python Package Index, or interfaces in Java) and can I create them myself? Any general explanatory words on this?
Thanks in advance.
This doesn't seem to be a standard function in C++
That is correct. There are no functions for graphics nor window handling in C++.
so I assume he somehow imported it. How can I do this myself?
Usually, you would pick a library of your choice (there are many), or do it yourself by using whatever API your operating system provides.
Does it have to with the file inclusions written at the top of the file (#include <SFML/Graphics.hpp>)?
Yes, SFML is one of those libraries.
If so, how can I learn more about such files
You would go to the library's homepage and read the documentation.
where can I find them
Try searching the web for lists of libraries, articles, projects, etc.
is it anything like the Python Package Index
No, there is no standard one for C++. There are several package managers, build systems, etc. Popular libraries are in most of them and support one or more build systems.
Something is puzzling me after reading the this great answer to a related question:
There are two possibilities to share a function that I wrote in Clojure with Java developers
The first one is providing it in a JAR file so that they can call it as if I had written it in Java. Sounds great for Clojure advocacy.
The second one, the purportedly better way, requires those Java developers to use things like clojure.lang.IFn or clojure.lang.RT and invoking functions by passing their names as strings (!) instead of just calling them.
Why is the second approach "the better one"?
You are sorta setting up a false dichotomy here. Every approach involves creating a jar file: that is just how JVM programs are distributed. But there are 3 different ways for Java code to invoke Clojure code contained in a jar:
Use methods in clojure.lang.RT to initialize the runtime, load files, and then look up vars. This is the old, deprecated approach.
Use methods in clojure.java.api.Clojure to look up functions and invoke them. This is the newer version of (1), and hides some of the messy stuff you could accidentally get wrong.
Use gen-class in the Clojure library to define a more Java-friendly interface to the Clojure functions.
You can still do (3) - there's nothing wrong with it exactly. But gen-class is a pretty clunky tool, and except for the simplest examples like exposing a number of static methods, it's just not a lot of fun, and it's not easy to provide an API that "feels" like a Java API using Clojure.
But you know what's great at providing an API that feels like Java? Java! So what I recommend if you want to make a Clojure library easy to use in Java is to include some Java code in your Clojure library. That Java code, written by you, bridges the language gap. It accesses your Clojure code by mechanism (2) above, and presents a Java-friendly facade so the outside world doesn't have to know there's Clojure underneath.
amalloy/thrift-gen is an example of a library I wrote years ago following this approach. It would not be at all easy to write this in pure Clojure, just because traditional Java idioms are very foreign to Clojure, and it doesn't support them all very well. By writing my own Java shim instead, Java clients get a very comfortable interface to work with, and I can just write Clojure that feels like Clojure instead of a bunch of gen-class nonsense.
I would like to add scripting capabilities to my C++ game engine.
I have Engine.exe, Physics.dll, Audio.dll and I'm adding Scripting.dll which is a high-level Racket wrapper.
Engine.exe loads Physics.dll and sets up physics world, loads Audio.dll and sets up audio world. It is supposed to load Scripting.dll, to set up bindings to Physics.dll, Audio.dll and to load game scripts.
AFAIK there are two possible ways to embed Racket into a C++ program:
As Extension
As Foreign Interface
Using Foreign Interface seems bizarre due to necessity to load Physics.dll, Audio.dll two times: first from Engine.exe and then from the game script.
Writing Extensions looks more appealing, because it allows doing script bindings on C++ side. On the other hand you have to build your extension with raco ctool, link it with mzdyn object file — which looks awkward as well: why not make mzdyn a static library?
I would like to implement a single method, e.g. setupScriptBindings(), both in Physics.dll and in Audio.dll, and to call it from Engine.exe at the startup.
Is there a straightforward way to do it?
Having used both the extension and FFI methods of connecting Racket to C code, I have to say the FFI approach is much nicer. The bindings in Racket to the C functions are well specified and robust and dealing with C types in Racket is very nice. The only drawback to using the FFI approach is that, AFAIK, your Racket program must be the driver application.
With the embedding approach your C/C++ executable is the driver, but declaring the interface with the Racket code is much more manual and error prone. Not to mention that you have to either figure out raco ctool and replicate it or have racket's build system take over yours. For our purposes we wound up extracting the Racket sources and building it ourselves. I don't really recommend that approach.
Ultimately for my purposes having my application be a Racket application with a foreign .DLL/.so file that it loaded for C functions worked best, but it sounds like you may be stuck with the embedding approach.
I'm reading this page in my effort to determine if Clojurescript is appropriate for my use case.
I'm interested in using Clojurescript to create the Javascript code that will run in Qt 5 where JS is a native language that can access C++ functions exposed in Qt to the JS layer.
These functions will have names that can be called from Javascript within Qt, but of course they will not exist outside the Qt project, thus creating Javascript code via Clojurescript requires that the Clojurescript can call these functions even though they are outside the scope of the Clojurescript environment.
Does the "extern" method allow for Clojurescript to do this, while maintaining both successful compilation as well as no "munging" of those function names so they can operate in my Qt context fine?
Yes. If you do any optimizations but advanced, externs are not necessary.
If you plan on using the advanced mode, you will need to specify the externs, either manually, using a plugin like lein-externs, or a combination of both.
Another cool thing to do would be generating a full externs from the API docs and publishing them for other people to benefit too. Shouldn't be too hard.
I currently have two separate programs: (1) a GTK GUI; (2) a Glut application with openGL 3D graphics. However, I'd like to have the openGL part as some widget embedded in the GUI I have.
I have noticed GtkGlExt is exactly what I need, but unfortunately there are no OCaml bindings mentioned on its web pages.
My questions are:
(1) Do you know if there are any such bindings lost somewhere in cyberspace? (I have found a similar discussion from 2008 so I would hope after 3 years something would have happened.)
(2) If there aren't any bindings, how difficult would it be to produce these bindings and where would it be a good place to start? How much of the original C libraries would I have to undestand? (I haven't done any C calls from OCaml so far.)
(3) Alternatively, do you know of any other out-of-the-box package I could use? (I have attempted to install gtkglarea on OSX but I had errors which I couldn't solve and gave up. I've also tried to install lablgtk2-2.14.0+dfsg but got the errors described here.)
The standard solution is to use the LablGTK's OpenGL support. I know of no bindings to other solutions such as gtkglext. If you want to write your own bindings, in general it isn't overly difficult, does take some work and thought. You'll at least need to understand enough of the underlying C library to safely bridge with OCaml, which varies greatly with the library's interface. Since GtkGLExt is Glib-based, so you'll have the blessing and curse of being able to build on existing experience in the community with binding GLib/GTK libraries, and needing to understand enough of how Lablgtk2 works to make your bindings integrate with it. This is possible, but not exactly trivial and I don't recall seeing any good documentation on binding new GTK libraries to help you get started.
Your error in the other question looks like you're trying to hand-compile - have you tried building the GODI package for lablgtk with OpenGL enabled? It may have patches and/or build options to make it work. Alternatively, does MacPorts, which it looks like you're using from the /opt/local path, have OCaml and lablgtk packages?
Another option: There's another option I commonly use when I need access to facilities from an unbound library. Rather than writing bindings for the library, I'll write the logic needing that library in C and expose a minimal interface back to my OCaml code. In the GtkGLExt case, it's probably just a matter of creating initialization, teardown, and start/stop context calls that do the underlying work with the C API and return the OpenGL context or whatever is necessary. You'll still need to do some work to figure out how to get the right GTK object from the OCaml object, and how to pass back whatever is needed for LablGL to work, but it's typically easier than creating real bindings.