After yet another long wait version 2.7.0 is finally here. The main new feature for this version is the support for class interfaces. Script classes can now implement interfaces that have been declared either by the application or in the scripts. This allow the scripts to provide polymorphism, still without inheritance though. I also modified the way to obtain compiler messages from the library so that it is now much more flexible. Instead of receiving a string with all the information, the application now receives a structure. This allows the application to format the string as desired, and also simplifies filtering of the messages. The portability of the library has also been improved. Manu Evans added support for native calling conventions on MIPS processors, which are mainly used on PSP and PS2. Pecan Heber added support for native calling conventions on Mac OS X with PPC, though this has not yet been fully tested and may not work. I have also done a lot of testing on the 64bit support, and although support for native calling conventions still hasn't been implemented 64bit platforms are now fully supported. Regards, Andreas

If you happen to be using anything I've released, and these changes break it, please let me know. My current project doesn't use any scripting at all, and I haven't the time to upgrade a lib I'm not using. :)

I was compiling AngelScript 2.7 with Dev-cpp (MingGW) and found the following warning:

AngelScript\angelscript\source\as_builder.cpp In member function `void asCBuilder::CompileClasses()': [Line 1060] [Warning] cannot pass objects of non-POD type `class asCString' through `...'; call will abort at runtime

and like the other time... i have no idea what it means...

also, i've found out that it's not possible to compile the DLL using the "Best Optimization" for the compiler options. It says something about already defined symbols at link time (or something like that...).

I show that part of the Compile log:
C:\DOCUME~1\ALRAZ\CONFIG~1\Temp/cc8Iaaaa.s: Assembler messages:
C:\DOCUME~1\ALRAZ\CONFIG~1\Temp/cc8Iaaaa.s:926: Error: symbol `copyloop3' is already defined
C:\DOCUME~1\ALRAZ\CONFIG~1\Temp/cc8Iaaaa.s:931: Error: symbol `endcopy3' is already defined
C:\DOCUME~1\ALRAZ\CONFIG~1\Temp/cc8Iaaaa.s:1086: Error: symbol `copyloop1' is already defined
C:\DOCUME~1\ALRAZ\CONFIG~1\Temp/cc8Iaaaa.s:1091: Error: symbol `endcopy1' is already defined
[And many others like that here...]

make.exe: *** [obj/as_callfunc_x86.o] Error 1


However, it will compile just fine if you use any other of the optimization options.

By the way, in Code::blocks the option "Optimize fully (for speed)" causes the same problem.

Hi!

There's a problem with empty switch statements. They cause an assertion/segfault in asCArray. It can be fixed by adding the following check to as_compiler.cpp:

		cnode = cnode->next;	}	        // check for empty switch	if (caseValues.GetLength() == 0)	{		Error(TXT_EMPTY_SWITCH, snode);		return;	}	if( defaultLabel == 0 )		defaultLabel = breakLabel;	//---------------------------------        // Output the optimized case comparisons	// with jumps to the case code	//------------------------------------

TXT_EMPTY_SWITCH has to be added to as_texts.h

#define TXT_EMPTY_SWITCH  "Empty switch statement"

Thanks ALRAZ and the_bateman. I'll fix these problems for the next release.

Hi Andreas,
Great work on this. Would it be possible to have a way of enumerating all classes that implement a particular interface within a given module be possible? This would be handy for dynamically creating scripted instances that are guaranteed to conform to a given interface.

Cheers,
Will.

PS. I'll try & resurrect the x64 native calling code ASAP.

It should be possible. I'll think about the best way to implement this.

It would be great if you could get the native x64 code working. Yiannis Mandravellos of Code::Blocks was going to send me what he made, but I lost contact with him and don't know when/if that may happen. I guess he's too busy working on Code::Blocks to worry about AngelScript, especially now that they took the decision to use another scripting library.

Regards,
Andreas

Quote: Original post by WitchLord
I guess he's too busy working on Code::Blocks to worry about AngelScript, especially now that they took the decision to use another scripting library.

I'm sad to hear that. Especially since I think that Angelscript is the much nicer scripting engine than Squirrel.

Bye,
Martin

Yes, I was a bit sad about that too. But, they need a scripting language that is more mature than AngelScript and has full platform portability, so I think they made a wise choice.

It was just not the right moment for AngelScript. :)

For Squirrel you have to write warper function like in the generic mode of Angelscript. But the generic mode of Angelscript is also quite platform independent. It works at least fine on my Mac.

That Angle script is evolving that fast might scare some developers. Maybe you could try to make Anglescript 3.0 feature complete with inheritance, function pointers etc. :-)

For example lua became successful once the development speed of new features seriously decreased. They needed 3 years for the 5.1 update. Which is probably the other extreme ;-)

Bye,
Martin