WitchLord

Moderators
  • Content count

    8018
  • Joined

  • Last visited

Community Reputation

4679 Excellent

About WitchLord

  • Rank
    Moderator - AngelCode

Personal Information

  1. Assert failure in asCExprValue::GetConstantDW

    Thanks for providing the snippets for reproducing the problems. It makes it so much easier to identify and fix the bugs. I've fixed this latest one in revision 2418. Regards, Andreas
  2. Assert failure in asCExprValue::GetConstantDW

    I've fixed this in revision 2416. Thanks, Andreas
  3. Compile error with AS_DEPRECATED

    Thanks for letting me know. I've fixed this in revision 2415.
  4. Angelscript on Github!

    Nice. Thanks for taking the time for contributing that to the Linguist library.
  5. ARM questions

    gcc and clang is for the most part compatible. While I haven't tried it, odds are that as_callfunc_arm_gcc.S will work with clang too. From your second question I gather that you're compiling for 64bit ARM. Unfortunately AngelScript doesn't yet have support for native calling conventions on 64bit ARM platforms, only 32bit. You'll have to use the generic calling convention on 64bit ARM platforms for now. The auto wrapper add-on will allow to skip writing lots of wrappers manually.
  6. Variadic arguments support

    You don't need to register one for each combination of type and length. With the use of the variable parameter type and default arguments you can potentially implement and register a single function with the maximum number or arguments that you wish to support. Of course, if you're thinking of supporting a huge number of arguments, then you probably want to provide at least a couple of variants with less arguments that will likely be more frequently used to avoid unnecessary overhead when all the extra unused parameters are evaluated with the default argument.
  7. Passing Script Objects

    You would have to provide a shared interface, or class, that both script modules have access to. The script object that will be passed from one module to the other should then implement that shared interface (or inherit from the shared class). Regards, Andreas
  8. Variadic arguments support

    Not with the variadic syntax. However you can do something similar with dictionaries, allowing a syntax like this: void OnScriptInit() { printf("%s-%d", {{'arg0', 'test'},{'arg1', 1}}); return; } The dictionary would even be able to receive updates so the function can return values into the dictionary. If you do not like the idea of dictionaries, you could use an array instead. Though I don't currently supply a standard add-on for an array that can hold variable types in the elements. With a little effort you ought to be able to implement that yourself by merging the code from the array and dictionary add-ons. The implementation to support actual variadic argument lists is still on my to-do list, but currently with a very low priority.
  9. Reference Counting Problem

    Do you really need the vector and matrix types to be reference types? Couldn't they be value types? In my own math library I treat them as value types. Unfortunately safety and performance do not always go hand-in-hand. Perhaps you should not expose the opengl shader programs directly to the script, and instead have proxy functions that transform the data prepared by the script into the format expected by the opengl shaders. If you do not really bother with safety you can relax the controls in the script compiler by setting the engine property asEP_ALLOW_UNSAFE_REFERENCES to true. That might help allow you to work a little closer to the way C++ does without requiring the matrix and vector types to be reference types. Along this way of thinking you can also provide functions to allow the scripts to manually allocate and free memory for matrices and vectors. You could register a matrix_ptr type to represent a pointer to a matrix allocated on the heap, then have implicit cast operators to cast to a matrix type.
  10. Get list of used namespaces

    You could enumerate the global properties, functions, and types and look-up the namespace of each. Finding out if a function accesses a variable, function, or type from a different namespace is not as easy though. With some work it ought to be possible to enumerate the instructions and verify the entities accesses using the same interface used by JIT compilers. What do you need this for? If it is something that could be useful for others too I'll evaluate implementing some interface to make it easier to enumerate used namespaces.
  11. shared by default

    Including everything from a directory into a single module when compiling sounds like a much easier and less restrictive solution than trying to make everything shared across modules. Your application can easily list all the files in the directory using a name mask (for example *.as) and include each of them as a separate script section (AddScriptSection) in the module before calling Build. The #include directive is not really part of the core language. It is implemented by the application, if desired. The standard add-on ScriptBuilder has a simple implementation that you can use as a base to write your own custom solution.
  12. shared by default

    Not without customizing the library. Why would you want to make everything shared by default? The global variables that you mentioned is one reason. The fact that if everything is shared you'll have difficulty in creating unique logic in separate modules is another. If everything is shared, then why not just put everything in a single module and be done with it. Not at the moment. Support for global shared variables has not yet been implemented. It is on my to-do list though.
  13. error compiling on gcc/x64 with address sanitizer

    That was it. After updating g++ to 5.4.1 the problem was reproduced. I've checked in your fix under revision 2410. Thanks, Andreas
  14. error compiling on gcc/x64 with address sanitizer

    I'm running g++ 4.8.4 on Ubuntu 14.04. I'll upgrade g++ and see if that allow me to reproduce the problem.
  15. error compiling on gcc/x64 with address sanitizer

    I didn't encounter any problem compiling the library using address sanitizer with GNUC and Ubuntu 64bit. What other compiler options are you using? Perhaps it is a specific combination of compiler options that causes the problem you reported. I used the following: g++ -m64 -std=c++11 -fsanitize=address -Wall -fPIC -fno-strict-aliasing -o obj/as_callfunc_x64_gcc.o -c ../../source/as_callfunc_x64_gcc.cpp