Angeljuice released!

[quote]How does it handle memory, does it use a pool, or does it allocate globally, or does it allow the register code to define allocators ?
actually you can define a global allocator pool (for every object) or per single object allocator: you manage how to treat what u allocate. or you can leave the engine handle it.

actually a class is just a struct, virtual table is implemented but not usable, i think in a couple of weeks we can see inheritance implemented.

you have a couple of macros that will easy that setup:

engine->RegisterGlobalFunction("int& callFunction(float&) const", asFUNCTIONPR(callFunction, (float&) const, int&), asCALL_CDECL); engine->RegisterGlobalFunction("int callFunction(const int, const int)", asFUNCTIONPR(callFunction, (const int, const int), int), asCALL_CDECL);

yeah, this is actually lacking, but i’m implementing it myself… it will be completed in near time.

The thing I was getting at with the registration is that if you have to give the signiture in the string as well, what if the signiture changes and you forget to change that one as well? Boost’s version gets the signiture from the function pointer itself, should look at the def() function (def.hpp, def_helper.hpp, def_visitor.hpp) and have him use that style, or at least not a string, maybe a template param so it can be checked at compile time so it can static assert. He really should not use a string though because then it makes it incredably hard to add simple wrappers around it to auto-link things.

And to C++ the only difference between a struct and a class is that by default everything in a struct is public and by default everything in a class is private. :slight_smile:

yeah this could come in hand. i have to investigate how boost::python do this… and maybe have the possibility to register in both ways: specifying a declaration or automagically. the ability to choose the signature sometimes is useful.

mmmh the only thing is… actually isn’t any useful if you want to publish functions with references, or pointers…

def("f", f, return_internal_reference<1, with_custodian_and_ward<1, 2> >());

for publishing a simple:

X& f(Y& y, Z* z) { y.z = z; return y.x; }

seems odd and badly understandable. what if you change f signature
to not have references or adding another one ? you finally have to change the registration code as well.

If you just wanted to register that function, then def(“f”, &f); would be fine. That example is only showing when the lifetime of one object relies on the lifetime of another object so that one thing is not prematurely deleted. You would not have to deal with that in angelscript since it is not a dynamic typed garbage collected language. If he ever added GC though, then he would have to worry about those exact things and how to pull it off in his registering. :slight_smile:

atm angelscript have a gc :wink:

It does? I thought it was C/C++ like…

In that case, how do you currently register something like that where a lifetime of one object depends on the lifetime of another so you don’t crash the vm?

you wouldn’t :wink:

So you could crash the vm using something like the above example then? :stuck_out_tongue:

Gotta love vm programming…

no that would not crash since it supports references natively and object declared in script have handles (something like pointers but more safe) so their lifetime is controlled by the engine with reference count. i simple register a function that return a reference and take a reference (as i think them in c++) and a handle (think it as a pointer) not with_compliance_and_ward :wink:
this topics has turned a war seems… eheh

Heh, just wondering how AS works internally. How does it hold internal references like that though?

you can register objects with or without reference count. it’s up to you, but for have handles support you should register with the class the two methods (addref/release) in the engine. so creating a handle in the script just tell the engine to increment the refcount for that object, and when the handle goes out of scope, the refcount will be decremented. also you can decide for every function that takes a handle to let the engine do inc-call-dec or just do it yourself (or not). references are handled by default without have to register special methods or such.

Hi kraken,

[quote=“kraken”]i finally launched it…

I found that insertion of new line into
large text (2000 lines, each is about 80 symbols) in Angeljuice script-edit box works very slow.
But also I found that selection text for copy or cut work very fast unlike standard juce::TextEditor, it is good.

So, could you give me direction how to improve speed of insertion new lines into your texteditor with large amount of text?

ok, that’s the way it works (briefly). all the logic of document parse is done in AngelJuice_SyntaxDocument.h/.cpp . it basically is an extracted version of the juce standard TextEditor atoms splitting function, extended to handle creation of atoms depending on their lexical types.

the functions that probably need some speedup are insert / remove / split / append, since they have to update syntax atoms that maybe have changed nearly the insertion (or remove) index.

you have to be smart about how you decide to reparse text. i’m going upwards and downwards till i find a newline or a multiline/single line comment and reparse till that. also, updateSyntaxSections (called from insert / remove / split / append) could be more smarter since it extract text from the string that it have to reparse, and do a reinsert back in after it have been parsed.

Things should be better by providing a better way to store internal text atoms, and a better SyntaxDocument class which should provide functions to fast get and set internal text.

Ah now i see also that i was a bit lazy about calculating offsets when i coded that, in SyntaxTextEditor insert / remove function i do “repaintText (0, -1);” which will basically repaint the whole text starting at char index 0. Try to make it repaint only the range SyntaxDocument insert / remove have changed.

anyway, the way things are handled now are for relatively small scripts, and the use of #include helps a bit on this.

hope this is enough…

anyway any improvements are well appreciated since i will release a new version soon…