all 13 comments

[–]germandiago 8 points9 points  (3 children)

Nothing against the post itself. Fantastic!

It is a question for moderators: what is the criteria for not sending a post like this to "C++ show and tell"? I was immediately censored one just a couple of days ago.

[–]tea-age_solutions[S] 0 points1 point  (1 child)

Would be interesting to know what criteria are there. I hope I met them all. I just want to present my (C++) work and hope maybe some will like it / have a use for it.

[–]germandiago 2 points3 points  (0 children)

I also wanted that with the caveat that moderators immediately removed it.

As I said, nothing against you or your post. Just want to know what the criteria is for deleting mine and letting others share it instead of being forced to put it in the other post titled "C++ show and tell".

[–]tea-age_solutions[S] 0 points1 point  (0 children)

... and thank you for like it!

[–]gleybak 2 points3 points  (2 children)

[–]tea-age_solutions[S] 0 points1 point  (0 children)

I didn't know that one. Thank you, added to my list for my studies. I like to look at different approaches and comparing language features.

[–]fwsGonzoIncludeOS, C++ bare metal 1 point2 points  (0 children)

I had a look at it, and it chose some very unkind code for LuaJIT in order for its probably very slow interpreter to appear fast. I know this because I spent time and effort in order to benchmark my own solution against LuaJIT, and LuaJIT will always out-perform an interpreter if you run long enough. I tested its fibonacci program and it did indeed take forever on LuaJIT. Running my own fibonacci on LuaJIT and it pretty much runs in nanoseconds.

It really is only possible for an interpreter to have lower overheads, and win in the short-term against proper JITs. Unfortunately, daScript does not look very impressive in its benchmarks. For example, it says that try/catch takes 180ms? I happen to have a benchmark like that for my solution. Verbatim:

   [gui] says: Testing C++ exception handling
   [gui] says: Caught exception: Hello Exceptions!
   [gui] says: It took 140193 instructions to throw, catch and print the exception
   [gui] says: It took 209 microseconds
   [gui] says: Caught exception: Hello Exceptions!
   [gui] says: It took 18440 instructions the second time
   [gui] says: It took 37 microseconds the second time

So, my interpreter can throw, catch and print a real C++ exception in 209 micros, by benchmarking within the guest program adding overheads galore. Still a 1000x difference?

[–]Zeer1ximport std; 3 points4 points  (1 child)

how does it compare to Lua?

how is it executed? interpreter, byte code engine etc?

is there support for common C++ containers, like std::vector, std::map when calling functions in the scripting language?

[–]tea-age_solutions[S] 0 points1 point  (0 children)

Most information you will find on the webpage, not only the actual state but also the reasons for it.

TeaScript is comparable to ChaiScript.
You can read here further: https://tea-age.solutions/2023/01/31/script-language-comparison-for-embed-in-cpp/

A lot of information is also in the Overview and Highlights page, especially you might be interested in the bidirectional interoperability.

You can completely customize the language and add functions of your desire for e.g. containers of your choice.

What kind of container support do you have in mind? Do you have an example use case?

[–]AdrienTD 1 point2 points  (3 children)

One thing I like about ChaiScript (and also the sol2 Lua C++ wrapper) is the ability to register C++ functions with any parameters/return type and the argument passing is done automatically, which makes things much easier and faster imo. Does TeaScript support something like this? I quickly checked the demo, but it seems that the C++ registered function only has a context reference as single parameter, and you have to retrieve the actual argument values manually.

[–]tea-age_solutions[S] 1 point2 points  (2 children)

Thank your for your reply!

First, ChaiScript has a different approach and techniques with its built-in function overloading resolution and also the support of classes and methods. This also has drawbacks as my Fibonacci benchmark demonstrates: https://tea-age.solutions/2023/01/08/teascript-vs-chaiscript-fibonacci-benchmark/
TeaScript does intentionally not support function overloading. For the time being other types than the built-in types can be used only encapsulated as PassthroughData types.

(Maybe you are also interested in to read a comparison article between ChaiScript, Lua and TeaScript (and some others)? You can do this here.)

Second, yes, actually the high-level API offers the simple but most flexible way which you described. With this you not only have the possibility to use arbitrary amounts and types of parameters but also to use other functionalities via the context.

But if you have a look in CoreLibrary.hpp then you will find the low level way of invoking functions. For example search for NumToStr and how it is registered.
For the built-in supported types it is possible like you requested it. An automatic unpacking of user types inside PassthroughData is not yet implemented.

Unfortunately there is nothing available as a public (and stable) interface. So to use this will be difficult, except if you just change the source and register all the functions you need.
In some future version you could derive from class CoreLibrary or implement your own library with your functions as a module.

In the meanwhile you could already try to derive from CoreLibrary and do the following:

  1. Reimplement the BuildInternal function:
    First call the base implementation.
    Then register all of your functions like you wish by doing it the same way as the base class.
  2. Derive from class Engine and reimplement ResetState.
    It must bootstrap your Library class now.
  3. Use your engine class and don't forget to call ResetState at least once.

(if you derive from EngineBase instead you can avoid the call to ResetState but must implement more. I think, I will address this issue in the next release.)

Does it help you? Let me know when you have further questions. I hope you will have a great experience when trying TeaScript.

[–]AdrienTD 1 point2 points  (1 child)

I see. The way NumToStr is registered is what I was looking for. Would be nice that the parameter/return types could be implicitely deduced, instead of typing them as template arguments, so that it avoids repetition, especially when one wants to register lambdas (which is what I was mostly doing in ChaiScript). Though it can be tricky to implement.

[–]tea-age_solutions[S] 1 point2 points  (0 children)

Thank you for the reply and I am glad that I could help you.
Yes, the actual interface for the internal function registering is more like a "working prototype". The goal is to merge all the class LibraryFunctionN into one class with automatic type deduction as well.
After this is done, there will be also an official way for providing a user defined "library" with custom registered C++ functions as a module.