Hello!

Thanks for the amazing library.

Is there a way to add some custom attributes to function declarations in scripts?

e.g.

[[my custom attribute]]
void MyFunction()
{
}

Hi!

Thanks for the compliments. I'm happy you like my work.

Yes, metadata is supported by the CScriptBuilder add-on.

https://angelcode.com/angelscript/sdk/docs/manual/doc_addon_build.html#doc_addon_build_metadata

Regards,
Andreas

Hey again,

I've managed to replace module/source management to CScriptBuilder.
Since for the moment I use things from C-Lib, I had to extend it with CScriptBuilder support and also had to tweak it a bit to hide the std::string exposing methods.
For the module source reloading on file changes - is it just enough to StartNewModule(…) without Discard-ing old one first?
(In my previous manual code I was calling module->Discard and recreating everything as needed)

Anyways, it runs great with CScriptBuilder now.
Having attributes, includes and pragmas is nice - thank you!

Best,
Val

Yes, StartNewModule will automatically discard the old. Actually the asIScriptEngine::GetModule(name, asGM_ALWAYS_CREATE) called by StartNewModule is what is doing the discard.

Now, if you are referring to hot-reloading where the script is recompiled but the current runtime state is maintained you'll want to read up on the following topic: https://angelcode.com/angelscript/sdk/docs/manual/doc_adv_dynamic_build.html#doc_adv_dynamic_build_hot

I made it somewhat straightforward as I didn't need to ‘save’ the state between the script changes.

Reloading source and rebuilding the module works well. I extract some functions of interest (now marked with metadata as ‘runnable by ui’) and put them into a list for user execution.

But ‘hot-reloading’ is probably something I want to try for other projects later, thank you.

As for the other topic I'm also looking into options to make a debugger. Probably worth starting a new thread 🙂

Here's some information that may help for your debugger: https://angelcode.com/angelscript/sdk/docs/manual/doc_addon_debugger.html

You may also want to take a look at some of third party debuggers: https://angelcode.com/angelscript/resources.html

Hey Andreas,

Is it too late or too big a breaking change to update base CScriptBuilder a bit?
For some reason there are 2 little things in it.

The PRAGMACALLBACK_t is using a std::string and CScriptBuilder & (most of other code including a INCLUDECALLBACK_t right above uses const char * and CScriptBuilder *, so it's at least non-uniform.

Then there is a std::string GetSectionName(…) that is not a const char * again, when most of engine usually returns those (in fact engine header is clean of std::string for those who only use custom strings).

Thanks!

Too late?

I think I can still manage to get those changes done to make it more uniform. I've only been working on angelscript for the last 21 years, so a little bit more would surely not be an issue. I have no plans to stop working on angelscript any time soon. 🙂

Thanks for bringing this to my attention. I will review the code and do updates as necessary.

In general, in the core library I avoid relying on STL, any third party library, or even features from recent C++ standards to maintain maximum cross-platform compatibility. But on the add-ons I don't put that restriction on the code, and try to use what is more convenient.

Heh, I didn't mean that by ‘too late', just the implication of a little breaking changes requiring people to update a few lines in their code. Some library maintainers are quite strict about it.

Exactly, I understand your point about less dependencies on third parties.

CScriptBuilder somewhat became an important part of the library providing includes and attributes, now it is basically a hard to avoid addon.

In my case as I mentioned I had to fork and change it to make it compatible with CLib (also had to add a few additional handles for attribute query results - wrappers around those vector of std::string)

With those little changes I'll gladly remove my forked version.

Yes, I know. But I don't want to lock myself in a corner. I do adjust the core library interface every now and then. With the add-ons I'm even less strict as they are mostly meant for showing how some things can be done, and I don't even attempt to try to make them a fit-all-projects type of things. Every application developer is free to take the pieces they feel works for them, and just ignore the rest.

Now, if I do the change I will most likely do it so CScriptBuilder uses more of std::string rather than less. It sounded like you would prefer the other way around, is that right?