Re: Boost.Python copyright issues

Maciej Sobczak <[email protected]> writes:

> Hi,
>
> David Abrahams wrote:
>
>>>Some time ago I've tried to use Boost.Python in one of the projects
>>>I was working on. It turned to be a source of frustration thanks to
>>>the fact that Python interpreter literally sits on global objects
>
>> I don't know what you mean by "sits on," but it is single-threaded.
>
> Consider the following Python signatures:
>
> PyAPI_FUNC(void) Py_Initialize(void);
> PyAPI_FUNC(void) Py_Finalize(void);
> PyAPI_FUNC(int) PyRun_SimpleString(const char *);
>
> and the following Tcl "equivalents":
>
> Tcl_Interp * Tcl_CreateInterp();
> void Tcl_DeleteInterp(Tcl_Interp *interp);
> int Tcl_Eval(Tcl_Interp *interp, char *script);
>
> (well, the above are not true function signatures, but macros which
> can be called as if they looked like this)
>
> Do you see the difference in pattern? ;)

Okay.

> The difference is that it is the global state that binds together
> *all* Python functions. It is the "this" pointer in Tcl, which
> provides encapsulation for each of multiple interpreters.

Right.  Lua follows the same pattern.

> As a result, I can call Tcl_CreateInterp thousand times, define
> different commands in each one, run thousand different scripts in each
> interpreter and collect thousand different responses, errors,
> exceptions or whatever else happens to be as the output.
> And I can interleave all these calls, which is still single-threaded
> activity. Not surprisingly, I can also exploit every interpreter in a
> separate thread in a multi-threaded application.
>
>>>and running multiple interpreters in a single process (possibly
>>>multithreaded) was somewhere between difficult and impossible.
>
>> I hear it's the former.
>
> Interesting.
> What will happen when one script sets the error (PyErr_SetString)? Can
> another script (in another interpreter) run without noticing it? 

IIUC, yes, but I'm not an expert in this department.  AFAIK, every
interpreter sees its own universe of objects.

> Can it also set its own error (another PyErr_SetString), so that I
> can examine each error separately?  

IIUC, yes.

> Is it possible to define separate sets of commands in different
> Python interpreters, but with the same command names, so that the
> scripts will not stumble one over another?

IIUC, yes.

> I needed these functionalities once and got frustrated with Python.

Understandable.  I hear using multiple interpreters in Python is
cumbersome.

>>>Since I'm also a bit of Tcl programmer, I decided to invest my time in
>>>the Open Source library that would have the same scope of application
>>> in Tcl as Boost.Python has in the Python world. 
>
>> Yet Another Spin-off.  Have you seen
>> http://www.boost-consulting.com/writing/oopsla04.html and
>> http://www.boost-consulting.com/writing/langbinding.ppt?
>
> Now I did. :)
>
> But I do not believe in it. Yes, I'm dead frank now.
> The differences between Python and Tcl are sooo big (and there are
> other scripting languages than just Python, Lua and Tcl) that building
> a common mechanism for all of them just cannot succeed. Of course, you
> *will* do it for Python, probably also for Lua, but I'm really
> pessimistic (kindly speaking) about covering Tcl this way.

Why do you think so?

> Tcl needs separate approach, for the reasons mentioned above

I don't think so; Langbinding was designed to account for those
particular reasons.  There may be others, of course.

> (I can already point out a couple of assumptions in
> Boost.Langbinding that cannot be sensibly implemented in Tcl).

Please do!

> On the other hand, Tcl is way much simpler than Python. For example, a
> function cannot differentiate its parameters between 7 and "7", so
> there is no way to implement function overloading (at least on the
> parameter type).

I have a hard time believing that *no* type information is available
at runtime.  If everything is a string in Tcl, you can at least parse
the strings to figure out types.

>>>The advantage is in the fact that Tcl interpreter is a heap-based
>>>object and one can have many of them in a single process
>
>> You can certainly do that with Python...
>
>>> either isolated from each other or connected in a hierarchy.  
>
>> ...although I really don't know about that.  What does it mean?
>
> Considering that I can create arbitrary (resources permitting) number
> of Tcl interpreters, it is a nice feature that I can declare one a
> slave of another and register command aliases from slave to master.
> Thanks to this, for example, I can have two interpreters in my application:
>
> - one evaluating my own, application scripts, with the set of commands
>   covering all parts of my app, including critical or dangerous stuff
> - another evaluating user-provided scripts, like editor macros
>
> I can declare the second as a slave of the first and create a couple
> of aliases, so that a selected set of commands executed by
> user-provided scripts will in fact execute in the master
> interpreter. 

Interesting.  Not that it affects the viability of langbinding, of
course ;-)

> This way I can provide kind of "firewall" for the critical parts of
> my application, so that user-provided scripts (for example, editor
> macros) cannot do much mess, but still being able to access the
> selected functionality.
>
> This is a very simple forwarding mechanism and therefore the
> master-slave hierarchy can be arbitrary big and deep.

Nifty.

>>>Is it OK for me to use the same code examples, when possible?
>
>> Sure, feel free!
>
> Thanks!
>
> I think that the cpptcl-1.0.0 will see the light within a couple of
> days. What is already in CVS is quite functional.

Sounds very cool.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8