Hi everyone, I just felt like letting you guys know what's going on with AngelScript. Especially since it's been so long since I last released a new version, since February 13th to be exact. This is the longest period between releases since I begun writing AngelScript in early 2003. Part of the long wait is due to my vacation, during which I went about one month without working at all on AngelScript. Another part has been due to my day job, in which I've seen an increased work load the last few months (not that I'm complaining, because it came with a promotion as well. I'm now a senior development analyst [grin]). Well, currently I'm doing a serious bug hunt. I'm surprised to see so many bug reports for these last versions. There are always a few with every release, but this time has beaten all records. I do not believe this is due to the quality of my testing decreasing, but rather on the user base increasing which exposes more and more ways of using the library, which in turn exposes new code paths that haven't been thuroughly tested yet. This is all for the better, because I'm fixing these bugs, and my test framework is growing with each bug report. So these same bugs won't appear again in the future. There are still a few bugs that I need to root out. I'll also try to get the native calling conventions on Mac OS X / PPC working before I release 2.8.1. This in turn will allow me to do even more tests which is important, because I suspect there are still a few bugs on big endian CPUs, even though my test framework doesn't detect any problems at the moment. If you're having any problems with AngelScript, now's the time to report them. And I'll have them fixed before the next release. Regards, Andreas

Very cool! I haven't had any issues besides my own ineptness, but I'll keep my eyes open.

One recommendation that I have is that you should improve the docs. They are 'OK' imho, but somethings are difficult to find, or just aren't there. As well, more code snippets would be awesome imho.

Cheers

I'm sadly aware of the poor documentation. It's currently mostly a reference manual which unfortunately means that you at least need to have a notion of where to look for it to be useful. Documentation is not my strong side though, so it will probably be a while before I'll improve it in any significant way. Besides, there is so much to do on the code side of things, that it's difficult to find the time to spend on extras, such as tutorials, code-snippets, or add-ons.

One thing that I would like to do, is to make the documentation into a Wiki, that way I could update sections of it as I find the time. It would also be easier for me to organize the reference section in a better way. Though, even with a Wiki I need to have a way of generating HTML pages for an offline version that can be included in the SDK.

Regards,
Andreas

Why not a true wiki where others can add information to it?

Quote: It's currently mostly a reference manual which unfortunately means that you at least need to have a notion of where to look for it to be useful.

Yes, which when just starting, makes it difficult to find anything. Thus all my damn posts! haha

Cheers

There is already a wiki for AngelScript here: http://angelscript.pbwiki.com/

But I cannot use that for the manual, since the manual needs to be in synch with the code. I could include user contributed articles in the manual though, if someone were to write them.

Regards,
Andreas

This is good news. I can barely await the next release. The docs should definitely be improved tho (more newbie-friendly). I'd like to request more info on the different library types (single threaded, multithreaded, dll, etc.) and examples when to use them.

What library types do you mean? The ones I talk about in the article on compiling the AngelScript library?

Single-threaded is usually slightly faster than multi-threaded, due to not requiring extra code to guarantee thread safety.

I normally use multi-threaded DLL though when compiling my projects, because I rarely need the extra speed, and prefer the smaller binary size of using the shared library over the statically linked library. Using the dll also has the added benefit of automatically gaining any updates from Microsoft in this code.

There is rarely any use of compiling AngelScript as a DLL though, as different versions of AngelScript are rarely binary compatible, meaning that you can't easily update the DLL with a new version of AngelScript and expect the programs that use it to continue working.

The only reason I can see for using AngelScript in a DLL is if you wish to provide scripting capabilities to a program that already allow some form of plugin though not scripting. In that case you'll still compile AngelScript itself as a static library, and then link with it in your plugin DLL.

There is also a drawback with using AngelScript from a DLL, and that is that the memory management will be separate from your main application, which means that you may discover that objects allocated on one side of the DLL interface cannot be correctly deallocated on the other side, since they use two different heaps.

Regards,
Andreas

Yes, that's what I had in mind. Makes sense, but it still confuses me a bit tho. Some of your examples (those that I have tried - the "tutorial" sample is one of them) always seem to work regardless of the static library type. But I'm having some trouble getting my own projects to work and let that be a simple copy/paste of your own code. I'll make a separate thread at some point. Ty for the reply.

Update:

PPC native calling conventions are now working on Mac OS X (and also on PlayStation 3, thanks to Jeff Slutter from ReactorZero). I've fixed plenty of other bugs as well, but there are still a few bugs that need to be taken care of before the 2.8.1 release.

Regards,
Andreas