Jump to content

  • Log In with Google      Sign In   
  • Create Account

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Jul 19 2016 06:32 PM

#5301089 Clang Asgettypetraits

Posted by Andreas Jonsson on 17 July 2016 - 10:25 AM

Fixed in revision 2335




#5301082 Clang Asgettypetraits

Posted by Andreas Jonsson on 17 July 2016 - 09:59 AM

Thanks. I'll add defined(__clang__).




#5298148 AngelScript 2.31.1 is out

Posted by Andreas Jonsson on 26 June 2016 - 03:53 PM

Despite it being 4 months since the last release, this is not a big release. This release contains mostly bug fixes and a few minor enhancements.

 

I would have liked to include more, but time to work on AngelScript has been very short the last months. Rather than prolonging the release further until I had the time to implement something bigger, I decided it was time to release what I had so that everyone can take advantage of the bug fixes.

 

Regards,

Andreas




#5298030 Problem with a function of C++ object which returns a delegate to the AngelSc...

Posted by Andreas Jonsson on 25 June 2016 - 03:36 PM

Is this with version 2.31.0? 

 

Have you tried the latest WIP version? Several bugs related to function pointers crept into version 2.31.0, but all of them have been fixed in the WIP version already (including a bug that prevented returning function pointers from registered functions)




#5292546 The compiler crashes

Posted by Andreas Jonsson on 19 May 2016 - 06:20 PM

As I suspected. This problem had already been fixed in the latest WIP version.

 

 

Thanks for the compliments on the library. Let me know if you encounter any other problems, or have any suggestions for how to improve the library further.

 

Regards,

Andreas




#5290891 Various unexpected behaviors of AngelScript 2.31.0

Posted by Andreas Jonsson on 09 May 2016 - 04:29 PM

Thanks for letting me know. I'll look into it.




#5290677 BmFont does not includes invalid char glyph in my own font

Posted by Andreas Jonsson on 08 May 2016 - 11:34 AM

The following is used to determine the glyph index for the invalid char glyph:

// Get the default character instead
TEXTMETRICW tm;
GetTextMetricsW(dc, &tm);
WORD glyph;
fGetGlyphIndicesW(dc, &tm.tmDefaultChar, 1, &glyph, 0);
idx = glyph;

There appears to be a bug in BMFont when not rendering the glyphs from the true type outline though. I'll need to investigate and fix this.




#5284410 Refcount mismatch when discarding module.

Posted by Andreas Jonsson on 30 March 2016 - 08:57 PM

I've fixed the bug in revision 2309. 

 

If you don't want to upgrade to the latest revision from the SVN, you ought to be able to apply this fix locally to version 2.30.2.

 

https://sourceforge.net/p/angelscript/code/2309/tree//trunk/sdk/angelscript/source/as_module.cpp?diff=2274

 

Regards,

Andreas




#5284265 AngelScript and Fastdelegates

Posted by Andreas Jonsson on 30 March 2016 - 08:45 AM

True, an arbitrary method pointer can have different sizes. But in your case the method pointer to the FastDelegate's operator() method will always be of the same size regardless of the arguments (on MSVC it will have the size of a simple pointer), but in your case you're probably best to typedef a simple class method as it will be more portable.

 

 

// Declare a simple dummy class so the compiler can determine what a method pointer would look like,

// i.e. it can see that the method pointer won't need to keep track of multiple or virtual inheritances

class CSimpleDummy {};

typedef void (CSimpleDummy::*SIMPLEMETHOD_t)();
 
// Take the address of the FastDelegate's class method like this:
SIMPLEMETHOD_t methodAddr = reinterpret_cast<SIMPLEMETHOD_t >(&ScriptComponentMethodString::operator());
 
 

The methodAddr can then be passed from the exe to the dll just like any other primitive type. AngelScript will take care of interpreting the method pointer and setting up the arguments for the call dynamically based on what you tell it in the function declaration string when registering the method with the engine.




#5283625 Various unexpected behaviors of AngelScript 2.31.0

Posted by Andreas Jonsson on 26 March 2016 - 04:36 PM

I've fixed all the bugs reported here in revision 2308.

 

Thanks,

Andreas




#5282692 Various unexpected behaviors of AngelScript 2.31.0

Posted by Andreas Jonsson on 22 March 2016 - 11:49 AM

All, except the last are valid bugs and I'll look into them, and have them fixed a.s.a.p.

 

The last one is as you suspect a special case, and while it may look odd, it is specifically designed to work so that this type of expression can be used in code where you don't know at the time of writing the actual type of the argument given to the function. Consider for example macros, templates, or mixins, where you write the code once and then reuse it in different situations.

 

I also have a case in the console sample that takes advantage of this. Here I register various overloads of a special function called _grab that is used to catch the value of the expression written on the console input line and print it on the screen. When the expression doesn't have any value (i.e. void) then the overload _grab() is used. The statement written to the console input is then compiled and executed by the application like this:

void ExecString(asIScriptEngine *engine, string &arg)
{
  string script;
 
  // Wrap the expression in with a call to _grab, which allow us to print the resulting value
  script = "_grab(" + arg + ")";
 
  int r = ExecuteString(engine, script.c_str(), engine->GetModule("console"));
  if( r < 0 )
    cout << "Invalid script statement. " << endl;
  else if( r == asEXECUTION_EXCEPTION )
    cout << "A script exception was raised." << endl;
}

If this is causing a problem for you I could add an engine property to allow you to turn off this behaviour in your application.




#5280453 Crash instead of null pointer exception on opIndex

Posted by Andreas Jonsson on 09 March 2016 - 07:07 PM

There was indeed a bug in asBC_Thiscall1. Even if your first opIndex had returned a null handle (instead of a reference) it would still crash since asBC_Thiscall1 didn't verify the object pointer.

 

I've fixed this now in revision 2303.

 

Regards,

Andreas




#5280445 Difference between object handles/references

Posted by Andreas Jonsson on 09 March 2016 - 06:09 PM

The difference between a reference and handle in AngelScript is pretty much the same as the difference between a reference and a pointer in C++.

 

You already stated one of the differences: "I also understand that a reference cannot be null and a object handle can be".

 

Another difference is that a reference cannot be reassigned to point to a different object while an handle can be.

 

 

When registering functions with AngelScript you'll have to be careful with the choice of reference versus handle due to the reference counting. When registering the function as returning a reference, the C++ function must not increment the ref counter of the object, but when registering the function as returning a handle, the C++ function must increment the ref counter of the object (or use auto handles to tell AngelScript to do that for you). If you don't do this correctly you may end up with memory leaks, or crashes due to the objects being freed too early.




#5279671 Crash instead of null pointer exception on opIndex

Posted by Andreas Jonsson on 05 March 2016 - 09:59 AM

How is the opIndex method registered with the engine? Is it registered to return a reference, or a handle?

 

A method that is registered to return a reference really shouldn't be allowed to return a null pointer as the reference is expected to be to a valid object. Only return a null pointer if you're also raising an exception to tell the engine that the returned reference shouldn't be accessed.

 

 

Still, I'll see what to do about this. I have a feeling that this problem was introduced in version 2.30.1 (released last year) when I added the bytecode instruction asBC_Thiscall1 to optimize access to array elements (and any other method that takes a single 32bit integer argument).




#5278388 AngelScript 2.31.0 is finally out

Posted by Andreas Jonsson on 26 February 2016 - 07:38 PM

Wow, it's been 6 long months since the last release. Never before during the 13 years that I've been working on AngelScript has it been this far between two releases. 
 
Naturally, with such a long period, the number of changes that have been made are also larger than anytime before. As this is a major release, there is also interface breaking changes. Not to worry though the changes are for the better, and I'm certain that it shouldn't take much work for users to upgrade to the new version. 
 
The most significant change to the interface is that the asIObjectType has been removed. Instead the new asITypeInfo has been introduced. asITypeInfo has all the methods that asIObjectType had before to inspect object types, and it also has new methods to inspect enums, typedefs, and funcdefs. With this change I've unified the way that type information can be handled by the application, which I hope should be welcome change.
 
Of course, some methods on the other interfaces, e.g. asIScriptEngine, asIScriptContext, asIScriptModule, etc, have been changed to reflect the move from asIObjectType to asITypeInfo, but developers ought to feel right at home with the changes.
 
These changes to the application interface has also triggered a rather extensive refactoring of the code within the library, so that was another reason for the long period since the last release.
 
Some other enhancements that also made it in to this release are:
  • support for storing an auxiliary pointer with functions registered using asCALL_GENERIC
  • included engine property asEP_ALLOW_UNICODE_IDENTIFIERS for those who do not like the restriction of using only English alphabet in the scripts
  • funcdefs can now be registered/declared as members of classes
  • included a simple datetime script add-on for telling the time
  • added a method getInput in asrun to allow it to take input from the user
I never intended to make AngelScript a stand-alone scripting language, but I've been adding some functionality to the asrun sample every once in a while, and it is has now reached a stage where it can actually be used to script some tasks that I would normally use other script languages for. For example, I now use asrun to prepare the SDK package for the release. It actually feels quite cool to see this work out so well despite it not being the intended use for the library.
 
Regards,
Andreas





PARTNERS