• Content count

  • Joined

  • Last visited

Community Reputation

4684 Excellent

1 Follower

About WitchLord

  • Rank
    Moderator - AngelCode

Personal Information

  1. Segmentation fault with dictionary retrieve to auto

    I've fixed the crash now in revision 2465. The problem was due to the dictionaryValue type not having opEquals operators, and when the compiler then attempted to look for valid opEquals operators on the right hand expression (null), there was a null pointer access failure due to 'null' not having any specific type associated with it. With the fix, your script will produce a compiler error message "No appropriate opEquals method found" on the if-condition. The error message is a bit too cryptic to my liking, as it is not immediately clear why there are no opEquals methods. I'll see if I can improve this in the future.
  2. Doing just that would lead to the script engine attempting to release the string constants after the string factory has been destroyed. This in turn might lead to a crash in your application. I've made a change in the string add-on so that the string factory is now allocated dynamically, and only deleted if the string cache is empty. This means that there will be a memory leak if the singletons are not deleted in the right order, but at least there is no risk of crashes. The leak is only upon application shutdown so you won't have any impact on this except if you run your application with any memory leak finding tool. You can get this change from the SVN revision 2464.
  3. Segmentation fault with dictionary retrieve to auto

    Yes, the line 'if( compoundData !is null)' is consistent with the backtrace. I'll give it another try with this code and let you know if I can reproduce the problem. I probably won't need to see your registered classes, as it appears to be just a problem related to the combination of 'auto' and the script dictionary add-on (or more specifically types registered with the asOBJ_ASHANDLE flag). In the meantime, can you answer the following? Are you using the latest 2.32.0 release? If not, which version are you using? Have you made any custom modifications on the dictionary add-on? If yes, can you share the modifications?
  4. The problem is that the static CStdStringFactory stringFactory in the scriptstdstring add-on is being destroyed before your singleton that holds the engine instance.
  5. Segmentation fault with dictionary retrieve to auto

    I haven't been able to reproduce the problem. I need more information from you in order to reproduce and fix this problem. The backtrace you're showing for the seg fault is not compatible with the script statement you say is causing the problem. The script statement is a declaration of a variable. It is actually a valid statement, as the 'auto' in this case assumes the type of 'dictionaryValue'. The backtrace shows that the seg fault happens when compiling the condition for an if statement, which is located in a double nested for-loop. Can you show me the full function that is being compiled when the seg fault happens?
  6. Make sure to shutdown the script engine before you exit main so it will have a chance to free up the memory and release any string constants that were allocated during the script compilations.
  7. Segmentation fault with dictionary retrieve to auto

    You're absolutely correct. The compiler should be giving an error message rather than crashing. I'll have it fixed.
  8. Call function with primitive ref parameter from C++

    Indeed. The documentation is wrong. The correct is to use SetArgAddress. I'll correct the documentation.
  9. Thanks. I'll investigate and fix this.
  10. Git mirror for Angelscript SVN repository, CMake support

    I've checked in the cmake changes in revision 2462.
  11. Git mirror for Angelscript SVN repository, CMake support

    This sounds good to me. I'll review and merge your changes into the svn. I've not made any such definition. I tend to try to allow whatever users ask for, as long as it is for the common good, and is something that I can provide without too much effort. Though I would think that most users that use CMake are most likely keeping up with the updates to this tool, so keeping support for very old versions is probably not worth the effort. I was under the impression that Git is the one that pulls the updates from SVN as they are committed, not the other way around. Perhaps someone else on this forum can give us a hint of how to best set this up.
  12. Git mirror for Angelscript SVN repository, CMake support

    I'm no expert in svn, just a regular user, and I have zero experience with git. I'm not sure if you're asking me to make any changes to the SVN repository on source forge, or if you're just laying out plans for how to best set up a github mirror repository. I am creating tags for each release. http://svn.code.sf.net/p/angelscript/code/tags/ If you want to synch git with a specific release that would be the best place to do so. I don't personally use cmake. The cmake projects available in the angelscript repository have been provided by other users. If you believe improvements can be made (such as upgrade the syntax) then please feel free to send me the updated cmake files and I'll have them checked in.
  13. implementing partial templates

    You can already do this without changing the angelscript library. You can register the template type with dummy behaviours and a callback routine that prevents any template instance that you don't explicitly want. Then you can register the template specializations for the types that you do want. This way the non-specialized template type can never be used in the script, and the compiler will print a useful error message. (If desired the callback routine can even print an additional informative message).
  14. AngelScript 2.32.0 is out

    A new version is out. The most significant changes in this version are: The string factory has changed to an interface. This is done so that the application can create the string constants at compile time rather than at runtime. This also reduces memory consumption as the script engine doesn't have to keep a copy of the string constants. Improved support for registering types that rely on composition. Now registered class methods and properties can directly refer to member components without the need for wrappers. Introduction of the 'external' keyword to explicitly tell the compiler that a script entity is external and must have been compiled and shared by an existing module. Compiler can now determine the type of initialization lists based on the use, so when there is no ambiguity it is no longer necessary to explicitly inform the type. Of course this release includes a long list of other smaller changes too. Please refer to the change list for the details. Regards, Andreas
  15. ScriptHandle addon doesn't check object type

    I've fixed this in revision 2454. Regards, Andreas