We designed ChaiScript foremost as a tool for tying together your C++ objects, and did not initially consider that you would want to define types in ChaiScript.

Then, as we got further along and decided to give types a try, we thought they should be in the spirit of the rest of ChaiScript and very free form. If you want something rigid, you should define it in C++, not in ChaiScript.

However, I see your point about wanting to create types that are passed back from ChaiScript land into C++ land.

Your proposal is interesting, but I don't think it would ultimately solve your problem, because the dynamically typed attr would still exist. The user could ignore that option and still make things dynamically typed.

Perhaps requiring the user to provide a typemap would work for you? This is something you could validate at runtime and perform any conversions that you wanted to based on what the user specified.

attr Rectangle::type_map
attr Rectangle::height
attr Rectangle::width
fun Rectangle::Rectangle() { this.type_map = ["height":int_type, "width":int_type]; }

This would make you do a little bit more heavy lifting, but by requiring the user to provide a type_map attribute, you could reject an object simply on its being missing. Then, you could further use the type_map as a driver to determine which attributes should get stored and how they should get stored.

This would allow the user even to use internal attributes for whatever purposes he has in mind, but will never get stored by your database tool.

I'm sure there are unanswered questions about the best way to extract/access/convert the stored data that we could help you with.

It's at least an idea, anyhow.

Just out of curiosity, is this a closed or open project? Is it something we would like to add to the list of projects using ChaiScript?

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

I understand the explanation and I agree it should not pose a problem. After looking through the docs again I can see that there is no implicit access to members I don't explicitly register so it's OK. I was really worried about users gaining access to protected or private members but I see it can't be so.

Thanks for the bug report. I've fixed the problem in SVN. You were correct that the stack was not being properly initialized in the case of adding objects to the stack from C++ during multithreading.

It'd help if you could post all of your source files as a bug report to chaiscript.googlecode.com. This way I can try to reproduce the problem and see where the error is. I'll do my best to debug it this weekend, or maybe tomorrow afternoon.

Thanks!

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

I'm getting crash when trying to add a shared_ptr<> variable (first variable)
to the chaiscript.

it seems like its accessing non exisiting index or element.

      void add_object(const std::string &name, const Boxed_Value &obj)
      {
        StackData &stack = get_stack_data();
        validate_object_name(name);
        stack.get<0>().erase(name);
        stack.get<1>().back()[name] = obj;
      }

it happens on last line of this method.

this is the setup (processDES can be called from multiple threads )

static chaiscript::ChaiScript g_chai;
static boost::once_flag g_chaiInitOnce = BOOST_ONCE_INIT;
 
void g_chaiInit()
{
	g_chai.add(chaiscript::fun(&parseHex),"hex");
	g_chai.add(chaiscript::fun(&getTagValue),"getTag");
	g_chai.add(chaiscript::fun(&setTagValue),"setTag");
}
 
void processDES(DcDirMetaInfo_ptr pMetaInfo,DcElemList_ptr pElemList,const string& des)
{	
	boost::call_once(&g_chaiInit,g_chaiInitOnce);
 
	g_chai.add(chaiscript::var(pElemList),"dicom"); // This is the call that crashes in add_object
	g_chai.add(chaiscript::var(pMetaInfo),"meta");
 
	g_chai.eval(des);	
}

any ideas ?

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.

Hi there , I love ChaiScript! But, will it see some performance boosts in the future?
Especially for-loops (C-style) seems to be very slow.

Hi,

How does the above example work with the modification?

	void Print1(int value){std::cout << value<<" Print from Class1" << std::endl;}

It does not compile anymore after adding the parameter, showing the following error (MacOSX 10.6.4, gcc4.2 and gcc4.5):

/opt/local/include/boost/function/function_template.hpp: In static member function ‘static void boost::detail::function::function_void_mem_invoker1<MemberPtr, R, T0>::invoke(boost::detail::function::function_buffer&, T0) [with MemberPtr = void (Class1::*)(int), R = void, T0 = Class2*]’:
/opt/local/include/boost/function/function_template.hpp:913:   instantiated from ‘void boost::function1<R, T1>::assign_to(Functor) [with Functor = void (Class1::*)(int), R = void, T0 = Class2*]’
/opt/local/include/boost/function/function_template.hpp:722:   instantiated from ‘boost::function1<R, T1>::function1(Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = void (Class1::*)(int), R = void, T0 = Class2*]’
/opt/local/include/boost/function/function_template.hpp:1064:   instantiated from ‘boost::function<R ()(T0)>::function(Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = void (Class1::*)(int), R = void, T0 = Class2*]’
test_inherit.cpp:31:   instantiated from here
/opt/local/include/boost/function/function_template.hpp:225: error: no match for call to ‘(boost::_mfi::mf1<void, Class1, int>) (Class2*&)’
/opt/local/include/boost/bind/mem_fn_template.hpp:163: note: candidates are: R boost::_mfi::mf1<R, T, A1>::operator()(T*, A1) const [with R = void, T = Class1, A1 = int]
/opt/local/include/boost/bind/mem_fn_template.hpp:184: note:                 R boost::_mfi::mf1<R, T, A1>::operator()(T&, A1) const [with R = void, T = Class1, A1 = int]

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 don't have any support for operator() in chaiscript, which is an interesting point that I will make a note of.

You would want to do something like:

chai.add(fun(&PSignal<void ()>::operator(), "emit"));.

Then in your chaiscript you could emit the signal explicitly:

mysignal.emit()

I'll look more closely at your example as soon as I get more time and see if I cannot make any more suggestions.

I've been considering a set of optional libraries that ship with chaiscript, like the stl extra that is currently there. boost::regex and filesystem were also considerations. boost::signal might be a good one too. You're showing that it could be a great way of hooking together c++ and chaiscript.

Regarding compile time, just wait :).

In all seriousness, 95% of what we need to do cannot really be done in compiled library code, but there are some techniques for making recompiles of your application faster. I should publish some docs on that. The gist of it is that you want to include ChaiScript in your main.cpp, then have a mylib.cpp that creates and returns a chaiscript::module object. Your this way, main.cpp (and the core of chaiscript) only needs to be recompiled rarely, and you make all of your changes inside your mylib.cpp.

-Jason