trunk/pygtk/extmethod.cpp

#include "extmethod.h"

#include <stdexcept>
using namespace std;

#ifndef ASCXX_USE_PYTHON
# error "Where's ASCXX_USE_PYTHON?"
#endif

/*--- WARNING ---
    In the C++ interface I'm trying to make the nomenclature
    a bit more systematic. 'ExternalFunc' as listed end up
    being things that you can call like 'asc_free_all_vars' --
    they are effectively externally-defined methods on ASCEND
    models, so I'll call then 'external methods'.

    Meanwhile, external relations I will call 'ExtRelation'.

    External functions, if ever implemented, will be for
    functions like 'sin', 'exp', etc.
*/

ExtMethod::ExtMethod(const struct ExternalFunc *e) : e(e) {
    // nothing else
}

ExtMethod::ExtMethod(const ExtMethod &old) : e(old.e) {
    // nothing else
}

ExtMethod::ExtMethod(){
    throw runtime_error("Can't create empty ExtMethod");
}

#ifdef ASCXX_USE_PYTHON
/**
    Declare and register a new external script method from Python

    @TODO not sure if this is the right place for this... problems when creating
    the method might cause problems. Perhaps it should be in the 'library'
    object instead?
*/
ExtMethod::ExtMethod(PyObject *obj){
    CONSOLE_DEBUG("CREATING EXTERNAL PYTHON METHOD");

    ExtMethodRun *runfn;
    runfn = (ExtMethodRun *)importhandler_getsharedpointer("extpy.method");

    CreateUserFunctionMethod("myextpyfn",runfn,0,"external python function",(void *)obj);
    e = LookupExtFunc("myextpyfn");
}
#endif


const char *
ExtMethod::getName() const{
    return ExternalFuncName(e);
}

const char *
ExtMethod::getHelp() const{
    return e->help;
}

const unsigned long
ExtMethod::getNumInputs() const{
    return NumberInputArgs(e);
}

const unsigned long
ExtMethod::getNumOutputs() const{
    return NumberOutputArgs(e);
}
1	#include "extmethod.h"
2
3	#include <stdexcept>
4	using namespace std;
5
6	#ifndef ASCXX_USE_PYTHON
7	# error "Where's ASCXX_USE_PYTHON?"
8	#endif
9
10	/*--- WARNING ---
11	In the C++ interface I'm trying to make the nomenclature
12	a bit more systematic. 'ExternalFunc' as listed end up
13	being things that you can call like 'asc_free_all_vars' --
14	they are effectively externally-defined methods on ASCEND
15	models, so I'll call then 'external methods'.
16
17	Meanwhile, external relations I will call 'ExtRelation'.
18
19	External functions, if ever implemented, will be for
20	functions like 'sin', 'exp', etc.
21	*/
22
23	ExtMethod::ExtMethod(const struct ExternalFunc *e) : e(e) {
24	// nothing else
25	}
26
27	ExtMethod::ExtMethod(const ExtMethod &old) : e(old.e) {
28	// nothing else
29	}
30
31	ExtMethod::ExtMethod(){
32	throw runtime_error("Can't create empty ExtMethod");
33	}
34
35	#ifdef ASCXX_USE_PYTHON
36	/**
37	Declare and register a new external script method from Python
38
39	@TODO not sure if this is the right place for this... problems when creating
40	the method might cause problems. Perhaps it should be in the 'library'
41	object instead?
42	*/
43	ExtMethod::ExtMethod(PyObject *obj){
44	CONSOLE_DEBUG("CREATING EXTERNAL PYTHON METHOD");
45
46	ExtMethodRun *runfn;
47	runfn = (ExtMethodRun *)importhandler_getsharedpointer("extpy.method");
48
49	CreateUserFunctionMethod("myextpyfn",runfn,0,"external python function",(void *)obj);
50	e = LookupExtFunc("myextpyfn");
51	}
52	#endif
53
54
55	const char *
56	ExtMethod::getName() const{
57	return ExternalFuncName(e);
58	}
59
60	const char *
61	ExtMethod::getHelp() const{
62	return e->help;
63	}
64
65	const unsigned long
66	ExtMethod::getNumInputs() const{
67	return NumberInputArgs(e);
68	}
69
70	const unsigned long
71	ExtMethod::getNumOutputs() const{
72	return NumberOutputArgs(e);
73	}