Lobster without the engine

[davidbruce]

Is it possible to build lobster without the engine? In the docs here:http://aardappel.github.io/lobster/implementation.html#adding-your-code-to-lobster

It explains removing an engine folder, but that no longer appears to be accurate.

[aardappel]

I must admit I've never tried. It is certainly on my list to make this a simple build option one day, but its a bit of work with this many platforms.

What platform are you building on?

Why do you want to remove the engine? To have a smaller binary? To not rely on OpenGL headers and such? To add your own? Since unless you invoke gl_window Lobster is already quite usable as a console-only language as-is.

[davidbruce]

What platform are you building on?

I am building on Linux.

Why do you want to remove the engine? To have a smaller binary?

• To use lobster as a general purpose programming language and not a game engine.
• Have a smaller binary
• Shorten build times when compiling to C++.

To not rely on OpenGL headers and such? To add your own?

I would be interested in experimenting with my own or using it with Raylib or Godot.

Also is there way to do any kind of FFI inside of lobster without escaping to C++? Currently, if I were to create bindings for GTK with lobster someone would need my C++ code and recompile lobster to utilize my bindings. This would make if very difficult for a package manager to be created in the future that supports native wrappers. If native wrappers became heavily used you would essentially have to build a custom lobster runtime per-project or risk a very bloated lobster runtime.

Ultimately this is mostly out of curiosity as I have no real projects using Lobster at the moment. I keep coming back and playing around with it though.

[aardappel]

Hmm, yes that is currently going to require quite some detangling. I could give it a a go, to see how hard it is :)

For bindings, my plan was allow .so's with bindings to be loaded, so the main exe doesn't have to be specialized. Bindings declared in Lobster itself would be another option, though typically with all bindings I've created so far I have never exposed C/C++ APIs 1:1, i.e. I try to find a friendly binding that fits the language. If you call directly into C, you'll end up with a very low level API that will need some inefficient wrapping (which I guess is what e.g. Python does).

I keep coming back and playing around with it though.

That's cool :) Anything that is particularly cool or not so cool about it, beside the above issues?

[davidbruce]

Hmm, yes that is currently going to require quite some detangling. I could give it a a go, to see how hard it is :)

I wholeheartedly think it would be worth it. :)

For bindings, my plan was allow .so's with bindings to be loaded, so the main exe doesn't have to be specialized.

I'm interested to hear more about this plan.

That's cool :) Anything that is particularly cool or not so cool about it, beside the above issues?

I think you really hit the nail on the head for syntax and ease of use. I am not particularly sold on the use of _ for namespaces though since I like to use them in identifiers.

[aardappel]

Ok, will give it a try.. on Linux first, since that's what you're using.

.so Loading: if you look at the code, adding an engine or any set of native functions is already highly modular: It requires a single function that add the new native functions. That could totally sit in a .so. Then in the Lobster source you'd have a directive to load that .so.

_ for namespaces was really because it was the de-facto standard already. And it somehow feel lighter to read than :: or whatever. The idea is that wether a _ is due to identifier explicitly being named like that or added as part of a namespace should really be the same thing.

[aardappel]

That was pretty simple actually, mostly just CMake changes, and some minor #ifdeffing elsewhere. The code was mostly already set up to be separate, I had just never tried it.

To use it, turn the CMake LOBSTER_ENGINE off, and it should build and run on Linux. I made sure it passes all the unit tests fine.

Let me know how that works for you!

Details: https://github.com/aardappel/lobster/commit/04458b346215050d3844a34c36393eab80280b7a

[davidbruce]

This worked for making a stand alone lobster, but when I attempted to make a compiled_lobster with cpp and -DLOBSTER_ENGINE=OFF I received the following errors:

/usr/bin/ld: CMakeFiles/compiled_lobster.dir/compiled_lobster/src/compiled_lobster.cpp.o (symbol from plugin): in function `main':
(.text+0x0): multiple definition of `main'; CMakeFiles/compiled_lobster.dir/src/main.cpp.o (symbol from plugin):(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/compiled_lobster.dir/build.make:339: /home/davidbruce/Git/tools/lobster/bin/compiled_lobster] Error 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/compiled_lobster.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

[aardappel]

oops, didn't test it with that, will try tomorrow.

[davidbruce]

Besides just omitting the main.cpp, it looks like there are changes in tocpp that need to get changed. https://github.com/aardappel/lobster/blob/04458b346215050d3844a34c36393eab80280b7a/dev/src/tocpp.cpp#L213

https://github.com/aardappel/lobster/blob/04458b346215050d3844a34c36393eab80280b7a/dev/src/tocpp.cpp#L48

Should the generated cpp file be using the lobster namespace as well?

[aardappel]

Yup, what you found was exactly the problem. Refactored that code a bit: https://github.com/aardappel/lobster/commit/bcb7b52848651395902549c0d0a1bbb589e3bb98

Tested that it works on the unit test compiled to C++.

It has the funny restriction that to compile a console only Lobster program in C++ mode, the binary generating that C++ must also be a console only version, which should not be necessary, but that seems like an acceptable limitation for the moment.

[davidbruce]

Yeah I noticed the same console-only generating issue with the fix I did for myself. I can live with it for now, but I might take a stab fixing this behaviour later if you want to leave it for me.

In the meantime though, I'm probably going to start looking at getting some form of sockets working with lobster unless you already have something. Ideally I'd like make this an external shared library.

We could probably close this issue though, unless you'd like to keep it open until Windows and OSX have this implemented.

[aardappel]

Yes, I'd love some help :)

Doing this right may involve some other fixes, because the console build changes the built-in functions available, and these functions are referred to by index in the bytecode and generated C++. Now it happens to be such that these are assigned the same indices for these 2 kinds of builds, but it will be a bit fragile if people start adding their own functions. These functions are necessary both to compile the code and run it, so you can't compile code needing the engine using a console-only compiler because it doesn't know about these functions. Not sure what the cleanest way to decouple this is.

No, no plans for sockets. I did have an idea to add http://enet.bespin.org/ at some point, which would be good for creating multiplayer games.. it probably also has portable socket functions.

Yes, we can close this one, I don't think there is any hurry porting this functionality to other platforms yet as the value of console-only is lower there. It's also a bit more of a pain to set up with the VS/Xcode based projects, though these should be able to build from CMake as well.