Hi,

Thanks for your reply

> I also reworked the interface again a year or two ago as part of an
> update to the Perl stuff, making a few key improvements, but I haven't
> ever committed these changes since I've never found time to thoroughly
> test the new Perl stuff. The main changes are: introduction of an
> iScriptValue interface for the storage of ints, floats and strings in
> the format of the scripting language, meaning we don't need loads of
> overloaded Call/Set/Get methods, and the printf-style format strings and
> variadic arguments in Call are replaced with a csRefArray<iScriptValue>.
> My new interfaces are here:
> http://www.crystalspace3d.org/tikiwiki/tiki-index.php?page=ScriptChanges
This is nice and would make a lot more sense.

> I know very little about Python, and I don't understand the relevance of
> the code snippets you included, with all the Python API calls in the
> main() function, but I'll comment on the rest of what you said.
Maybe I wasn't really clear enough. In my email I present 2 methods of
loading python code
1) Call a python file using an absolute path and put the functions in
the global namespace
2) Import python modules ala the current method
(LoadModule("foo.bar")), retaining the modules (maybe storing in the
iScript and using a hash map).

At the moment I'm tending towards second option, as you say having a
function to edit PYTHONPATH would be good :)

#include <Python.h>

int main()
{
  char *cstrret;

  Py_Initialize();

  // Load Python module
  PyObject *module = PyImport_ImportModule("amir.foofunc");

  // get foo function from module
  PyObject *foo = PyObject_GetAttrString(module, "foo");

  // build a tuple of your argument list
  PyObject *args = ...; // build value or whatever

  // call function, getting return object
  PyObject *return = PyEval_CallObject(foo, args);

  Py_Finalize();
  return 0;
}

With this approach either the user you do
iscript->LoadModuleObject("amir.foofunc") (different name to
LoadModule to preserve it), and then the iscript would either return
an iScriptModule, or store it internally (whichever we decide is
best).
Then when you do the
iscript->FindLoadedModule("amir.foofunc")->Call("foo", &i, 2, 8);

FindLoadModule(..) will do the lookup in iscript for a iScriptModule*
which corresponds to the module we loaded and stored earlier.

Alternatively LoadModuleObject could just return an iScriptModule, and
make it up to the user to store and use.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]

Reply via email to