Proposal: libcuberite

[drmeister]

Sounds like a good project. I guess it is totally possible to write bindings for any other language.

Thanks.

What I'm looking for is to be able to compile cuberite as a C++ library that I could dynamically load it into my system using dlopen.  From Common Lisp I could then create cuberite C++ classes and call cuberite functions to set things up. Then I would create a main loop and call a cuberite function to step the world forward one time step.   Since Clasp generates compiled native code using LLVM the main loop could include a lot of Common Lisp code to drive the game. 

Here's a demo I put together yesterday where I expose a small part of the Bullet physics engine and set up and run a little simulation.
https://github.com/drmeister/demo-bullet

I'd like to do something like that with cuberite.   It would be a great teaching tool for kids because they could load up the system and then start modifying the behavior of animals and writing code to build structures within the world.

I can deal with the bindings - that's my forte.  Clasp has a C++ template library that semi-automatically creates bindings.  It also exposes the Clang C++ compiler front end so I have access to the C++ AST from Common Lisp.  I can slurp up the cuberite C++ API and automatically create bindings.

I think "libcuberite" is what I'm looking for.   I'm thinking to take out the main function and link everything as a library.

[xoft]

I'm no longer sure this is what would help you out. Even when split off, the libcuberite will handle all of its internal transparently, without any access to them from the client code, so it will not be possible to, for example, run a single tick of a world from the external app.

[LogicParrot]

The name "libcuberite" is misleading. lib implies a dynamically loadable library, while this proposal is only about decoupling the logic from the user interface and having multiple user interfaces.

[xoft]

"lib" doesn't have to be a dynamically loadable library at all, it could be static, too (which is what we're aiming for here).

[sphinxc0re]

Why are we aiming for a static library? A dynamic library has it's pros, too. For example multiple cuberite instances could share one library and safe memory

[yangm97]

The name "libcuberite" is misleading. lib implies a dynamically loadable library, while this proposal is only about decoupling the logic from the user interface and having multiple user interfaces.

Hm, I’m kind confused here. I thought the main objective was to break cuberite in 3 pieces: a library, a daemon and an interface (cli, qt etc):

...

1. libcuberite        -> the core library with all the backend functionality
   
2. cuberite-cli       -> the command line interface
   
3. cuberited         -> the cuberite deamon
   

...

[LogicParrot]

"lib" doesn't have to be a dynamically loadable library at all

Sorry, I didn't mean dynamic libraries specifically.

libX usually implies a building block for software. For instance, libpurple is an xmpp library. Pidgin and Adium are entirely different programs that use that library, as well as other libraries. This is proper use of the term.

Unless I'm missing something, this proposal is about decoupling the logic from the user interface, allowing multiple user interfaces. This is not proper usage of the term libX. Matlab has a cli and an IDE, and it isn't called libmatlab. apt-get has a ton of wrappers and it isn't libAptGet.

drmeister's questions and yangm97's chunk question are a testimony of the confusing terminology. Anyways, it's just terminology and perhaps it is subjective. Sorry for nitpicking.

I'd like to teach my daughter to program and a Common Lisp...

Offtopic: I think functional languages are not a good first step. Try Scratch or https://www.playcodemonkey.com/

[drmeister]

I see - I wanted a libcuberite.dylib that I could load into my environment and run the cuberite world one tick at a time with full access to the cuberite internals - so that's what I read into the proposal.  No worries - if that's not what is being discussed then I can withdraw.  

Offtopic: Funny coincidence, my daughter said to me on the weekend "Don't make it Scratch - that's so boooooooring".  Also, Common Lisp is not functional like Haskell and Clojure.  It's a great multi-paradigm language that gets a lot of programming concepts like "scope" right.  Google Flights to Roomba robots are programmed in Common Lisp.

[HelenaKitty]

Hello,
This sounds like a very good idea indeed, though I would like an ETA (Estimated Time Average) on when you are planning to get started on cuberite-cli, because that is the part of the libcuberite project which interests me to most.


I do think you need to continue more on the webadmin interface though, as there is no handler for removegroup, and a few other problems.

[ShadowCone]

This sounds like a very good idea indeed, though I would like an ETA (Estimated Time Average) on when you are planning to get started on cuberite-cli, because that is the part of the libcuberite project which interests me to most.

Lmao..... Apart from ETA usually meaning estimated time of arrival, who do you think we are that we can tell you "eta one month, by then we have it done". Lol. 

But I agree, webadmin could use the work better