There are a variety of techniques that can be used to share data between chaiscript defined objects and C++. I've just checked in a unit test to verify that it all worked, and provide some examples.

Regarding forcing a variable to be a certain type or not, let's start by clarifying terminology. Hopefully I have this right, but ChaiScript is a strongly typed dynamic language. The variable type is determined at runtime, but once it is set, it is set permanently. There are very few automatic type conversions. Conversions between pointer, reference, const, boost::shared_ptr happen automatically, whenever they safely can. Pointers that would require modifying the underlying type (ie, int->float) do not happen automatically.

There is exactly one type of variable declaration in ChaiScript, the "var" that has its type set on the first assignment operation.

However, you can force something to be a certain type during a function call by using function guards, like:

fun test(x) : x.is_type(int_type) {
 
/* do something */
 
}

Hope that helps.

-Jason

No, this is not possible. In ChaiScript, technically, methods do not exist; only functions exist.

So, a method call like:

obj.somefunc();

Is translated to:

somefunc(obj);

So, fundamentally, the user will always be allowed to add functions that can operate on your class. This means that the method sugaring we perform essentially means that all classes are always extendable, inside of script.

Unless I miss your meaning. What affect are you going for? What is your use case?

Im thinking that both my errors are caused by the same thing.
(like some portion of the stack is not being initialize)

To my memory, there aren't yet ways to do number literals like you describe, though it shouldn't be too difficult to support them.

In ChaiScript, we intentionally focused on flexibility over performance. Why? Let's think about how you might use a scripting language in a C++ application:

You build up your C++ app, but realize parts should be runtime configurable. These types of things might be settings, business logic, or game scripts.

These call back into the engine to fire off the events or set the values for you. The script itself is merely a set of calls back to the main application.

In ChaiScript, we went one step further. The entire script is calls back to the ChaiScript engine and your application. Every addition, every step of the loop, is all calling back to ChaiScript. This makes it generally less performant, but in return you get the ability to augment what each script does to the nth degree.

We chose to put less restrictions on the programmer. We could have tightened things down and prevented that level of modification, and for our efforts we might have gotten something of a speed increase, but in our opinion, if you're using ChaiScript for time critical things, you're using it wrong. Put the time critical sections in C++ where they will always work best, and fire them off from your script.

Hope that helps.

It would appear that you have a typo in your main.chai:

var x = LoadAnimMesh("C:\man.b3d")

should be:

var x = LoadAnimMesh("C:\\man.b3d")

Normal C++ escaping rules apply.

We should post your example for others to look at. Using the template to help you register the signal functions is what we needed to do when exposing std container classes.

Unfortunately there is not (and cannot be) a more generic way of exposing templates because we need to know the function pointer address of the functions we want to call at compile time. The only way to know these addresses is to instantiate the templates that are being used, and get the functions from them, as you did.

The important thing to realize, as you did, is that a template member is just like any other function, you just have to be explicit about which instantiation of the template you are referring to.

-Jason

In ChaiScript there aren't global variables. You can register a constant value in your C++ application that is global, but you can't make a variable that all functions can see.

If you're curious why:

The short answer is that global variables aren't good practice.

The long answer is that we liked the idea of reusable functions in ChaiScript. The easiest way to make reusable functions is to always have a function's parameters be explicit, so you can just call it from any context and know you're passing in everything it needs.

The even longer answer is that ChaiScript is automatically thread-safe. If you take the same engine and call scripts in different threads, this should, in theory, "just work". Having global variables makes this automatic safety difficult and the implementation hairy (since now some variables would be handled differently than others).

I'll look into it this evening, not sure why you would have a problem with that one.

We've implemented a fix that solves the naming conflict problem you were having. Don't forget to also properly initialize your members in your constructors. Since members are not typed we have no way of initializing them for your.

Your error is something of a red herring, the actual problem is that the local variables for an object type and the parameter names for the constructor are conflicting.

var kPI = 3.141592653589793
var kSolarMass = 4.0 * kPI * kPI
var kDaysPerYear = 365.24
var dt = 0.01
 
attr Vector3::x
attr Vector3::y
attr Vector3::z
def Vector3::Vector3(m_x, m_y, m_z) {
    this.x = m_x
    this.y = m_y
    this.z = m_z
}
 
def Vector3::`+`(rhs) {
    return Vector3(this.x + rhs.x, this.y + rhs.y, this.z + rhs.z)
}
 
def Vector3::`-`(rhs) {
    return Vector3(this.x - rhs.x, this.y - rhs.y, this.z - rhs.z)
}
 
def Vector3::`*`(rhs) {
    return Vector3(this.x * rhs, this.y * rhs, this.z * rhs)
}
 
def Vector3::Length() {
    return sqrt(this.x * this.x + this.y * this.y + this.z * this.z)
}
 
def Vector3::SquaredLength() {
    return (this.x * this.x + this.y * this.y + this.z * this.z)
}
 
attr Body::position
attr Body::velocity
attr Body::mass
def Body::Body() { }
def Body::Body(m_x, m_y, m_z, m_vx, m_vy, m_vz, m_mass) {
    this.position = Vector3(m_x, m_y, m_z)
    this.velocity = Vector3(m_vx, m_vy, m_vz)
    this.mass = m_mass
}
 
var sun = Body(0, 0, 0, 0, 0, 0, kSolarMass)

The above should work for you. We will see about fixing the scope problem so that this lookup/naming problem doesn't catch other people, (and should probably fix that error you are getting, to something more reasonable too).

I'll look into the IRC channel, might be hard for the main developers to keep up with, but we'll see if we can't give it a shot.

-Jason

Hey, when you define CHAISCRIPT_NO_THREADS the code will fail to compile under MSVC. This is due to '#warning' not being a valid preprocessor command.

I'm not sure what the equivalent is, but "#pragma message("Blah")" will print a message to the output window, so that's kind-of an alternative.

At any rate, you need to disable the use of "#warning" on MSVC or it will fail to compile. :)

Thanks.

In boxed_value.hpp, you specialize std::swap. Under VC10, if Chaiscript's headers are included in more than one translation unit, the template specialization causes linker errors due to a redefinition of an existing function. A fix is to simply mark the function as 'inline'. Unfortunately I don't know if the standard permits you to do that, or what the exact rules are for specializing std::swap, so I'll leave that up to you. However I assume that would be a legitimate fix, as typically defining functions in header files means you need to mark them as inline or for them to be templates in order to avoid linker errors.

The second is that if Boost.Signals2 has its headers included AFTER ChaiScripts, then you will get compiler errors.

To work around this (because I use Boost.Signals2 in my application), I simply make sure to always include Signal2's headers before ChaiScript's. I'm not sure of the actual problem here, so again, I can't really give you a solution and I'll leave that for you to decide.

Sorry to be a pain. :(

Thanks for being so helpful though.

P.S. There's one more potential issue I'm investigating, but it's hard to reproduce and I'm not even sure yet if it's my fault or ChaiScript's fault. If it's an actual issue I'll post again with more info, otherwise don't worry about it, it's probably a non-issue.