Re: Re: Interest in luabind

[2003-06-18] David Abrahams wrote:

>
>Moving this to the C++-sig as it's a more appropriate forum...
>
>"dalwan01" <[email protected]> writes:
>
>>> Daniel Wallin <[email protected]> writes:
>>>
>>> > namespace_("foo")
>>> > [
>>> >    def(..),
>>> >    def(..)
>>> > ];
>>>
>>> I considered this syntax but I am not convinced it is an advantage.
>>> It seems to have quite a few downsides and no upsides.  Am I
>>> missing something?
>>
>> For us it has several upsides:
>>
>>   * We can easily nest namespaces
>
>IMO, it optimizes for the wrong case, since namespaces are typically flat
>rather than deeply nested (see the Zen of Python), nor are they
>represented explicitly in Python code, but inferred from file
>boundaries.

I must be atipical. I make heavy, nested, use of namespaces in my C++ code.
So having an easy way to represent that would be nice. 

>>   * We like the syntax :)
>
>It is nice for C++ programmers, but Python programmers at least are
>very much more comfortable without the brackets.
>
>>   * We can remove the lua_State* parameter from
>>     all calls to def()/class_()
>
>I'm not sure what that is.  We handle global state in Boost.Python by
>simply keeping track of the current module ("state") in a global
>variable.  Works a treat.

It's not global state. Unlike Python Lua can handle multiple "instances" of
an interpreter by keeping all the interpreter state in one object. So having
a single global var for that is not an option. It needs to get passed around
explicitly or implicitly. I imagine Lua is not the only interpreter that
does this. So it's something to consider carefully as we'll run into it
again (I fact if I remember correctly Java JNI does the same thing).

>> For us it doesn't seem like an option to dispatch the converters at
>> runtime, since performance is a really high priority for our users.
>
>What we're doing in Boost.Python turns out to be very efficient, well
>below the threshold that anyone would notice IIUC.  Eric Jones did a
>test comparing its speed to SWIG and to my great surprise,
>Boost.Python won.

It's a somewhat different audience that uses Lua. The kind of audience that
looks at the assembly generated to make sure it's efficient. People like
game developers, embeded developers, etc. so having a choice between compile
time and runtime they, and I, would choose compile time.

But perhaps the important thing about this is to consider how to support
both models.


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Wed, 18 Jun 2003 13:35:43 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1055958058 6670 80.91.224.249 (18 Jun 2003 17:40:58 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 18 Jun 2003 17:40:58 +0000 (UTC)
Original-X-From: [email protected] Wed Jun 18 19:40:56 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19Sgti-0001cq-00
	for <[email protected]>; Wed, 18 Jun 2003 19:39:03 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Sgtl-0007rs-00; Wed, 18 Jun 2003 13:39:05 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19SgtV-0007Xj-00
	for [email protected]; Wed, 18 Jun 2003 13:38:49 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19SgsF-0001Tt-00
	for <[email protected]>; Wed, 18 Jun 2003 19:37:31 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19Sgqs-0001M8-00
	for <[email protected]>; Wed, 18 Jun 2003 19:36:06 +0200
Original-Lines: 139
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:EGnoiyq58UrbmurZJohQAJ0WirQ=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:3
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3469
Lines: 139
X-Gnus-Newsgroup: langbinding-mbox:3   Sat Jul 19 11:05:35 2003

Rene Rivera <[email protected]> writes:

> [2003-06-18] David Abrahams wrote:
>
>>
>>Moving this to the C++-sig as it's a more appropriate forum...
>>
>>"dalwan01" <[email protected]> writes:
>>
>>>> Daniel Wallin <[email protected]> writes:
>>>>
>>>> > namespace_("foo")
>>>> > [
>>>> >    def(..),
>>>> >    def(..)
>>>> > ];
>>>>
>>>> I considered this syntax but I am not convinced it is an advantage.
>>>> It seems to have quite a few downsides and no upsides.  Am I
>>>> missing something?
>>>
>>> For us it has several upsides:
>>>
>>>   * We can easily nest namespaces
>>
>>IMO, it optimizes for the wrong case, since namespaces are typically flat
>>rather than deeply nested (see the Zen of Python), nor are they
>>represented explicitly in Python code, but inferred from file
>>boundaries.
>
> I must be atipical. I make heavy, nested, use of namespaces in my C++ code.
> So having an easy way to represent that would be nice. 
>
>>>   * We like the syntax :)
>>
>>It is nice for C++ programmers, but Python programmers at least are
>>very much more comfortable without the brackets.
>>
>>>   * We can remove the lua_State* parameter from
>>>     all calls to def()/class_()
>>
>>I'm not sure what that is.  We handle global state in Boost.Python by
>>simply keeping track of the current module ("state") in a global
>>variable.  Works a treat.
>
> It's not global state. Unlike Python Lua can handle multiple "instances" of
> an interpreter by keeping all the interpreter state in one object. 

Python can handle multiple interpreter instances too, but hardly
anyone does that.  In any case, it still seems to me to be a handle to
global state.

> So having a single global var for that is not an option. 

Why not?  I don't get it.  Normally any module's initialization code
will be operating on a single interpreter, right?  Why not store its
identity in a global variable?

> It needs to get passed around explicitly or implicitly. I imagine
> Lua is not the only interpreter that does this. So it's something to
> consider carefully as we'll run into it again (I fact if I remember
> correctly Java JNI does the same thing).

As long as modules don't initialize concurrently, I don't see how
there could be a problem.  Of course, if they *do* initialize
concurrently, everything I've said about the viability of globals is
wrong.  For that case you'd need TLS if you wanted to effectively hide
the state :(.

>>> For us it doesn't seem like an option to dispatch the converters at
>>> runtime, since performance is a really high priority for our users.
>>
>>What we're doing in Boost.Python turns out to be very efficient, well
>>below the threshold that anyone would notice IIUC.  Eric Jones did a
>>test comparing its speed to SWIG and to my great surprise,
>>Boost.Python won.
>
> It's a somewhat different audience that uses Lua. The kind of audience that
> looks at the assembly generated to make sure it's efficient. People like
> game developers, embeded developers, etc. 

<politically incorrect sweeping generalization>

That audience tends to be superstitious about cycles, rather than
measuring, and I think this concern is almost always misplaced when
applied at the boundary between interpreted and compiled languages.
The whole point of binding C++ into an interpreter, when you're
concerned with performance, is to capture a large chunk of
high-performance execution behind a single function call in the
interpreter.  I would think that once you are willing to use a
language like lua you're not going to be that parsimonious with the
execution of lua code adjacent to the call into C++, and it's easy for
an extra instruction or two in the interpreter to swamp the cost of
dynamic type conversion.  Furthermore, purely compile-time lookups can
have costs in code size, which is another important concern for this
audience.

</politically incorrect sweeping generalization>

> so having a choice between compile time and runtime they, and I,
> would choose compile time.  But perhaps the important thing about
> this is to consider how to support both models.

I know it can be a hard sell to that group, but I'd want to see some
convincing numbers before deciding to support both models.
Boost.Python used to use static converter lookups, but the advantages
of doing it dynamically are so huge that I'm highly reluctant to
complicate the codebase by supporting both without scientific
justification.

Oh, and BTW: I think people have vastly overestimated the amount of
avoidable dynamic lookup, and the amount of code actually executed in
the dynamic converter lookup.  There is no map indexing or anything
like that, except at the time the module is loaded, when references to
converter registry for each type are initialized.  The converter
registry for a given type generally contains only one converter (in
each direction), so there is no cost for searching for an appropriate
converter. When C++ classes are extracted from wrapped class objects,
a *static* procedure for finding the C++ class is tried before
consulting the registry.

Finally, if you care about derived <==> base class conversions (and I
think you do), there will always be some dynamic type manipulation
and/or RTTI, leading to some dynamic dispatching, because that's the
only way to implement it.

I am not trying to be difficult here.  If there are significant
technical advantages to purely-static converter lookups, I will be the
first to support the idea.  In all, however, I believe it's not an
accident that Boost.Python evolved from purely-static to a model which
supports dynamic conversions, not just because of usability concerns,
but also because of correctness and real efficiency.  So, let's keep
the conversation open, and try to hammer on it until we reach
consensus.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: "Ralf W. Grosse-Kunstleve" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Wed, 18 Jun 2003 10:51:42 -0700 (PDT)
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1055958850 11106 80.91.224.249 (18 Jun 2003 17:54:10 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 18 Jun 2003 17:54:10 +0000 (UTC)
Original-X-From: [email protected] Wed Jun 18 19:54:08 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19Sh7w-0002rc-00
	for <[email protected]>; Wed, 18 Jun 2003 19:53:44 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Sh7x-0005f0-00; Wed, 18 Jun 2003 13:53:45 -0400
Original-Received: from web20205.mail.yahoo.com ([216.136.226.60])
	by mail.python.org with smtp (Exim 4.05)
	id 19Sh5z-0005CL-00
	for [email protected]; Wed, 18 Jun 2003 13:51:44 -0400
Original-Received: from [12.208.26.202] by web20205.mail.yahoo.com via HTTP; Wed, 18 Jun 2003 10:51:42 PDT
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:4
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3472
Lines: 16
X-Gnus-Newsgroup: langbinding-mbox:4   Sat Jul 19 11:05:35 2003

--- David Abrahams <[email protected]> wrote:
> As long as modules don't initialize concurrently, I don't see how
> there could be a problem.  Of course, if they *do* initialize
> concurrently, everything I've said about the viability of globals is
> wrong.  For that case you'd need TLS if you wanted to effectively hide
> the state :(.

Excuse my ignorance, but what is TLS? Tender Loving S???
Thanks,
        Ralf


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: Rene Rivera <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Wed, 18 Jun 2003 12:58:32 -0500
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1055959653 15654 80.91.224.249 (18 Jun 2003 18:07:33 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 18 Jun 2003 18:07:33 +0000 (UTC)
Original-X-From: [email protected] Wed Jun 18 20:07:32 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19ShJq-0003vq-00
	for <[email protected]>; Wed, 18 Jun 2003 20:06:02 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19ShJt-0001md-00; Wed, 18 Jun 2003 14:06:05 -0400
Original-Received: from 42.muja.mlwk.chcgil24.dsl.att.net
	([12.100.89.42] helo=redshift-software.com ident=root)
	by mail.python.org with esmtp (Exim 4.05)
	id 19ShCf-00076Y-00
	for [email protected]; Wed, 18 Jun 2003 13:58:37 -0400
X-AuthUser: [email protected]
Original-Received: from 12.100.89.43 (12.100.89.43)
	by redshift-software.com with [XMail 1.12 (FreeBSD/Ix86) ESMTP Server]
	id <S11F99> for <[email protected]> from <[email protected]>;
	Wed, 18 Jun 2003 12:58:33 -0500
Original-To: [email protected]
X-Priority: 3
In-Reply-To: <[email protected]>
X-Mailer: Mailsmith 1.1.8 (Bluto)
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:5
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3474
Lines: 21
X-Gnus-Newsgroup: langbinding-mbox:5   Sat Jul 19 11:05:35 2003

[2003-06-18] Ralf W. Grosse-Kunstleve wrote:

>--- David Abrahams <[email protected]> wrote:
>> As long as modules don't initialize concurrently, I don't see how
>> there could be a problem.  Of course, if they *do* initialize
>> concurrently, everything I've said about the viability of globals is
>> wrong.  For that case you'd need TLS if you wanted to effectively hide
>> the state :(.
>
>Excuse my ignorance, but what is TLS? Tender Loving S???

Thread Local Storage.

>Thanks,

Welcome :-)


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: Rene Rivera <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Wed, 18 Jun 2003 13:13:46 -0500
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1055960108 18417 80.91.224.249 (18 Jun 2003 18:15:08 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 18 Jun 2003 18:15:08 +0000 (UTC)
Original-X-From: [email protected] Wed Jun 18 20:15:07 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19ShRc-0004eb-00
	for <[email protected]>; Wed, 18 Jun 2003 20:14:05 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19ShRf-0007in-00; Wed, 18 Jun 2003 14:14:07 -0400
Original-Received: from 42.muja.mlwk.chcgil24.dsl.att.net
	([12.100.89.42] helo=redshift-software.com ident=root)
	by mail.python.org with esmtp (Exim 4.05)
	id 19ShRM-0007cL-00
	for [email protected]; Wed, 18 Jun 2003 14:13:48 -0400
X-AuthUser: [email protected]
Original-Received: from 12.100.89.43 (12.100.89.43)
	by redshift-software.com with [XMail 1.12 (FreeBSD/Ix86) ESMTP Server]
	id <S11F9C> for <[email protected]> from <[email protected]>;
	Wed, 18 Jun 2003 13:13:47 -0500
Original-To: [email protected]
X-Priority: 3
In-Reply-To: <[email protected]>
X-Mailer: Mailsmith 1.1.8 (Bluto)
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:6
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3475
Lines: 142
X-Gnus-Newsgroup: langbinding-mbox:6   Sat Jul 19 11:05:35 2003

[2003-06-18] David Abrahams wrote:

>Rene Rivera <[email protected]> writes:
>
>> [2003-06-18] David Abrahams wrote:
>>
>>>
>>>Moving this to the C++-sig as it's a more appropriate forum...
>>>
>>>"dalwan01" <[email protected]> writes:
>>>
>>>>> Daniel Wallin <[email protected]> writes:
>>>>>
>>>>> > namespace_("foo")
>>>>> > [
>>>>> >    def(..),
>>>>> >    def(..)
>>>>> > ];
>>>>>
>>>>> I considered this syntax but I am not convinced it is an advantage.
>>>>> It seems to have quite a few downsides and no upsides.  Am I
>>>>> missing something?
>>>>
>>>> For us it has several upsides:
>>>>
>>>>   * We can easily nest namespaces
>>>
>>>IMO, it optimizes for the wrong case, since namespaces are typically flat
>>>rather than deeply nested (see the Zen of Python), nor are they
>>>represented explicitly in Python code, but inferred from file
>>>boundaries.
>>
>> I must be atipical. I make heavy, nested, use of namespaces in my C++
code.
>> So having an easy way to represent that would be nice. 
>>
>>>>   * We like the syntax :)
>>>
>>>It is nice for C++ programmers, but Python programmers at least are
>>>very much more comfortable without the brackets.
>>>
>>>>   * We can remove the lua_State* parameter from
>>>>     all calls to def()/class_()
>>>
>>>I'm not sure what that is.  We handle global state in Boost.Python by
>>>simply keeping track of the current module ("state") in a global
>>>variable.  Works a treat.
>>
>> It's not global state. Unlike Python Lua can handle multiple "instances"
of
>> an interpreter by keeping all the interpreter state in one object. 
>
>Python can handle multiple interpreter instances too, but hardly
>anyone does that.  In any case, it still seems to me to be a handle to
>global state.

Perhaps because Python has a higher interpreter cost? The thing is it's the
recomended way to do things in Lua.

>> So having a single global var for that is not an option. 
>
>Why not?  I don't get it.  Normally any module's initialization code
>will be operating on a single interpreter, right?  

No. The LuaState is the complete interpreter state. So to do bindings, or
anything else, you create the state for each context you are calling in.
There's no limitation as to matching the state to anything else other than
the calling context. For eaxmple I could create a set of states, say 20, and
have a pool of, say 50, threads that all "share" those on an as needed
basis. Something like this is in fact my current need for Lua.

>> It needs to get passed around explicitly or implicitly. I imagine
>> Lua is not the only interpreter that does this. So it's something to
>> consider carefully as we'll run into it again (I fact if I remember
>> correctly Java JNI does the same thing).
>
>As long as modules don't initialize concurrently, I don't see how
>there could be a problem.  Of course, if they *do* initialize
>concurrently, everything I've said about the viability of globals is
>wrong.  For that case you'd need TLS if you wanted to effectively hide
>the state :(.

Ah, well, there's the rub ;-) They can initialize concurrently. And to make
it more interesting the same state can be used by different threads (but not
at the same time) from time to time.

><politically incorrect sweeping generalization>

I hate politics ;-)

But yes measuring the performace is a requirement. The group in question
tends to resort to looking at the ASM only when they've run out of other
options to find out why their program is slow.

>> so having a choice between compile time and runtime they, and I,
>> would choose compile time.  But perhaps the important thing about
>> this is to consider how to support both models.
>
>I know it can be a hard sell to that group, but I'd want to see some
>convincing numbers before deciding to support both models.
>Boost.Python used to use static converter lookups, but the advantages
>of doing it dynamically are so huge that I'm highly reluctant to
>complicate the codebase by supporting both without scientific
>justification.
>
>Oh, and BTW: I think people have vastly overestimated the amount of
>avoidable dynamic lookup, and the amount of code actually executed in
>the dynamic converter lookup.  There is no map indexing or anything
>like that, except at the time the module is loaded, when references to
>converter registry for each type are initialized.  The converter
>registry for a given type generally contains only one converter (in
>each direction), so there is no cost for searching for an appropriate
>converter. When C++ classes are extracted from wrapped class objects,
>a *static* procedure for finding the C++ class is tried before
>consulting the registry.
>
>Finally, if you care about derived <==> base class conversions (and I
>think you do), there will always be some dynamic type manipulation
>and/or RTTI, leading to some dynamic dispatching, because that's the
>only way to implement it.
>
>I am not trying to be difficult here.  If there are significant
>technical advantages to purely-static converter lookups, I will be the
>first to support the idea.  In all, however, I believe it's not an
>accident that Boost.Python evolved from purely-static to a model which
>supports dynamic conversions, not just because of usability concerns,
>but also because of correctness and real efficiency.  So, let's keep
>the conversation open, and try to hammer on it until we reach
>consensus.

Being difficult is the point ;-) If there's no difficulty there's no
discussion.

OK, I'm bassically convinced with that argument. If the majority of the
lookups are O(1) then the extra cycles at runtime is worth the convenience.
I just worry about O(n) lookups at a junction point in a program. It tends
to poroduce O(n2) algos ;-)


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Wed, 18 Jun 2003 14:30:09 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1055961915 27695 80.91.224.249 (18 Jun 2003 18:45:15 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 18 Jun 2003 18:45:15 +0000 (UTC)
Original-X-From: [email protected] Wed Jun 18 20:45:13 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19Shtd-0006zw-00
	for <[email protected]>; Wed, 18 Jun 2003 20:43:01 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Shtg-0004S5-00; Wed, 18 Jun 2003 14:43:04 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19ShtA-0004MH-00
	for [email protected]; Wed, 18 Jun 2003 14:42:32 -0400
Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19Shqv-0006lz-00
	for <[email protected]>; Wed, 18 Jun 2003 20:40:13 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19ShhY-0005ys-00
	for <[email protected]>; Wed, 18 Jun 2003 20:30:32 +0200
Original-Lines: 108
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:mvLcd3lLhOf2pOg0NaBadzfxMeM=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:7
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3477
Lines: 108
X-Gnus-Newsgroup: langbinding-mbox:7   Sat Jul 19 11:05:35 2003

Rene Rivera <[email protected]> writes:

> [2003-06-18] David Abrahams wrote:
>
>>>>I'm not sure what that is.  We handle global state in Boost.Python by
>>>>simply keeping track of the current module ("state") in a global
>>>>variable.  Works a treat.
>>>
>>> It's not global state. Unlike Python Lua can handle multiple "instances" of
>>> an interpreter by keeping all the interpreter state in one object. 
>>
>>Python can handle multiple interpreter instances too, but hardly
>>anyone does that.  In any case, it still seems to me to be a handle
>>to global state.
>
> Perhaps because Python has a higher interpreter cost? 

I'm not really sure why.  What's an "interpreter cost?"

> The thing is it's the recomended way to do things in Lua.
>
>>> So having a single global var for that is not an option. 
>>
>>Why not?  I don't get it.  Normally any module's initialization code
>>will be operating on a single interpreter, right?
>
> No. The LuaState is the complete interpreter state. So to do bindings, or
> anything else, you create the state for each context you are calling
> in.

"Context", possibly meaning "module?"

If so, I still don't see a problem with using namespace-scope
variables in an anonymous namespace (for example).

> There's no limitation as to matching the state to anything else
> other than the calling context. For eaxmple I could create a set of
> states, say 20, and have a pool of, say 50, threads that all "share"
> those on an as needed basis. Something like this is in fact my
> current need for Lua.

Wow, cool and weird!  Why do you want 20 separate interpreters?

>>> It needs to get passed around explicitly or implicitly. I imagine
>>> Lua is not the only interpreter that does this. So it's something to
>>> consider carefully as we'll run into it again (I fact if I remember
>>> correctly Java JNI does the same thing).
>>
>>As long as modules don't initialize concurrently, I don't see how
>>there could be a problem.  Of course, if they *do* initialize
>>concurrently, everything I've said about the viability of globals is
>>wrong.  For that case you'd need TLS if you wanted to effectively hide
>>the state :(.
>
> Ah, well, there's the rub ;-) They can initialize concurrently. And
> to make it more interesting the same state can be used by different
> threads (but not at the same time) from time to time.

If the same module can be initialized simultaneously by two separate
interpreters, I can see that there might be a problem.  Of course, one
could put a mutex guard around the whole module initialization, but
the people who read the ASM would probably be upset with that.

>><politically incorrect sweeping generalization>
>
> I hate politics ;-)

Me too; it wasn't meant to be a political statement.  I was trying to
put the technical issues in perspective.

> But yes measuring the performace is a requirement. The group in
> question tends to resort to looking at the ASM only when they've run
> out of other options to find out why their program is slow.

Maybe this is a different group from the one that invented EC++
because "namespaces and templates have negative performance impact."
;-)

>>I am not trying to be difficult here.  If there are significant
>>technical advantages to purely-static converter lookups, I will be the
>>first to support the idea.  In all, however, I believe it's not an
>>accident that Boost.Python evolved from purely-static to a model which
>>supports dynamic conversions, not just because of usability concerns,
>>but also because of correctness and real efficiency.  So, let's keep
>>the conversation open, and try to hammer on it until we reach
>>consensus.
>
> Being difficult is the point ;-) If there's no difficulty there's no
> discussion.
>
> OK, I'm bassically convinced with that argument. If the majority of the
> lookups are O(1) then the extra cycles at runtime is worth the
> convenience.

They are.  Furthermore, to-python conversions for specific known
types can be fixed at compile-time.

> I just worry about O(n) lookups at a junction point in a program. It tends
> to poroduce O(n2) algos ;-)

When n != 1 it's usually 0 or 2.  As long as you're not nervous about
everything that calls through a function pointer I think we're OK.
Let's see what the luabind guys think.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: Rene Rivera <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Wed, 18 Jun 2003 16:18:14 -0500
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1055971146 12154 80.91.224.249 (18 Jun 2003 21:19:06 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 18 Jun 2003 21:19:06 +0000 (UTC)
Original-X-From: [email protected] Wed Jun 18 23:19:04 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19SkKe-00039p-00
	for <[email protected]>; Wed, 18 Jun 2003 23:19:04 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19SkKg-0000k0-00; Wed, 18 Jun 2003 17:19:06 -0400
Original-Received: from 42.muja.mlwk.chcgil24.dsl.att.net
	([12.100.89.42] helo=redshift-software.com ident=root)
	by mail.python.org with esmtp (Exim 4.05)
	id 19SkJs-0000b9-00
	for [email protected]; Wed, 18 Jun 2003 17:18:16 -0400
X-AuthUser: [email protected]
Original-Received: from 12.100.89.43 (12.100.89.43)
	by redshift-software.com with [XMail 1.12 (FreeBSD/Ix86) ESMTP Server]
	id <S11FBA> for <[email protected]> from <[email protected]>;
	Wed, 18 Jun 2003 16:18:14 -0500
Original-To: [email protected]
X-Priority: 3
In-Reply-To: <[email protected]>
X-Mailer: Mailsmith 1.1.8 (Bluto)
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:8
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3488
Lines: 84
X-Gnus-Newsgroup: langbinding-mbox:8   Sat Jul 19 11:05:35 2003

[2003-06-18] David Abrahams wrote:

>Rene Rivera <[email protected]> writes:
>
>> [2003-06-18] David Abrahams wrote:
>>
>>>Python can handle multiple interpreter instances too, but hardly
>>>anyone does that.  In any case, it still seems to me to be a handle
>>>to global state.
>>
>> Perhaps because Python has a higher interpreter cost? 
>
>I'm not really sure why.  What's an "interpreter cost?"

The time and space required to initialize/create a context sufficient for
executing some scripted code independent of any other such context.

>> The thing is it's the recomended way to do things in Lua.
>>
>>>> So having a single global var for that is not an option. 
>>>
>>>Why not?  I don't get it.  Normally any module's initialization code
>>>will be operating on a single interpreter, right?
>>
>> No. The LuaState is the complete interpreter state. So to do bindings, or
>> anything else, you create the state for each context you are calling
>> in.
>
>"Context", possibly meaning "module?"

No I meant execution context in this case. As in that of a thread. Hence my
use case below.

>If so, I still don't see a problem with using namespace-scope
>variables in an anonymous namespace (for example).
>
>> There's no limitation as to matching the state to anything else
>> other than the calling context. For eaxmple I could create a set of
>> states, say 20, and have a pool of, say 50, threads that all "share"
>> those on an as needed basis. Something like this is in fact my
>> current need for Lua.
>
>Wow, cool and weird!  Why do you want 20 separate interpreters?

Because they may be 20 separate Lua scripts running at a time. My current
product has the ability for users to specificy script code that runs on the
server. And the server can have some bounded set of execution threads to
handle the actions. But only a subset of those will be executing script
code.

Here's a comparable use case. Imagine you want to make it possible to write
scripting capabilities to a web server. It runs a varying number of threads
to handle client requests any of which can possibly run some script code. So
you write up a common interpreter state pool, just like you have a thread
pool. If a thread needs to execute some script code it grabs one of the
interpreter state objects and calls the interpreter code with the state and
the script.

>> Ah, well, there's the rub ;-) They can initialize concurrently. And
>> to make it more interesting the same state can be used by different
>> threads (but not at the same time) from time to time.
>
>If the same module can be initialized simultaneously by two separate
>interpreters, I can see that there might be a problem.  Of course, one
>could put a mutex guard around the whole module initialization, but
>the people who read the ASM would probably be upset with that.

<caveat>
I'm talking Lua4 here so my info may be outdated. I know there's some new
stuff to handle sharing of state. I'll look into the luabind code to see how
it's doing things.
</caveat>

If one needs for script code to execute concurrently then one has to
initialize the modules into (clasic idea of intern) each interpreter state.
So if requiring that all such initializations execute serialy solves the
problem, that's fine IMO. Unless the people who read the ASM intend to do
initializations all the time they can live with the mutex. After all in such
cases you pool those initilizations ahead of time as I mentioned above. 


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: "Joel de Guzman" <[email protected]>
Newsgroups: gmane.comp.python.c++,gmane.comp.lib.boost.devel
Subject: Re: Re: Interest in luabind
Date: Wed, 18 Jun 2003 23:15:58 +0800
Sender: [email protected]
Approved: [email protected]
Message-ID: <067c01c335af$bbc896e0$0100a8c0@godzilla>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1055951210 28486 80.91.224.249 (18 Jun 2003 15:46:50 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 18 Jun 2003 15:46:50 +0000 (UTC)
Cc: <[email protected]>
Original-X-From: [email protected] Wed Jun 18 17:46:48 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19Sf3o-0006yp-00
	for <[email protected]>; Wed, 18 Jun 2003 17:41:20 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Sf3j-0001VE-00; Wed, 18 Jun 2003 11:41:15 -0400
Original-Received: from mail.gmx.net ([213.165.64.20])
	by mail.python.org with smtp (Exim 4.05)
	id 19Sf26-00018T-00
	for [email protected]; Wed, 18 Jun 2003 11:39:34 -0400
Original-Received: (qmail 2205 invoked by uid 65534); 18 Jun 2003 15:39:02 -0000
Original-Received: from unknown (EHLO godzilla) (202.69.166.35)
  by mail.gmx.net (mp025) with SMTP; 18 Jun 2003 17:39:02 +0200
Original-To: <[email protected]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:9
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3466
Lines: 18
X-Gnus-Newsgroup: langbinding-mbox:9   Sat Jul 19 11:05:35 2003

David Abrahams wrote:

[ snip [] syntax ]

>>   * We like the syntax :)
> 
> It is nice for C++ programmers, but Python programmers at least are
> very much more comfortable without the brackets.

FWIW, I like the syntax ;-)
But then of course I'm biased :o)

Regards,
-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: "dalwan01" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu, 19 Jun 2003 11:55:35 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056020167 2348 80.91.224.249 (19 Jun 2003 10:56:07 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 19 Jun 2003 10:56:07 +0000 (UTC)
Original-X-From: [email protected] Thu Jun 19 12:56:05 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19Sx5J-0000bg-00
	for <[email protected]>; Thu, 19 Jun 2003 12:56:05 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Sx5K-0008Np-00; Thu, 19 Jun 2003 06:56:06 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Sx4r-0008Kv-00
	for [email protected]; Thu, 19 Jun 2003 06:55:37 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5JAtZFM038178;
	Thu, 19 Jun 2003 12:55:36 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:10
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3491
Lines: 200
X-Gnus-Newsgroup: langbinding-mbox:10   Sat Jul 19 11:05:35 2003

>
> Moving this to the C++-sig as it's a more appropriate
> forum...
>
> "dalwan01" <[email protected]> writes:
>
> >> Daniel Wallin <[email protected]> writes:
> >>
> >> > At 18:03 2003-06-17, you wrote:
> >>
> >>http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/16
> 73338 is
> >> >>more recent and also relevant to your question.
> >> >>
> >> >>In short, I'd love to see luabind in Boost, and I'd
> hate to see
> >> >>it happen without substantial code sharing with
> Boost.Python.
> >> >
> >> > I agree. It seems like a lot of code could be shared.
>  For
> >> > instance, the conversion system between
> base<->derived should
> >> > work exactly the same and we could probably plug in
> BPL's system
> >> > for this without much trouble.
> >> >
> >> > It would also be really nice if we could share most
> of the
> >> > front-end code (declaration of scopes, classes and
> functions).
> >> >
> >> > Note however that there are quite a few differences
> in design,
> >> > for instance for our scope's we have been
> experimenting with
> >> > expressions ala phoenix:
> >> >
> >> > namespace_("foo")
> >> > [
> >> >    def(..),
> >> >    def(..)
> >> > ];
> >>
> >> I considered this syntax but I am not convinced it is
> an advantage.
> >> It seems to have quite a few downsides and no upsides.
> Am I
> >> missing something?
> >
> > For us it has several upsides:
> >
> >   * We can easily nest namespaces
>
> IMO, it optimizes for the wrong case, since namespaces are
> typically flat
> rather than deeply nested (see the Zen of Python), nor are
> they
> represented explicitly in Python code, but inferred from
> file
> boundaries.
>
> >   * We like the syntax :)
>
> It is nice for C++ programmers, but Python programmers at
> least are
> very much more comfortable without the brackets.


>
> >   * We can remove the lua_State* parameter from
> >     all calls to def()/class_()
>
> I'm not sure what that is.  We handle global state in
> Boost.Python by
> simply keeping track of the current module ("state") in a
> global
> variable.  Works a treat.

As pointed out lua can handle multiple states, so using
global variabels doesn't strike me as a very good solution.

>
> > What do you consider the downsides to be?
>
> In addition to what I cited above,
>
> a. since methods and module-scope functions need to be
> wrapped
>    differently, you need to build up a data structure
> which stores the
>    arguments to def(...) out of the comma-separated items
> with a
>    complex expression-template type and then interpret
> that type using
>    a metaprogram when the operator[]s are applied.  This
> can only
>    increase compile times, which is already a problem.

We don't build a complex expression-template, instead we
build a list of objects with a virtual method to commit that
object to the lua_State. This doesn't increase compile
times.

>
> b. You don't get any order-of-evaluation guarantees.
> Things like
>    staticmethod() need to operate on an existing function
> object in the
>    class' dictionary
>
> [http://www.boost.org/libs/python/doc/v2/class.html#class_
> -spec-modifiers]
>    and if you can't guarantee that it gets executed after
> a def()
>    call you need to further complicate your expression
> template to
>    delay evaluation of staticmethod()

As we don't build a expression template, I don't think this
is an issue.

>
> I guess these two are essentially the same issue.
>
> >> > Also, we don't have a type-converter registry; we
> make all
> >> > choices on what converter to use at compile time.
> >>
> >> I used to do that, but it doesn't support
> >> component-based-development has other serious problems.
>  Are you
> >> sure your code is actually conformant?  When converters
> are
> >> determined at compile-time, the only viable and
> conformant way
> >> AFAICT is with template specializations, and that means
> clients
> >> have to be highly conscious of ordering issues.
> >
> > I think it's conformant, but I wouldn't swear on it.
> > We strip all qualifiers from the types and specialize on
> >
> >   by_cref<..>
> >   by_ref<..>
> >   by_ptr<..>
> >   by_value<..>
> >
> > types.
>
> How do people define specialized converters for particular
> types?

This isn't finished, but currently we do:

yes_t is_user_defined(by_cref<my_type>);
my_type convert_from_lua(lua_State*, by_cref<my_type>);

something like that..

>
> > It works on all compilers we have tried it on (vc 6-7.1,
> > codewarrior, gcc2.95.3+, intel).
>
> Codewarrior Pro8.x, explicitly using the '-iso-templates
> on' option?
> All the others support several common nonconformance bugs,
> many of
> which I was exploiting in Boost.Python v1.

I haven't tried with -iso- option, I'll try it when i get
home. We do not however use the bug you where exploiting i
bpl.v1 (i assume you are referreing to friend templates?).

>
> > For us it doesn't seem like an option to dispatch the
> converters at
> > runtime, since performance is a really high priority for
> our users.
>
> What we're doing in Boost.Python turns out to be very
> efficient, well
> below the threshold that anyone would notice IIUC.  Eric
> Jones did a
> test comparing its speed to SWIG and to my great surprise,
> Boost.Python won.

Lua is used a lot in game developement, and game developers
tend to care very much about every extra cycle. Even an
extra function call via a function pointer could make
difference for those users.

We like the generated bindings to be almost equal in speed
to one that is hand written.

(sorry for my late reply, my home connection is down for two
weeks..)

--
Daniel Wallin
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Thu, 19 Jun 2003 08:04:23 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056024366 21734 80.91.224.249 (19 Jun 2003 12:06:06 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 19 Jun 2003 12:06:06 +0000 (UTC)
Original-X-From: [email protected] Thu Jun 19 14:06:02 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19SyB0-0005e2-00
	for <[email protected]>; Thu, 19 Jun 2003 14:06:02 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19SyB3-0000Vp-00; Thu, 19 Jun 2003 08:06:05 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19SyAQ-0000Rb-00
	for [email protected]; Thu, 19 Jun 2003 08:05:26 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19Sy9y-0005Yr-00
	for <[email protected]>; Thu, 19 Jun 2003 14:04:58 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19Sy9n-0005Xn-00
	for <[email protected]>; Thu, 19 Jun 2003 14:04:47 +0200
Original-Lines: 184
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:GYEUQk18paKzMPtLk7lIdrRNPqk=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:11
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3494
Lines: 184
X-Gnus-Newsgroup: langbinding-mbox:11   Sat Jul 19 11:05:35 2003

"dalwan01" <[email protected]> writes:

>>
>> Moving this to the C++-sig as it's a more appropriate
>> forum...
>>
>> "dalwan01" <[email protected]> writes:
>>
>> >> Daniel Wallin <[email protected]> writes:
>> >>
>> >> > Note however that there are quite a few differences in design,
>> >> > for instance for our scope's we have been experimenting with
>> >> > expressions ala phoenix:
>> >> >
>> >> > namespace_("foo")
>> >> > [
>> >> >    def(..),
>> >> >    def(..)
>> >> > ];
>> >>
>> >> I considered this syntax but I am not convinced it is an advantage.
>> >> It seems to have quite a few downsides and no upsides. Am I
>> >> missing something?
>> >
>> > For us it has several upsides:
>> >
>> >   * We can easily nest namespaces
>>
>> IMO, it optimizes for the wrong case, since namespaces are
>> typically flat rather than deeply nested (see the Zen of Python),
>> nor are they represented explicitly in Python code, but inferred
>> from file boundaries.
>>
>> >   * We like the syntax :)
>>
>> It is nice for C++ programmers, but Python programmers at least are
>> very much more comfortable without the brackets.
>
>
>>
>> >   * We can remove the lua_State* parameter from
>> >     all calls to def()/class_()
>>
>> I'm not sure what that is.  We handle global state in Boost.Python
>> by simply keeping track of the current module ("state") in a global
>> variable.  Works a treat.
>
> As pointed out lua can handle multiple states, so using
> global variabels doesn't strike me as a very good solution.

I am not committed to the global variable approach nor am I opposed
to the syntax.

>> > What do you consider the downsides to be?
>>
>> In addition to what I cited above,
>>
>> a. since methods and module-scope functions need to be wrapped
>> differently, you need to build up a data structure which stores the
>> arguments to def(...) out of the comma-separated items with a
>> complex expression-template type and then interpret that type using
>> a metaprogram when the operator[]s are applied.  This can only
>> increase compile times, which is already a problem.
>
> We don't build a complex expression-template, instead we
> build a list of objects with a virtual method to commit that
> object to the lua_State. 

Very nice solution!  My brain must have been trapped into thinking
"compile-time".

> This doesn't increase compile times.

Good.  Virtual functions come with bloat of their own, but that's an
implementation detail which can be mitigated.

>> b. You don't get any order-of-evaluation guarantees.
>> Things like
>>    staticmethod() need to operate on an existing function
>> object in the
>>    class' dictionary
>>
>> [http://www.boost.org/libs/python/doc/v2/class.html#class_
>> -spec-modifiers]
>>    and if you can't guarantee that it gets executed after
>> a def()
>>    call you need to further complicate your expression
>> template to
>>    delay evaluation of staticmethod()
>
> As we don't build a expression template, I don't think this
> is an issue.

Actually I think it's a non-issue because you *do* build a
runtime-bound version of an expression template.

>> I guess these two are essentially the same issue.
>>
>> >> > Also, we don't have a type-converter registry; we make all
>> >> > choices on what converter to use at compile time.
>> >>
>> >> I used to do that, but it doesn't support
>> >> component-based-development has other serious problems.  Are you
>> >> sure your code is actually conformant?  When converters are
>> >> determined at compile-time, the only viable and conformant way
>> >> AFAICT is with template specializations, and that means clients
>> >> have to be highly conscious of ordering issues.
>> >
>> > I think it's conformant, but I wouldn't swear on it.
>> > We strip all qualifiers from the types and specialize on
>> >
>> >   by_cref<..>
>> >   by_ref<..>
>> >   by_ptr<..>
>> >   by_value<..>
>> >
>> > types.

I'm not really sure what the above means yet... I'm certainly
interested in avoiding runtime dispatching if possible, so if this
approach is viable for Boost.Python I'm all for it.

>>
>> How do people define specialized converters for particular
>> types?
>
> This isn't finished, but currently we do:
>
> yes_t is_user_defined(by_cref<my_type>);
> my_type convert_from_lua(lua_State*, by_cref<my_type>);
>
> something like that..

I assume that means the user must define those two functions?  Where
in the code must they be defined?

How will this work when multiple extension modules need to manipulate
the same types?

How do *add* a way to convert from Python type A to C++ type B
without masking the existing conversion from Python type Y to C++
type Z?

>> > It works on all compilers we have tried it on (vc 6-7.1,
>> > codewarrior, gcc2.95.3+, intel).
>>
>> Codewarrior Pro8.x, explicitly using the '-iso-templates on'
>> option?  All the others support several common nonconformance bugs,
>> many of which I was exploiting in Boost.Python v1.
>
> I haven't tried with -iso- option, I'll try it when i get home. We
> do not however use the bug you where exploiting i bpl.v1 (i assume
> you are referreing to friend templates?).

No, friend functions declared in templates being found without Koenig
Lookup.

>> > For us it doesn't seem like an option to dispatch the converters at
>> > runtime, since performance is a really high priority for our users.
>>
>> What we're doing in Boost.Python turns out to be very efficient,
>> well below the threshold that anyone would notice IIUC.  Eric Jones
>> did a test comparing its speed to SWIG and to my great surprise,
>> Boost.Python won.
>
> Lua is used a lot in game developement, and game developers tend to
> care very much about every extra cycle. Even an extra function call
> via a function pointer could make difference for those users.

I'm not convinced yet.  Just adding a tiny bit of lua code next to any
invocation of a wrapped function would typically consume much more
than that.

> We like the generated bindings to be almost equal in speed to one
> that is hand written.

Me too; I just have serious doubts that once you factor in everything
else that you want going on (e.g. derived <==> base conversions), the
ability to dynamically register conversions has a significant cost.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: "dalwan01" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu, 19 Jun 2003 12:23:38 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056021845 9949 80.91.224.249 (19 Jun 2003 11:24:05 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 19 Jun 2003 11:24:05 +0000 (UTC)
Original-X-From: [email protected] Thu Jun 19 13:24:02 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19SxWM-0002aF-00
	for <[email protected]>; Thu, 19 Jun 2003 13:24:02 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19SxWP-0002jr-00; Thu, 19 Jun 2003 07:24:05 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19SxW0-0002jh-00
	for [email protected]; Thu, 19 Jun 2003 07:23:40 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5JBNcFM069137;
	Thu, 19 Jun 2003 13:23:38 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:12
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3492
Lines: 125
X-Gnus-Newsgroup: langbinding-mbox:12   Sat Jul 19 11:05:35 2003

> Rene Rivera <[email protected]> writes:
>
> > [2003-06-18] David Abrahams wrote:
> >
> >>>>I'm not sure what that is.  We handle global state in
> Boost.Python by
> >>>>simply keeping track of the current module ("state")
> in a global
> >>>>variable.  Works a treat.
> >>>
> >>> It's not global state. Unlike Python Lua can handle
> multiple "instances" of
> >>> an interpreter by keeping all the interpreter state in
> one object.
> >>
> >>Python can handle multiple interpreter instances too,
> but hardly
> >>anyone does that.  In any case, it still seems to me to
> be a handle
> >>to global state.
> >
> > Perhaps because Python has a higher interpreter cost?
>
> I'm not really sure why.  What's an "interpreter cost?"
>
> > The thing is it's the recomended way to do things in
> Lua.
> >
> >>> So having a single global var for that is not an
> option.
> >>
> >>Why not?  I don't get it.  Normally any module's
> initialization code
> >>will be operating on a single interpreter, right?
> >
> > No. The LuaState is the complete interpreter state. So
> to do bindings, or
> > anything else, you create the state for each context you
> are calling
> > in.
>
> "Context", possibly meaning "module?"
>
> If so, I still don't see a problem with using
> namespace-scope
> variables in an anonymous namespace (for example).

If the choice is between:

namespace_(..)
[
  def(..),
  def(..)
];

and

{
  namespace_ local_ns(..);

  def(state, ..);
  def(state, ..);
}

I would prefer the first as it is both more readable and
less verbose.

> >>I am not trying to be difficult here.  If there are
> significant
> >>technical advantages to purely-static converter lookups,
> I will be the
> >>first to support the idea.  In all, however, I believe
> it's not an
> >>accident that Boost.Python evolved from purely-static to
> a model which
> >>supports dynamic conversions, not just because of
> usability concerns,
> >>but also because of correctness and real efficiency.
> So, let's keep
> >>the conversation open, and try to hammer on it until we
> reach
> >>consensus.
> >
> > Being difficult is the point ;-) If there's no
> difficulty there's no
> > discussion.
> >
> > OK, I'm bassically convinced with that argument. If the
> majority of the
> > lookups are O(1) then the extra cycles at runtime is
> worth the
> > convenience.
>
> They are.  Furthermore, to-python conversions for specific
> known
> types can be fixed at compile-time.

How can they be fixed at compile-time? Doesn't this mean
bypassing the conversion system and not allowing multiple
converters / type?

>
> > I just worry about O(n) lookups at a junction point in a
> program. It tends
> > to poroduce O(n2) algos ;-)
>
> When n != 1 it's usually 0 or 2.  As long as you're not
> nervous about
> everything that calls through a function pointer I think
> we're OK.
> Let's see what the luabind guys think.

Some people would indeed get nervous by that. :) It isn't so
much about the complexity as the additional cache misses and
branch mispreditions introduced by lists of converters and
calls through functions pointers.

I realise this sounds silly, but when developing on a
console these are important issues.

I don't really have any numbers on this, and we would really
need those.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Thu, 19 Jun 2003 08:12:18 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056024953 24300 80.91.224.249 (19 Jun 2003 12:15:53 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 19 Jun 2003 12:15:53 +0000 (UTC)
Original-X-From: [email protected] Thu Jun 19 14:15:52 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19SyJg-0006G6-00
	for <[email protected]>; Thu, 19 Jun 2003 14:15:00 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19SyJk-0001cq-00; Thu, 19 Jun 2003 08:15:04 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19SyIp-0001P1-00
	for [email protected]; Thu, 19 Jun 2003 08:14:07 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19SyI4-0006A3-00
	for <[email protected]>; Thu, 19 Jun 2003 14:13:20 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19SyHQ-000678-00
	for <[email protected]>; Thu, 19 Jun 2003 14:12:40 +0200
Original-Lines: 22
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:Ksg+6BZQhCE6iw/AGipAjNz7t3s=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:13
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3495
Lines: 22
X-Gnus-Newsgroup: langbinding-mbox:13   Sat Jul 19 11:05:35 2003

"dalwan01" <[email protected]> writes:

Abrahams:

>> They are.  Furthermore, to-python conversions for specific known
>> types can be fixed at compile-time.
>
> How can they be fixed at compile-time? Doesn't this mean
> bypassing the conversion system and not allowing multiple
> converters / type?

Given that when converting from C++ to Python, you only have a C++
type to work with and no Python type, there really can only be a
single way to do the conversion anyhow.  Given a to-python converter
for a given C++ type, there's no criterion by which to say, "this
converter doesn't match; try another"... unless of course you inspect
the value of the C++ object, but I don't allow that.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Thu, 19 Jun 2003 08:14:38 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056025284 25678 80.91.224.249 (19 Jun 2003 12:21:24 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 19 Jun 2003 12:21:24 +0000 (UTC)
Original-X-From: [email protected] Thu Jun 19 14:21:22 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19SyPU-0006ed-00
	for <[email protected]>; Thu, 19 Jun 2003 14:21:00 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19SyPZ-0001wh-00; Thu, 19 Jun 2003 08:21:05 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19SyPQ-0001wS-00
	for [email protected]; Thu, 19 Jun 2003 08:20:56 -0400
Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19SyOb-0006bs-00
	for <[email protected]>; Thu, 19 Jun 2003 14:20:05 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19SyJh-0006GF-00
	for <[email protected]>; Thu, 19 Jun 2003 14:15:01 +0200
Original-Lines: 19
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:vDN1dzw5gkKpw+2mrGDJsM6ijaQ=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:14
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3496
Lines: 19
X-Gnus-Newsgroup: langbinding-mbox:14   Sat Jul 19 11:05:35 2003

"dalwan01" <[email protected]> writes:

>> When n != 1 it's usually 0 or 2.  As long as you're not nervous
>> about everything that calls through a function pointer I think
>> we're OK.  Let's see what the luabind guys think.
>
> Some people would indeed get nervous by that. :) 
> It isn't so much about the complexity as the additional cache misses
> and branch mispreditions introduced by lists of converters and calls
> through functions pointers.

I know but I think they're superstitious, at least in the context of
bindings to a dynamic language where *everything* goes through
function pointers.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:35 2003
Path: main.gmane.org!not-for-mail
From: "dalwan01" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu, 19 Jun 2003 15:48:16 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056034224 10490 80.91.224.249 (19 Jun 2003 14:50:24 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 19 Jun 2003 14:50:24 +0000 (UTC)
Original-X-From: [email protected] Thu Jun 19 16:50:19 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19T0il-0002eL-00
	for <[email protected]>; Thu, 19 Jun 2003 16:49:03 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19T0im-0006Yf-00; Thu, 19 Jun 2003 10:49:04 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19T0i3-0005Hx-00
	for [email protected]; Thu, 19 Jun 2003 10:48:19 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5JEmHFM076010;
	Thu, 19 Jun 2003 16:48:17 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:15
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3498
Lines: 250
X-Gnus-Newsgroup: langbinding-mbox:15   Sat Jul 19 11:05:35 2003

> "dalwan01" <[email protected]> writes:
>
> >>
> >> Moving this to the C++-sig as it's a more appropriate
> >> forum...
> >>
> >> "dalwan01" <[email protected]> writes:
> >>
> >> >> Daniel Wallin <[email protected]> writes:
> >> >>
> >> >> > Note however that there are quite a few
> differences in design,
> >> >> > for instance for our scope's we have been
> experimenting with
> >> >> > expressions ala phoenix:
> >> >> >
> >> >> > namespace_("foo")
> >> >> > [
> >> >> >    def(..),
> >> >> >    def(..)
> >> >> > ];
> >> >>
> >> >> I considered this syntax but I am not convinced it
> is an advantage.
> >> >> It seems to have quite a few downsides and no
> upsides. Am I
> >> >> missing something?
> >> >
> >> > For us it has several upsides:
> >> >
> >> >   * We can easily nest namespaces
> >>
> >> IMO, it optimizes for the wrong case, since namespaces
> are
> >> typically flat rather than deeply nested (see the Zen
> of Python),
> >> nor are they represented explicitly in Python code, but
> inferred
> >> from file boundaries.
> >>
> >> >   * We like the syntax :)
> >>
> >> It is nice for C++ programmers, but Python programmers
> at least are
> >> very much more comfortable without the brackets.
> >
> >
> >>
> >> >   * We can remove the lua_State* parameter from
> >> >     all calls to def()/class_()
> >>
> >> I'm not sure what that is.  We handle global state in
> Boost.Python
> >> by simply keeping track of the current module ("state")
> in a global
> >> variable.  Works a treat.
> >
> > As pointed out lua can handle multiple states, so using
> > global variabels doesn't strike me as a very good
> solution.
>
> I am not committed to the global variable approach nor am
> I opposed
> to the syntax.
>
> >> > What do you consider the downsides to be?
> >>
> >> In addition to what I cited above,
> >>
> >> a. since methods and module-scope functions need to be
> wrapped
> >> differently, you need to build up a data structure
> which stores the
> >> arguments to def(...) out of the comma-separated items
> with a
> >> complex expression-template type and then interpret
> that type using
> >> a metaprogram when the operator[]s are applied.  This
> can only
> >> increase compile times, which is already a problem.
> >
> > We don't build a complex expression-template, instead we
> > build a list of objects with a virtual method to commit
> that
> > object to the lua_State.
>
> Very nice solution!  My brain must have been trapped into
> thinking
> "compile-time".
>
> > This doesn't increase compile times.
>
> Good.  Virtual functions come with bloat of their own, but
> that's an
> implementation detail which can be mitigated.

Right. The virtual functions isn't generated in the
template, so there is very little code generated.

>
> >> I guess these two are essentially the same issue.
> >>
> >> >> > Also, we don't have a type-converter registry; we
> make all
> >> >> > choices on what converter to use at compile time.
> >> >>
> >> >> I used to do that, but it doesn't support
> >> >> component-based-development has other serious
> problems.  Are you
> >> >> sure your code is actually conformant?  When
> converters are
> >> >> determined at compile-time, the only viable and
> conformant way
> >> >> AFAICT is with template specializations, and that
> means clients
> >> >> have to be highly conscious of ordering issues.
> >> >
> >> > I think it's conformant, but I wouldn't swear on it.
> >> > We strip all qualifiers from the types and specialize
> on
> >> >
> >> >   by_cref<..>
> >> >   by_ref<..>
> >> >   by_ptr<..>
> >> >   by_value<..>
> >> >
> >> > types.
>
> I'm not really sure what the above means yet... I'm
> certainly
> interested in avoiding runtime dispatching if possible, so
> if this
> approach is viable for Boost.Python I'm all for it.

I don't know if i fully understand the ordering issues you
mentioned. When we first implemented this we had converter
functions with this sig:

T convert(type<T>, ..)

This of course introduces problems with some compilers when
trying to overload for T& and T* and such. So we introduced
a more complex type<..>.. T& -> by_ref<T>, const T& ->
by_cref<T> etc.

>
> >>
> >> How do people define specialized converters for
> particular
> >> types?
> >
> > This isn't finished, but currently we do:
> >
> > yes_t is_user_defined(by_cref<my_type>);
> > my_type convert_from_lua(lua_State*, by_cref<my_type>);
> >
> > something like that..
>
> I assume that means the user must define those two
> functions?  Where
> in the code must they be defined?

Right. The user declares the first function and defines the
other before binding functions that use the types.

>
> How will this work when multiple extension modules need to
> manipulate
> the same types?

I don't know. I haven't given that much thought. Do you see
any obvious issues?

>
> How do *add* a way to convert from Python type A to C++
> type B
> without masking the existing conversion from Python type Y
> to C++
> type Z?

I don't understand. How are B and Z related? Why would a
conversion function for B mask conversions to Z?

>
> >> > It works on all compilers we have tried it on (vc
> 6-7.1,
> >> > codewarrior, gcc2.95.3+, intel).
> >>
> >> Codewarrior Pro8.x, explicitly using the
> '-iso-templates on'
> >> option?  All the others support several common
> nonconformance bugs,
> >> many of which I was exploiting in Boost.Python v1.
> >
> > I haven't tried with -iso- option, I'll try it when i
> get home. We
> > do not however use the bug you where exploiting i bpl.v1
> (i assume
> > you are referreing to friend templates?).
>
> No, friend functions declared in templates being found
> without Koenig
> Lookup.

Right, that's what I meant. :)

>
> >> > For us it doesn't seem like an option to dispatch the
> converters at
> >> > runtime, since performance is a really high priority
> for our users.
> >>
> >> What we're doing in Boost.Python turns out to be very
> efficient,
> >> well below the threshold that anyone would notice IIUC.
>  Eric Jones
> >> did a test comparing its speed to SWIG and to my great
> surprise,
> >> Boost.Python won.
> >
> > Lua is used a lot in game developement, and game
> developers tend to
> > care very much about every extra cycle. Even an extra
> function call
> > via a function pointer could make difference for those
> users.
>
> I'm not convinced yet.  Just adding a tiny bit of lua code
> next to any
> invocation of a wrapped function would typically consume
> much more
> than that.
>
> > We like the generated bindings to be almost equal in
> speed to one
> > that is hand written.
>
> Me too; I just have serious doubts that once you factor in
> everything
> else that you want going on (e.g. derived <==> base
> conversions), the
> ability to dynamically register conversions has a
> significant cost.

You might be right. I'll investigate how runtime dispatch
would affect luabind the next couple of days, in particular
I will look at what this would do to our policy system.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Thu, 19 Jun 2003 11:45:52 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056037798 32368 80.91.224.249 (19 Jun 2003 15:49:58 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 19 Jun 2003 15:49:58 +0000 (UTC)
Original-X-From: [email protected] Thu Jun 19 17:49:56 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19T1ey-0008Ko-00
	for <[email protected]>; Thu, 19 Jun 2003 17:49:12 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19T1f1-0007oW-00; Thu, 19 Jun 2003 11:49:15 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19T1eG-0007Y2-00
	for [email protected]; Thu, 19 Jun 2003 11:48:28 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19T1d6-00089f-00
	for <[email protected]>; Thu, 19 Jun 2003 17:47:16 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19T1c8-00084U-00
	for <[email protected]>; Thu, 19 Jun 2003 17:46:16 +0200
Original-Lines: 178
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:yOR2R2P3eufme3oeaR4w0W9rKQs=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:16
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3499
Lines: 178
X-Gnus-Newsgroup: langbinding-mbox:16   Sat Jul 19 11:05:36 2003

"dalwan01" <[email protected]> writes:

>> "dalwan01" <[email protected]> writes:
>>
>> >>
>> >> Moving this to the C++-sig as it's a more appropriate
>> >> forum...
>> >>
>> >> "dalwan01" <[email protected]> writes:
>> >>
>> >> >> Daniel Wallin <[email protected]> writes:
>> >> >>
>> >> >> > Note however that there are quite a few differences in
>> >> >> > design, for instance for our scope's we have been
>> >> >> > experimenting with expressions ala phoenix:
>> >> >> >
>> >> >> > namespace_("foo")
>> >> >> > [
>> >> >> >    def(..),
>> >> >> >    def(..)
>> >> >> > ];
>> >> >>
>> >> >> I considered this syntax but I am not convinced it is an
>> >> >> advantage.  It seems to have quite a few downsides and no
>> >> >> upsides. Am I missing something?
>> >> >
>> >> > For us it has several upsides:
>> >> >
>> >> >   * We can easily nest namespaces
>> >>
>> >> IMO, it optimizes for the wrong case, since namespaces are
>> >> typically flat rather than deeply nested (see the Zen of
>> >> Python), nor are they represented explicitly in Python code, but
>> >> inferred from file boundaries.
>> >>
>> >> >   * We like the syntax :)
>> >>
>> >> It is nice for C++ programmers, but Python programmers at least
>> >> are very much more comfortable without the brackets.
>> >
>> >
>> >>
>> >> >   * We can remove the lua_State* parameter from
>> >> >     all calls to def()/class_()
>> >>
>> >> I'm not sure what that is.  We handle global state in
>> >> Boost.Python by simply keeping track of the current module
>> >> ("state") in a global variable.  Works a treat.
>> >
>> > As pointed out lua can handle multiple states, so using global
>> > variabels doesn't strike me as a very good solution.
>>
>> I am not committed to the global variable approach nor am I opposed
>> to the syntax.

In fact, the more I look at the syntax of luabind, the more I like.
Using addition for policy accumulation is cool.  The naming of the
policies is cool.

>> > This doesn't increase compile times.
>>
>> Good.  Virtual functions come with bloat of their own, but that's
>> an implementation detail which can be mitigated.
>
> Right. The virtual functions isn't generated in the
> template, so there is very little code generated.

I don't see how that's possible, but I guess I'll learn.

>> >> > I think it's conformant, but I wouldn't swear on it.
>> >> > We strip all qualifiers from the types and specialize on
>> >> >
>> >> >   by_cref<..>
>> >> >   by_ref<..>
>> >> >   by_ptr<..>
>> >> >   by_value<..>
>> >> >
>> >> > types.
>>
>> I'm not really sure what the above means yet... I'm certainly
>> interested in avoiding runtime dispatching if possible, so if this
>> approach is viable for Boost.Python I'm all for it.
>
> I don't know if i fully understand the ordering issues you
> mentioned. When we first implemented this we had converter
> functions with this sig:
>
> T convert(type<T>, ..)
>
> This of course introduces problems with some compilers when
> trying to overload for T& and T* and such. So we introduced
> a more complex type<..>.. T& -> by_ref<T>, const T& ->
> by_cref<T> etc.

The ordering issues basically have to do with the requirement that
classes be wrapped and converters defined before they are used,
syntactically speaking.  That caused all kinds of inconveniences in
BPLv1 when interacting classes were wrapped.  OTOH I bet it's possible
to implicltly choose conversion methods for classes which you haven't
seen a wrapper for, so maybe that's less of a problem than I'm making
it out to be.

>> >> How do people define specialized converters for particular
>> >> types?
>> >
>> > This isn't finished, but currently we do:
>> >
>> > yes_t is_user_defined(by_cref<my_type>);
>> > my_type convert_from_lua(lua_State*, by_cref<my_type>);
>> >
>> > something like that..
>>
>> I assume that means the user must define those two functions?
>> Where in the code must they be defined?
>
> Right. The user declares the first function and defines the
> other before binding functions that use the types.

Right.

>> How will this work when multiple extension modules need to
>> manipulate the same types?
>
> I don't know. I haven't given that much thought. Do you see
> any obvious issues?


Hmm, maybe I'm on drugs.  The biggest problems in BPLv1 in this area
were because the converters for a given class were generated,
essentially, by its class_<...> instantiation.  But I have already
said that from-python conversion for a given wrapped class is normally
done statically.

User-defined converters still need to be exposed to all the extensions
which use the types, somehow.  It would be better not to replicate
that code.  Furthermore there are potential issues of creating objects
in one DLL and destroying them elsewhere.  These may be minor in
comparison, though.

Ralf, do you have any insight here?

>> How do *add* a way to convert from Python type A to C++ type B
>> without masking the existing conversion from Python type Y to C++
>> type Z?
>
> I don't understand. How are B and Z related? Why would a
> conversion function for B mask conversions to Z?

Sorry, B==Z ;-)

>> > Lua is used a lot in game developement, and game developers tend to
>> > care very much about every extra cycle. Even an extra function call
>> > via a function pointer could make difference for those users.
>>
>> I'm not convinced yet.  Just adding a tiny bit of lua code next to
>> any invocation of a wrapped function would typically consume much
>> more than that.
>>
>> > We like the generated bindings to be almost equal in speed to one
>> > that is hand written.
>>
>> Me too; I just have serious doubts that once you factor in
>> everything else that you want going on (e.g. derived <==> base
>> conversions), the ability to dynamically register conversions has a
>> significant cost.
>
> You might be right. I'll investigate how runtime dispatch
> would affect luabind the next couple of days, in particular
> I will look at what this would do to our policy system.

OK.  Incidentally, I find much of what you're doing very appealing,
and I think that if we could find a way to share a lot of technology
it would be fantastic.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Fri, 20 Jun 2003 12:47:59 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056109795 1987 80.91.224.249 (20 Jun 2003 11:49:55 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 20 Jun 2003 11:49:55 +0000 (UTC)
Original-X-From: [email protected] Fri Jun 20 13:49:52 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19TKO4-0000SR-00
	for <[email protected]>; Fri, 20 Jun 2003 13:49:00 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19TKO9-0003XY-00; Fri, 20 Jun 2003 07:49:05 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19TKNC-0002Fk-00
	for [email protected]; Fri, 20 Jun 2003 07:48:06 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5KBm0FM047326;
	Fri, 20 Jun 2003 13:48:00 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:17
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3505
Lines: 243
X-Gnus-Newsgroup: langbinding-mbox:17   Sat Jul 19 11:05:36 2003

> "dalwan01" <[email protected]> writes:
>
> >> "dalwan01" <[email protected]> writes:
> >>
> >> >>
> >> >> Moving this to the C++-sig as it's a more
> appropriate
> >> >> forum...
> >> >>
> >> >> "dalwan01" <[email protected]> writes:
> >> >>
> >> >> >> Daniel Wallin <[email protected]> writes:
> >> >> >>
> >> >> >> > Note however that there are quite a few
> differences in
> >> >> >> > design, for instance for our scope's we have
> been
> >> >> >> > experimenting with expressions ala phoenix:
> >> >> >> >
> >> >> >> > namespace_("foo")
> >> >> >> > [
> >> >> >> >    def(..),
> >> >> >> >    def(..)
> >> >> >> > ];
> >> >> >>
> >> >> >> I considered this syntax but I am not convinced
> it is an
> >> >> >> advantage.  It seems to have quite a few
> downsides and no
> >> >> >> upsides. Am I missing something?
> >> >> >
> >> >> > For us it has several upsides:
> >> >> >
> >> >> >   * We can easily nest namespaces
> >> >>
> >> >> IMO, it optimizes for the wrong case, since
> namespaces are
> >> >> typically flat rather than deeply nested (see the
> Zen of
> >> >> Python), nor are they represented explicitly in
> Python code, but
> >> >> inferred from file boundaries.
> >> >>
> >> >> >   * We like the syntax :)
> >> >>
> >> >> It is nice for C++ programmers, but Python
> programmers at least
> >> >> are very much more comfortable without the brackets.
> >> >
> >> >
> >> >>
> >> >> >   * We can remove the lua_State* parameter from
> >> >> >     all calls to def()/class_()
> >> >>
> >> >> I'm not sure what that is.  We handle global state
> in
> >> >> Boost.Python by simply keeping track of the current
> module
> >> >> ("state") in a global variable.  Works a treat.
> >> >
> >> > As pointed out lua can handle multiple states, so
> using global
> >> > variabels doesn't strike me as a very good solution.
> >>
> >> I am not committed to the global variable approach nor
> am I opposed
> >> to the syntax.
>
> In fact, the more I look at the syntax of luabind, the
> more I like.
> Using addition for policy accumulation is cool.  The
> naming of the
> policies is cool.

It does increase compile times a bit though, but it
shouldn't matter that much.

>
> >> > This doesn't increase compile times.
> >>
> >> Good.  Virtual functions come with bloat of their own,
> but that's
> >> an implementation detail which can be mitigated.
> >
> > Right. The virtual functions isn't generated in the
> > template, so there is very little code generated.
>
> I don't see how that's possible, but I guess I'll learn.

We can generate the wrapper code in the template, and store
function pointers in the object instead of generating a
virtual function which generates the wrapper functions. I'm
not sure we do it that way though, been a while since I
looked at the code.

>
> >> >> > I think it's conformant, but I wouldn't swear on
> it.
> >> >> > We strip all qualifiers from the types and
> specialize on
> >> >> >
> >> >> >   by_cref<..>
> >> >> >   by_ref<..>
> >> >> >   by_ptr<..>
> >> >> >   by_value<..>
> >> >> >
> >> >> > types.
> >>
> >> I'm not really sure what the above means yet... I'm
> certainly
> >> interested in avoiding runtime dispatching if possible,
> so if this
> >> approach is viable for Boost.Python I'm all for it.
> >
> > I don't know if i fully understand the ordering issues
> you
> > mentioned. When we first implemented this we had
> converter
> > functions with this sig:
> >
> > T convert(type<T>, ..)
> >
> > This of course introduces problems with some compilers
> when
> > trying to overload for T& and T* and such. So we
> introduced
> > a more complex type<..>.. T& -> by_ref<T>, const T& ->
> > by_cref<T> etc.
>
> The ordering issues basically have to do with the
> requirement that
> classes be wrapped and converters defined before they are
> used,
> syntactically speaking.  That caused all kinds of
> inconveniences in
> BPLv1 when interacting classes were wrapped.  OTOH I bet
> it's possible
> to implicltly choose conversion methods for classes which
> you haven't
> seen a wrapper for, so maybe that's less of a problem than
> I'm making
> it out to be.

Ok. In BPLv1 you generated converter functions using friend
functions in templates though, and this was the cause for
these ordering issues?

>
> >> How will this work when multiple extension modules need
> to
> >> manipulate the same types?
> >
> > I don't know. I haven't given that much thought. Do you
> see
> > any obvious issues?
>
>
> Hmm, maybe I'm on drugs.  The biggest problems in BPLv1 in
> this area
> were because the converters for a given class were
> generated,
> essentially, by its class_<...> instantiation.  But I have
> already
> said that from-python conversion for a given wrapped class
> is normally
> done statically.
>
> User-defined converters still need to be exposed to all
> the extensions
> which use the types, somehow.  It would be better not to
> replicate
> that code.

I haven't thought about that at all. But it's a good point,
and it's impossible to not replicate the code with static
dispatch.

> >> How do *add* a way to convert from Python type A to C++
> type B
> >> without masking the existing conversion from Python
> type Y to C++
> >> type Z?
> >
> > I don't understand. How are B and Z related? Why would a
> > conversion function for B mask conversions to Z?
>
> Sorry, B==Z ;-)

Ah, ok. Well, this isn't finished either. We have a
(unfinished) system which works like this:

template<>
struct implicit_conversion<0, B> : from<A> {};
template<>
struct implicit_conversion<1, B> : from<Y> {};

Of course, this has all the problems with static dispatch as
well..

>
> >> > Lua is used a lot in game developement, and game
> developers tend to
> >> > care very much about every extra cycle. Even an extra
> function call
> >> > via a function pointer could make difference for
> those users.
> >>
> >> I'm not convinced yet.  Just adding a tiny bit of lua
> code next to
> >> any invocation of a wrapped function would typically
> consume much
> >> more than that.
> >>
> >> > We like the generated bindings to be almost equal in
> speed to one
> >> > that is hand written.
> >>
> >> Me too; I just have serious doubts that once you factor
> in
> >> everything else that you want going on (e.g. derived
> <==> base
> >> conversions), the ability to dynamically register
> conversions has a
> >> significant cost.
> >
> > You might be right. I'll investigate how runtime
> dispatch
> > would affect luabind the next couple of days, in
> particular
> > I will look at what this would do to our policy system.
>
> OK.  Incidentally, I find much of what you're doing very
> appealing,
> and I think that if we could find a way to share a lot of
> technology
> it would be fantastic.

I think so too. I'm looking around in BPL's conversion
system now trying to understand how I incorporate it in
luabind.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Fri, 20 Jun 2003 08:13:35 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056111304 8404 80.91.224.249 (20 Jun 2003 12:15:04 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 20 Jun 2003 12:15:04 +0000 (UTC)
Cc: Ralf W. Grosse-Kunstleve <[email protected]>
Original-X-From: [email protected] Fri Jun 20 14:15:02 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19TKnF-0002Aq-00
	for <[email protected]>; Fri, 20 Jun 2003 14:15:01 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19TKnK-0003qb-00; Fri, 20 Jun 2003 08:15:06 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19TKmP-0002rn-00
	for [email protected]; Fri, 20 Jun 2003 08:14:09 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19TKmG-00025G-00
	for <[email protected]>; Fri, 20 Jun 2003 14:14:00 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19TKmE-00024v-00
	for <[email protected]>; Fri, 20 Jun 2003 14:13:58 +0200
Original-Lines: 146
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:vUi/X7QZS6BMGUzDiT1S8iIcZU0=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:18
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3509
Lines: 146
X-Gnus-Newsgroup: langbinding-mbox:18   Sat Jul 19 11:05:36 2003


I just love how GNUs is able to straighten out that nasty Outlook
(Express) wrapping.  Unfortunately it looks like you're using
webmail, or you could use OE-QuoteFix :(

"Daniel Wallin" <[email protected]> writes:

>> In fact, the more I look at the syntax of luabind, the more I like.
>> Using addition for policy accumulation is cool.  The naming of the
>> policies is cool.
>
> It does increase compile times a bit though

What, overloading '+'?  I don't think it's significant.

> but it shouldn't matter that much.

Agreed.

>>
>> >> > This doesn't increase compile times.
>> >>
>> >> Good.  Virtual functions come with bloat of their own, but that's
>> >> an implementation detail which can be mitigated.
>> >
>> > Right. The virtual functions isn't generated in the
>> > template, so there is very little code generated.
>>
>> I don't see how that's possible, but I guess I'll learn.
>
> We can generate the wrapper code in the template, and store
> function pointers in the object instead of generating a
> virtual function which generates the wrapper functions. 

Well, IIUC, that means you have to treat def() the same when it
appears inside a class [...] as when it's inside a module [ ... ],
since there's no delayed evaluation.

    ah, wait: you don't use [ ... ] for class, which gets you off
    the hook.

    but what about nested classes?  Consistency would dictate the
    use of [ ... ].


> I'm not sure we do it that way though, been a while since I looked
> at the code.

OK.

>> The ordering issues basically have to do with the requirement that
>> classes be wrapped and converters defined before they are used,
>> syntactically speaking.  That caused all kinds of inconveniences in
>> BPLv1 when interacting classes were wrapped.  OTOH I bet it's
>> possible to implicltly choose conversion methods for classes which
>> you haven't seen a wrapper for, so maybe that's less of a problem
>> than I'm making it out to be.
>
> Ok. In BPLv1 you generated converter functions using friend
> functions in templates though, and this was the cause for
> these ordering issues?

That was one factor.  The other factor of course was that each class
which needed to be converted from Python used its own conversion
function, where a generalized procedure for converting classes will do
perfectly well.

There is still an issue of to-python conversions for wrapped classes;
different ones get generated depending on how the class is "held".
I'm not convinced that dynamically generating the smart pointer
conversions is needed, but conversions for virtual function
dispatching subclass may be.

>> >> How will this work when multiple extension modules need to
>> >> manipulate the same types?
>> >
>> > I don't know. I haven't given that much thought. Do you see
>> > any obvious issues?
>>
>>
>> Hmm, maybe I'm on drugs.  The biggest problems in BPLv1 in this
>> area were because the converters for a given class were generated,
>> essentially, by its class_<...> instantiation.  But I have already
>> said that from-python conversion for a given wrapped class is
>> normally done statically.
>>
>> User-defined converters still need to be exposed to all the
>> extensions which use the types, somehow.  It would be better not to
>> replicate that code.
>
> I haven't thought about that at all. But it's a good point, and it's
> impossible to not replicate the code with static dispatch.

Right.  BPLv1 used a nonuniform system of explicit importing
converters from other modules (thanks, Ralf!) but we went to uniform
dynamic dispatching for v2.

>> >> How do *add* a way to convert from Python type A to C++ type B
>> >> without masking the existing conversion from Python type Y to C++
>> >> type Z?
>> >
>> > I don't understand. How are B and Z related? Why would a
>> > conversion function for B mask conversions to Z?
>>
>> Sorry, B==Z ;-)
>
> Ah, ok. Well, this isn't finished either. We have a
> (unfinished) system which works like this:
>
> template<>
> struct implicit_conversion<0, B> : from<A> {};
> template<>
> struct implicit_conversion<1, B> : from<Y> {};
>
> Of course, this has all the problems with static dispatch as
> well..

And with multiple implicit conversions being contributed by multiple
people.  Also note that in many environments there's no guarantee that
different extension modules won't share a link namespace, so you have
to watch out for ODR problems.

>> >> Me too; I just have serious doubts that once you factor in
>> >> everything else that you want going on (e.g. derived <==> base
>> >> conversions), the ability to dynamically register conversions has a
>> >> significant cost.
>> >
>> > You might be right. I'll investigate how runtime dispatch
>> > would affect luabind the next couple of days, in particular
>> > I will look at what this would do to our policy system.
>>
>> OK.  Incidentally, I find much of what you're doing very appealing,
>> and I think that if we could find a way to share a lot of
>> technology it would be fantastic.
>
> I think so too. I'm looking around in BPL's conversion system now
> trying to understand how I incorporate it in luabind.

I am not convinced I got it 100% right.  You've forced me to think
about the issues again in a new way.  It may be that the best answer
blends our two approaches.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Sun, 22 Jun 2003 12:36:04 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056281819 22904 80.91.224.249 (22 Jun 2003 11:36:59 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sun, 22 Jun 2003 11:36:59 +0000 (UTC)
Original-X-From: [email protected] Sun Jun 22 13:36:57 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19U39V-0005xG-00
	for <[email protected]>; Sun, 22 Jun 2003 13:36:57 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19U39e-0000eK-00; Sun, 22 Jun 2003 07:37:06 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19U38h-0000W4-00
	for [email protected]; Sun, 22 Jun 2003 07:36:07 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5MBa5FM034808;
	Sun, 22 Jun 2003 13:36:05 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:19
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3517
Lines: 275
X-Gnus-Newsgroup: langbinding-mbox:19   Sat Jul 19 11:05:36 2003

>
> I just love how GNUs is able to straighten out that nasty
> Outlook
> (Express) wrapping.  Unfortunately it looks like you're
> using
> webmail, or you could use OE-QuoteFix :(

I am using webmail, my home connection is down so I either
use this or configure mutt. :)

>
> "Daniel Wallin" <[email protected]> writes:
>
> >> In fact, the more I look at the syntax of luabind, the
> more I like.
> >> Using addition for policy accumulation is cool.  The
> naming of the
> >> policies is cool.
> >
> > It does increase compile times a bit though
>
> What, overloading '+'?  I don't think it's significant.

I meant composing typelist's with '+' opposed to composing
the typelist manually like in BPL.

> >>
> >> >> > This doesn't increase compile times.
> >> >>
> >> >> Good.  Virtual functions come with bloat of their
> own, but that's
> >> >> an implementation detail which can be mitigated.
> >> >
> >> > Right. The virtual functions isn't generated in the
> >> > template, so there is very little code generated.
> >>
> >> I don't see how that's possible, but I guess I'll
> learn.
> >
> > We can generate the wrapper code in the template, and
> store
> > function pointers in the object instead of generating a
> > virtual function which generates the wrapper functions.
>
> Well, IIUC, that means you have to treat def() the same
> when it
> appears inside a class [...] as when it's inside a module
> [ ... ],
> since there's no delayed evaluation.
>
>     ah, wait: you don't use [ ... ] for class, which gets
> you off
>     the hook.
>
>     but what about nested classes?  Consistency would
> dictate the
>     use of [ ... ].

Right, we don't have nested classes. We have thought about a
few solutions:

class_<A>("A")
  .def(..)
  [
    class_<inner>("inner")
      .def(..)
  ]
  .def(..)
  ;

Or reusing namespace_:

  class_<A>("A"),
  namespace_("A")
  [ class_<inner>(..) ]

We thought that nested classes is less common than nested
namespaces.

> >> The ordering issues basically have to do with the
> requirement that
> >> classes be wrapped and converters defined before they
> are used,
> >> syntactically speaking.  That caused all kinds of
> inconveniences in
> >> BPLv1 when interacting classes were wrapped.  OTOH I
> bet it's
> >> possible to implicltly choose conversion methods for
> classes which
> >> you haven't seen a wrapper for, so maybe that's less of
> a problem
> >> than I'm making it out to be.
> >
> > Ok. In BPLv1 you generated converter functions using
> friend
> > functions in templates though, and this was the cause
> for
> > these ordering issues?
>
> That was one factor.  The other factor of course was that
> each class
> which needed to be converted from Python used its own
> conversion
> function, where a generalized procedure for converting
> classes will do
> perfectly well.

Right. We have a general conversion function for all
user-defined types. More on this later.

>
> There is still an issue of to-python conversions for
> wrapped classes;
> different ones get generated depending on how the class is
> "held".
> I'm not convinced that dynamically generating the smart
> pointer
> conversions is needed, but conversions for virtual
> function
> dispatching subclass may be.

I don't understand how this has anything to do with
ordering. Unless you mean that you need to register the
types before executing python/lua code that uses them, which
seems pretty obvious. :)

>
> >> >> How will this work when multiple extension modules
> need to
> >> >> manipulate the same types?
> >> >
> >> > I don't know. I haven't given that much thought. Do
> you see
> >> > any obvious issues?
> >>
> >>
> >> Hmm, maybe I'm on drugs.  The biggest problems in BPLv1
> in this
> >> area were because the converters for a given class were
> generated,
> >> essentially, by its class_<...> instantiation.  But I
> have already
> >> said that from-python conversion for a given wrapped
> class is
> >> normally done statically.
> >>
> >> User-defined converters still need to be exposed to all
> the
> >> extensions which use the types, somehow.  It would be
> better not to
> >> replicate that code.
> >
> > I haven't thought about that at all. But it's a good
> point, and it's
> > impossible to not replicate the code with static
> dispatch.
>
> Right.  BPLv1 used a nonuniform system of explicit
> importing
> converters from other modules (thanks, Ralf!) but we went
> to uniform
> dynamic dispatching for v2.
>
> >> >> How do *add* a way to convert from Python type A to
> C++ type B
> >> >> without masking the existing conversion from Python
> type Y to C++
> >> >> type Z?
> >> >
> >> > I don't understand. How are B and Z related? Why
> would a
> >> > conversion function for B mask conversions to Z?
> >>
> >> Sorry, B==Z ;-)
> >
> > Ah, ok. Well, this isn't finished either. We have a
> > (unfinished) system which works like this:
> >
> > template<>
> > struct implicit_conversion<0, B> : from<A> {};
> > template<>
> > struct implicit_conversion<1, B> : from<Y> {};
> >
> > Of course, this has all the problems with static
> dispatch as
> > well..
>
> And with multiple implicit conversions being contributed
> by multiple
> people.  Also note that in many environments there's no
> guarantee that
> different extension modules won't share a link namespace,
> so you have
> to watch out for ODR problems.

Right. We didn't really intend for luabind to be used in
this way, but rather for binding closed modules. It seems to
me like this can't be very common thing to do though, at
least not with lua. I have very little insight in how python
is used.

>
> >> >> Me too; I just have serious doubts that once you
> factor in
> >> >> everything else that you want going on (e.g. derived
> <==> base
> >> >> conversions), the ability to dynamically register
> conversions has a
> >> >> significant cost.
> >> >
> >> > You might be right. I'll investigate how runtime
> dispatch
> >> > would affect luabind the next couple of days, in
> particular
> >> > I will look at what this would do to our policy
> system.
> >>
> >> OK.  Incidentally, I find much of what you're doing
> very appealing,
> >> and I think that if we could find a way to share a lot
> of
> >> technology it would be fantastic.
> >
> > I think so too. I'm looking around in BPL's conversion
> system now
> > trying to understand how I incorporate it in luabind.
>
> I am not convinced I got it 100% right.  You've forced me
> to think
> about the issues again in a new way.  It may be that the
> best answer
> blends our two approaches.

Your converter implementation with static ref's to the
registry entry is really clever. Instead of doing this we
have general converters which is used to convert all
user-defined types. To do this we need a map<..> lookup to
find the appropriate converter and this really sucks.

As mentioned before, lua can have multiple states, so it
would be cool if the converters would be bound to the state
somehow. This would probably mean we would need to store a
hash table in the registry entries and hash the lua state
pointer (or something associated with the state) though, and
I don't know if there is sufficient need for the feature to
introduce this overhead.

I don't know if I understand the issues with multiple
extension modules. You register the converters in a map with
the typeinfo as key, but I don't understand how this could
ever work between dll's. Do you compare the typenames? If
so, this could never work between modules compiled with
different compilers. So it seems to me like this feature
can't be that useful, what am I missing?

Anyway, I find your converter system more appealing than
ours. There are some issues which need to be taken care of;
We choose best match, not first match, when trying different
overloads. This means we need to keep the storage for the
converter on the stack of a function that is unaware of the
converter size (at compile time). So we need to either have
a fixed size buffer on the stack, and hope it works, or
allocate the storage at runtime.

For clarification:

void dispatcher(..)
{
  *storage here*
  try all overloads
  call best overload
}

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Ralf W. Grosse-Kunstleve" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Sun, 22 Jun 2003 06:44:03 -0700 (PDT)
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056289500 11328 80.91.224.249 (22 Jun 2003 13:45:00 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sun, 22 Jun 2003 13:45:00 +0000 (UTC)
Original-X-From: [email protected] Sun Jun 22 15:44:58 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19U59O-0002wI-00
	for <[email protected]>; Sun, 22 Jun 2003 15:44:58 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19U59V-00061O-00; Sun, 22 Jun 2003 09:45:05 -0400
Original-Received: from web20206.mail.yahoo.com ([216.136.226.61])
	by mail.python.org with smtp (Exim 4.05)
	id 19U58W-0005HH-00
	for [email protected]; Sun, 22 Jun 2003 09:44:04 -0400
Original-Received: from [12.208.26.202] by web20206.mail.yahoo.com via HTTP; Sun, 22 Jun 2003 06:44:03 PDT
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:20
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3518
Lines: 91
X-Gnus-Newsgroup: langbinding-mbox:20   Sat Jul 19 11:05:36 2003

--- Daniel Wallin <[email protected]> wrote:
> Right. We didn't really intend for luabind to be used in
> this way, but rather for binding closed modules. It seems to
> me like this can't be very common thing to do though, at
> least not with lua. I have very little insight in how python
> is used.

Boost.Python's "cross-module" feature is absolutely essential for us.
Unfortunately my cross-module web page seems to have fallen through the
cracks in the V1->V2 transition, but here it is, resurrected:

http://cci.lbl.gov/~rwgk/boost_1_28_0/libs/python/doc/cross_module.html

Adding to this: imagine you had to link all extensions statically into
Python. This is analog to not having cross-module support. Maybe it is
not important if you don't expect others to extend your system, but such
a barrier against natural growth is unacceptable for us.

Anecdotal comment: If you go way back in the Boost mailing list (4th
quarter of 2000) you can see that David wasn't very fond of the cross-module
idea at all :-)

Regarding the "static vs. dynamic dispatch" discussion: It seems to me
(without having thought it through) that static dispatch is associated
with explicitly importing and exporting converters a la Boost.Python
V1 (see cross_module.html referenced above). This made building
extensions quite cumbersome as our system got bigger. In practice it
was a *big* relieve when we upgraded to Boost.Python V2. The dynamic
dispatch allowed me to be very generous with introducing a large number
of "convenience converters" which would have been impractical in V1.
To get an idea look at this fragment of our system for wrapping
multi-dimensional C++ arrays:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/array_family/boost_python/flex_fwd.h?rev=1.4&content-type=text/vnd.viewcvs-markup

Each of the 20 C++ types in the signatures of the friend functions in
the flew_fwd<> struct (which is just a workaround for MIPSpro but nice
to show all the types in one place) needs custom from_python converters
(plural!) *for each* T, of which we have 14 right now. Due to the
dynamic dispatch I can define as many converters as I need *in one
place* and use them "just like that" in any other extension module.
In contrast, with Boost.Python V1 I had to bring all the right
converters into each C++ translation unit.

Regarding efficiency considerations: Boost.Python's (V2) conversions
are amazingly fast, on the order of 100000 per second on a recent
Intel/Linux system (I say "amazingly" because I know, to a certain
degree, how involved the C++ code is that makes this happen). But
anyway, I believe if you have to cross the language boundary 100000
times you are making a big mistake. If you have to do something 100000
times it can only be in a loop of some form. Simplified:

  for i in xrange(100000):
    call_wrapped_function(some_argument[i])

Our approach is to take full advantage of Boost.Python's ease of
use in wrapping additional functions:

E.g. in C++:

  void
  vectorized_function(array<type_of_some_argument>& a)
  {
    for(std::size_t i=0;i<a.size();i++) {
      function(a[i));
    }
  }

  ...

  def("function", vectorized_function);
  def("function", function); // just in case

Of course, critical to this approach is the ability to easily wrap
arrays of user-defined types, and critical to that is the cross-module
feature.

To summary my practical experience: Maybe (?) static dispatch is more
efficient if most of your loops are in the interpreted layer, but it is
vastly more efficient if you push the rate-limiting loops down into the
compiled layer. This requires wrapping arrays of user-defined types
which is much easier handled in a system based on dynamic dispatch. So
overall dynamic dispatch wins out by a large margin.

Ralf


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Sun, 22 Jun 2003 16:27:13 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056313691 1481 80.91.224.249 (22 Jun 2003 20:28:11 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sun, 22 Jun 2003 20:28:11 +0000 (UTC)
Original-X-From: [email protected] Sun Jun 22 22:28:06 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UBRV-0000NL-00
	for <[email protected]>; Sun, 22 Jun 2003 22:28:05 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UBRe-0007gj-00; Sun, 22 Jun 2003 16:28:14 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19UBRI-0007JU-00
	for [email protected]; Sun, 22 Jun 2003 16:27:52 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UBR5-0000M8-00
	for <[email protected]>; Sun, 22 Jun 2003 22:27:39 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UBR5-0000Lz-00
	for <[email protected]>; Sun, 22 Jun 2003 22:27:39 +0200
Original-Lines: 227
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:0WRWVJtH2Y4BsiWX/WlHqFW7nHc=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:21
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3522
Lines: 227
X-Gnus-Newsgroup: langbinding-mbox:21   Sat Jul 19 11:05:36 2003

"Daniel Wallin" <[email protected]> writes:

I wrote:

>> >> In fact, the more I look at the syntax of luabind, the more I like.
>> >> Using addition for policy accumulation is cool.  The naming of the
>> >> policies is cool.
>> >
>> > It does increase compile times a bit though
>>
>> What, overloading '+'?  I don't think it's significant.
>
> I meant composing typelist's with '+' opposed to composing
> the typelist manually like in BPL.

I think we agree that's probably minor.

>> >> >> > This doesn't increase compile times.
>> >> >>
>> >> >> Good.  Virtual functions come with bloat of their own, but that's
>> >> >> an implementation detail which can be mitigated.
>> >> >
>> >> > Right. The virtual functions isn't generated in the
>> >> > template, so there is very little code generated.
>> >>
>> >> I don't see how that's possible, but I guess I'll learn.
>> >
>> > We can generate the wrapper code in the template, and store
>> > function pointers in the object instead of generating a
>> > virtual function which generates the wrapper functions.
>>
>> Well, IIUC, that means you have to treat def() the same when it
>> appears inside a class [...] as when it's inside a module [ ... ],
>> since there's no delayed evaluation.
>>
>>     ah, wait: you don't use [ ... ] for class, which gets you off
>>     the hook.
>>
>>     but what about nested classes?  Consistency would dictate the
>>     use of [ ... ].
>
> Right, we don't have nested classes. We have thought about a
> few solutions:
>
> class_<A>("A")
>   .def(..)
>   [
>     class_<inner>("inner")
>       .def(..)
>   ]
>   .def(..)
>   ;

Looks pretty!

> Or reusing namespace_:
>
>   class_<A>("A"),
>   namespace_("A")
>   [ class_<inner>(..) ]
>
> We thought that nested classes is less common than nested
> namespaces.

Either one works; I like the former, but I think you ought to be able
to do both.

>> >> The ordering issues basically have to do with the requirement that
>> >> classes be wrapped and converters defined before they are used,
>> >> syntactically speaking.  That caused all kinds of inconveniences in
>> >> BPLv1 when interacting classes were wrapped.  OTOH I bet it's
>> >> possible to implicltly choose conversion methods for classes which
>> >> you haven't seen a wrapper for, so maybe that's less of a problem
>> >> than I'm making it out to be.
>> >
>> > Ok. In BPLv1 you generated converter functions using friend
>> > functions in templates though, and this was the cause for
>> > these ordering issues?
>>
>> That was one factor.  The other factor of course was that each
>> class which needed to be converted from Python used its own
>> conversion function, where a generalized procedure for converting
>> classes will do perfectly well.
>
> Right. We have a general conversion function for all
> user-defined types. 

We actually have something similar, plus dynamic lookup **as a
fallback in case the usual method doesn't work**

> More on this later.

OK

>> There is still an issue of to-python conversions for wrapped
>> classes; different ones get generated depending on how the class is
>> "held".  I'm not convinced that dynamically generating the smart
>> pointer conversions is needed, but conversions for virtual function
>> dispatching subclass may be.
>
> I don't understand how this has anything to do with ordering. Unless
> you mean that you need to register the types before executing
> python/lua code that uses them, which seems pretty obvious. :)

It has nothing to do with ordering; I'm just thinking out loud about
how much dynamic lookup is actually buying in Boost.Python.

>> >> >> How do *add* a way to convert from Python type A to C++ type B
>> >> >> without masking the existing conversion from Python type Y to C++
>> >> >> type Z?
>> >> >
>> >> > I don't understand. How are B and Z related? Why would a
>> >> > conversion function for B mask conversions to Z?
>> >>
>> >> Sorry, B==Z ;-)
>> >
>> > Ah, ok. Well, this isn't finished either. We have a
>> > (unfinished) system which works like this:
>> >
>> > template<>
>> > struct implicit_conversion<0, B> : from<A> {};
>> > template<>
>> > struct implicit_conversion<1, B> : from<Y> {};
>> >
>> > Of course, this has all the problems with static dispatch as
>> > well..
>>
>> And with multiple implicit conversions being contributed by
>> multiple people.  Also note that in many environments there's no
>> guarantee that different extension modules won't share a link
>> namespace, so you have to watch out for ODR problems.
>
> Right. We didn't really intend for luabind to be used in this way,
> but rather for binding closed modules. 

I think I'm saying that on some systems (not many), there's no such
thing as a "closed module".  If they're loaded in the same process,
they share a link namespace :(

>> > I think so too. I'm looking around in BPL's conversion system now
>> > trying to understand how I incorporate it in luabind.
>>
>> I am not convinced I got it 100% right.  You've forced me to think
>> about the issues again in a new way.  It may be that the best
>> answer blends our two approaches.
>
> Your converter implementation with static ref's to the
> registry entry is really clever. 

Thanks!

> Instead of doing this we have general converters which is used to
> convert all user-defined types. 

I have the same thing for most from_python conversions; the registry
is only used as a fallback in that case.

> To do this we need a map<..> lookup to find the appropriate
> converter and this really sucks.

I can't understand why you'd need that, but maybe I'm missing
something.  The general mechanism in Boost.Python is that
instance_holder::holds(type_info) will give you the address of the
contained instance if it's there.

> As mentioned before, lua can have multiple states, so it would be
> cool if the converters would be bound to the state somehow. 

Why?  It doesn't seem like it would be very useful to have different
states doing different conversions.

> This would probably mean we would need to store a hash table in the
> registry entries and hash the lua state pointer (or something
> associated with the state) though, and I don't know if there is
> sufficient need for the feature to introduce this overhead.
>
> I don't know if I understand the issues with multiple extension
> modules. You register the converters in a map with the typeinfo as
> key, but I don't understand how this could ever work between
> dll's. Do you compare the typenames? 

Depends on the platform.  See my other message and
boost/python/type_id.hpp.

> If so, this could never work between modules compiled with different
> compilers. 

If they don't have compatible ABIs you don't want them to match
anyway, but this is currently an area of weakness in the system.

> So it seems to me like this feature can't be that useful,
> what am I missing?

Well, it's terribly useful for teams who are developing large
systems.  Each individual can produce wrappers just for just her part
of it, and they all interact correctly.

> Anyway, I find your converter system more appealing than
> ours. There are some issues which need to be taken care of;
> We choose best match, not first match, when trying different
> overloads. This means we need to keep the storage for the
> converter on the stack of a function that is unaware of the
> converter size (at compile time). So we need to either have
> a fixed size buffer on the stack, and hope it works, or
> allocate the storage at runtime.

I would love to have best match conversion.  I was going to do it at
one point, but realized eventually that users can sort the overloads
so that they always work so I never bothered to code it.

> For clarification:
>
> void dispatcher(..)
> {
>   *storage here*
>   try all overloads
>   call best overload
> }

I've already figured out how to solve this problem; if we can figure
out how to share best-conversion technology I'll happily code it up
;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Sun, 22 Jun 2003 19:39:51 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056307208 12449 80.91.224.249 (22 Jun 2003 18:40:08 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sun, 22 Jun 2003 18:40:08 +0000 (UTC)
Original-X-From: [email protected] Sun Jun 22 20:39:57 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19U9kr-0003Dk-00
	for <[email protected]>; Sun, 22 Jun 2003 20:39:57 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19U9l0-0001VV-00; Sun, 22 Jun 2003 14:40:06 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19U9kn-0001Lg-00
	for [email protected]; Sun, 22 Jun 2003 14:39:53 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5MIdqFM078097;
	Sun, 22 Jun 2003 20:39:52 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:22
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3519
Lines: 38
X-Gnus-Newsgroup: langbinding-mbox:22   Sat Jul 19 11:05:36 2003

> --- Daniel Wallin <[email protected]> wrote:
> > Right. We didn't really intend for luabind to be used in
> > this way, but rather for binding closed modules. It
> seems to
> > me like this can't be very common thing to do though, at
> > least not with lua. I have very little insight in how
> python
> > is used.
>
> Boost.Python's "cross-module" feature is absolutely
> essential for us.
>
> <snip>
>
> To summary my practical experience: Maybe (?) static
> dispatch is more
> efficient if most of your loops are in the interpreted
> layer, but it is
> vastly more efficient if you push the rate-limiting loops
> down into the
> compiled layer. This requires wrapping arrays of
> user-defined types
> which is much easier handled in a system based on dynamic
> dispatch. So
> overall dynamic dispatch wins out by a large margin.

I mostly agree with everything you say. However, it may
still be of interest to be able to bypass the dynamic
dispatch system and use converters with static dispatch. I
fail to see how wrapping arrays of user-defined types is
easier with dynamic dispatch though.

How do you import the converters from one module to another?
And how does type_info objects compare between dll
boundries?

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Sun, 22 Jun 2003 16:11:48 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056312778 31267 80.91.224.249 (22 Jun 2003 20:12:58 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sun, 22 Jun 2003 20:12:58 +0000 (UTC)
Original-X-From: [email protected] Sun Jun 22 22:12:57 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UBCr-000883-00
	for <[email protected]>; Sun, 22 Jun 2003 22:12:57 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UBD0-0000ku-00; Sun, 22 Jun 2003 16:13:06 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19UBCO-0000Yn-00
	for [email protected]; Sun, 22 Jun 2003 16:12:29 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UBCB-00085k-00
	for <[email protected]>; Sun, 22 Jun 2003 22:12:15 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UBC9-00085T-00
	for <[email protected]>; Sun, 22 Jun 2003 22:12:13 +0200
Original-Lines: 77
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:ChRNS+lXPUrotMF4+IEQ881bCz4=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:23
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3520
Lines: 77
X-Gnus-Newsgroup: langbinding-mbox:23   Sat Jul 19 11:05:36 2003

"Daniel Wallin" <[email protected]> writes:

>> --- Daniel Wallin <[email protected]> wrote:
>>
>> > Right. We didn't really intend for luabind to be used in this
>> > way, but rather for binding closed modules. It seems to me like
>> > this can't be very common thing to do though, at least not with
>> > lua. I have very little insight in how python is used.
>>
>> Boost.Python's "cross-module" feature is absolutely essential for
>> us.

I want to lean a little bit in luabind's direction here.  One thing
we've been discussing on-and-off is how we can provide some "scoping"
for conversions (especially to-python conversions, of which you get
only one per type), to prevent different modules from colliding in
unpleasant ways.

While sharing conversions and types across modules is important for
some applications, it's clear that in many situations it's
undesirable.  For example, two independent modules may be compiled
with different compilers, or different alignment options.  You just
don't want those stepping on each others' toes.  Furthermore, on many
systems, when two extension modules link to the same shared library,
their link symbol spaces are automatically shared, so the symbol
insulation one normally gets by being in a separate shared object
accessed via dlopen is lost.

It seems to me that for groups interested in sharing conversions it
might be reasonable to have them to build a shared Boost.Python
library for their project, and have every module in the project link
to it.  That would provide some degree of isolation.  

Is it important for an extension module author to want to work with
types from two packages that have been wrapped in that way?  That
would imply linking to both of their BPL libraries, which is
impossible, unless we find a way to import converters from each
without actually using them.

I am envisioning a flexible system with at least one dynamic and
probably two static library configurations that can be combined to
achieve the desired sharing/isolation.

>> To summary my practical experience: Maybe (?) static dispatch is
>> more efficient if most of your loops are in the interpreted layer,
>> but it is vastly more efficient if you push the rate-limiting loops
>> down into the compiled layer. This requires wrapping arrays of
>> user-defined types which is much easier handled in a system based
>> on dynamic dispatch. So overall dynamic dispatch wins out by a
>> large margin.
>
> I mostly agree with everything you say. However, it may
> still be of interest to be able to bypass the dynamic
> dispatch system and use converters with static dispatch. I
> fail to see how wrapping arrays of user-defined types is
> easier with dynamic dispatch though.

Me too.  Comments, Ralf?

> How do you import the converters from one module to another?

The system does that; the demand for a converter for a given type
causes the converter chain in the global converter registry to be
bound to a reference at static initialization time.  Since all
modules that work with the same type are referring to the same
registry entry, it "just works"

> And how does type_info objects compare between dll boundries?

On most platforms, just fine because we've normalized them using
boost/python/type_id.hpp.  A few platforms (e.g. SGI) still have
problems, though.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Sun, 22 Jun 2003 16:12:06 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056313296 32734 80.91.224.249 (22 Jun 2003 20:21:36 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sun, 22 Jun 2003 20:21:36 +0000 (UTC)
Original-X-From: [email protected] Sun Jun 22 22:21:33 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UBLB-0008VY-00
	for <[email protected]>; Sun, 22 Jun 2003 22:21:33 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UBLL-0004Fw-00; Sun, 22 Jun 2003 16:21:43 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19UBK0-00045V-00
	for [email protected]; Sun, 22 Jun 2003 16:20:20 -0400
Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UBJn-0008Qa-00
	for <[email protected]>; Sun, 22 Jun 2003 22:20:07 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UBCR-00086p-00
	for <[email protected]>; Sun, 22 Jun 2003 22:12:31 +0200
Original-Lines: 77
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
In-Reply-To: <[email protected]> (Daniel Wallin's message
 of "Sun, 22 Jun 2003 19:39:51 +0100")
Cancel-Lock: sha1:/R7M2nPiW1QAAhiEbwDpmrX/riA=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:24
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3521
Lines: 77
X-Gnus-Newsgroup: langbinding-mbox:24   Sat Jul 19 11:05:36 2003

"Daniel Wallin" <[email protected]> writes:

>> --- Daniel Wallin <[email protected]> wrote:
>>
>> > Right. We didn't really intend for luabind to be used in this
>> > way, but rather for binding closed modules. It seems to me like
>> > this can't be very common thing to do though, at least not with
>> > lua. I have very little insight in how python is used.
>>
>> Boost.Python's "cross-module" feature is absolutely essential for
>> us.

I want to lean a little bit in luabind's direction here.  One thing
we've been discussing on-and-off is how we can provide some "scoping"
for conversions (especially to-python conversions, of which you get
only one per type), to prevent different modules from colliding in
unpleasant ways.

While sharing conversions and types across modules is important for
some applications, it's clear that in many situations it's
undesirable.  For example, two independent modules may be compiled
with different compilers, or different alignment options.  You just
don't want those stepping on each others' toes.  Furthermore, on many
systems, when two extension modules link to the same shared library,
their link symbol spaces are automatically shared, so the symbol
insulation one normally gets by being in a separate shared object
accessed via dlopen is lost.

It seems to me that for groups interested in sharing conversions it
might be reasonable to have them to build a shared Boost.Python
library for their project, and have every module in the project link
to it.  That would provide some degree of isolation.  

Is it important for an extension module author to want to work with
types from two packages that have been wrapped in that way?  That
would imply linking to both of their BPL libraries, which is
impossible, unless we find a way to import converters from each
without actually using them.

I am envisioning a flexible system with at least one dynamic and
probably two static library configurations that can be combined to
achieve the desired sharing/isolation.

>> To summary my practical experience: Maybe (?) static dispatch is
>> more efficient if most of your loops are in the interpreted layer,
>> but it is vastly more efficient if you push the rate-limiting loops
>> down into the compiled layer. This requires wrapping arrays of
>> user-defined types which is much easier handled in a system based
>> on dynamic dispatch. So overall dynamic dispatch wins out by a
>> large margin.
>
> I mostly agree with everything you say. However, it may
> still be of interest to be able to bypass the dynamic
> dispatch system and use converters with static dispatch. I
> fail to see how wrapping arrays of user-defined types is
> easier with dynamic dispatch though.

Me too.  Comments, Ralf?

> How do you import the converters from one module to another?

The system does that; the demand for a converter for a given type
causes the converter chain in the global converter registry to be
bound to a reference at static initialization time.  Since all
modules that work with the same type are referring to the same
registry entry, it "just works"

> And how does type_info objects compare between dll boundries?

On most platforms, just fine because we've normalized them using
boost/python/type_id.hpp.  A few platforms (e.g. SGI) still have
problems, though.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Ralf W. Grosse-Kunstleve" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Sun, 22 Jun 2003 13:51:49 -0700 (PDT)
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056315135 6441 80.91.224.249 (22 Jun 2003 20:52:15 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sun, 22 Jun 2003 20:52:15 +0000 (UTC)
Original-X-From: [email protected] Sun Jun 22 22:52:14 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UBoZ-0001eX-00
	for <[email protected]>; Sun, 22 Jun 2003 22:51:55 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UBoj-0002TE-00; Sun, 22 Jun 2003 16:52:05 -0400
Original-Received: from web20207.mail.yahoo.com ([216.136.226.62])
	by mail.python.org with smtp (Exim 4.05)
	id 19UBoV-0002O9-00
	for [email protected]; Sun, 22 Jun 2003 16:51:51 -0400
Original-Received: from [12.208.26.202] by web20207.mail.yahoo.com via HTTP; Sun, 22 Jun 2003 13:51:49 PDT
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:25
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3523
Lines: 56
X-Gnus-Newsgroup: langbinding-mbox:25   Sat Jul 19 11:05:36 2003

--- Daniel Wallin <[email protected]> wrote:
> I mostly agree with everything you say. However, it may
> still be of interest to be able to bypass the dynamic
> dispatch system and use converters with static dispatch. I
> fail to see how wrapping arrays of user-defined types is
> easier with dynamic dispatch though.

Maybe I wasn't precise enough here. It's not the wrapping that is
easier***, but that fact that I do not have to explicitly export and
import the converters.

> How do you import the converters from one module to another?

Hm, not having done the implementation I cannot tell for sure. I am
guessing that the registry, which resides in boost_python.dll, holds
essentially a few pointers to functions for the convertible() test and
the construct() stage. The machine code for these functions is in the
extension with the wrappers (i.e. the translation unit with the class_<>
instantiation). The other extensions get these function pointers from
the registry and then use the machine code from the first extension.
David, is this a reasonably accurate view?

> And how does type_info objects compare between dll
> boundries?

Again I can only offer a second-hand view. IIUC, on some platforms it is
possible to compare type_info objects across dll boundaries as if they
are in the same static link unit. I.e. there is nothing special. On some
platforms this is not possible, and type_id::name is used instead.
There is only one platform where relying on type_id::name caused a bit
of a hick-up, namely IRIX/MIPSpro. See the comment near the top of the
flew_fwd.h file (link in my previous message).

Anecdotal: when I first suggested the cross-module feature I had not
only no idea what to call it, but also no idea of all the difficulties
that we would run into. There were moments when I thought there is just
no way to get around a particular problem. The MIPSpro type_id::name
was one, but not the worst. That was issues with catching exceptions
thrown in one extension with the corresponding catch statement in
another. In retrospect it almost seems like a miracle that we got it to
work on all platforms eventually, but it does! Until quite recently I
wasn't sure about Mac OS 10 but even that we got to work now (at least
without optimization). I've also had success on an Itanium2 based
system, so there is not much out there that we have not tried.

Ralf

*** Footnote: For several reasons wrapping with Boost.Python V2 is a
lot easier compared to wrapping with V1, but maybe static vs. dynamic
dispatch is not the crucial difference.


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Sun, 22 Jun 2003 21:22:09 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056331378 702 80.91.224.249 (23 Jun 2003 01:22:58 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 01:22:58 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 03:22:56 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UG2q-0000B9-00
	for <[email protected]>; Mon, 23 Jun 2003 03:22:56 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UG30-0001ym-00; Sun, 22 Jun 2003 21:23:06 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19UG2i-0001jL-00
	for [email protected]; Sun, 22 Jun 2003 21:22:48 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UG2V-00009Z-00
	for <[email protected]>; Mon, 23 Jun 2003 03:22:35 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UG2U-00009G-00
	for <[email protected]>; Mon, 23 Jun 2003 03:22:34 +0200
Original-Lines: 16
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:eko54QO1S6z0P6/9ZNZ99U8AVak=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:26
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3524
Lines: 16
X-Gnus-Newsgroup: langbinding-mbox:26   Sat Jul 19 11:05:36 2003

"Ralf W. Grosse-Kunstleve" <[email protected]> writes:

> Hm, not having done the implementation I cannot tell for sure. I am
> guessing that the registry, which resides in boost_python.dll, holds
> essentially a few pointers to functions for the convertible() test and
> the construct() stage. The machine code for these functions is in the
> extension with the wrappers (i.e. the translation unit with the class_<>
> instantiation). The other extensions get these function pointers from
> the registry and then use the machine code from the first extension.
> David, is this a reasonably accurate view?

Yep.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Mon, 23 Jun 2003 13:21:03 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056370963 9988 80.91.224.249 (23 Jun 2003 12:22:43 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 12:22:43 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 14:22:41 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UQKa-0002YC-00
	for <[email protected]>; Mon, 23 Jun 2003 14:21:56 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UQKl-0003k3-00; Mon, 23 Jun 2003 08:22:07 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UQJm-0003Y1-00
	for [email protected]; Mon, 23 Jun 2003 08:21:06 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5NCL4e3066423;
	Mon, 23 Jun 2003 14:21:04 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:27
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3525
Lines: 300
X-Gnus-Newsgroup: langbinding-mbox:27   Sat Jul 19 11:05:36 2003

> "Daniel Wallin" <[email protected]> writes:
>
> I wrote:
>
> >> >> In fact, the more I look at the syntax of luabind,
> the more I like.
> >> >> Using addition for policy accumulation is cool.  The
> naming of the
> >> >> policies is cool.
> >> >
> >> > It does increase compile times a bit though
> >>
> >> What, overloading '+'?  I don't think it's significant.
> >
> > I meant composing typelist's with '+' opposed to
> composing
> > the typelist manually like in BPL.
>
> I think we agree that's probably minor.

Right.

>
> >> >> >> > This doesn't increase compile times.
> >> >> >>
> >> >> >> Good.  Virtual functions come with bloat of their
> own, but that's
> >> >> >> an implementation detail which can be mitigated.
> >> >> >
> >> >> > Right. The virtual functions isn't generated in
> the
> >> >> > template, so there is very little code generated.
> >> >>
> >> >> I don't see how that's possible, but I guess I'll
> learn.
> >> >
> >> > We can generate the wrapper code in the template, and
> store
> >> > function pointers in the object instead of generating
> a
> >> > virtual function which generates the wrapper
> functions.
> >>
> >> Well, IIUC, that means you have to treat def() the same
> when it
> >> appears inside a class [...] as when it's inside a
> module [ ... ],
> >> since there's no delayed evaluation.
> >>
> >>     ah, wait: you don't use [ ... ] for class, which
> gets you off
> >>     the hook.
> >>
> >>     but what about nested classes?  Consistency would
> dictate the
> >>     use of [ ... ].
> >
> > Right, we don't have nested classes. We have thought
> about a
> > few solutions:
> >
> > class_<A>("A")
> >   .def(..)
> >   [
> >     class_<inner>("inner")
> >       .def(..)
> >   ]
> >   .def(..)
> >   ;
>
> Looks pretty!

:)

>
> > Or reusing namespace_:
> >
> >   class_<A>("A"),
> >   namespace_("A")
> >   [ class_<inner>(..) ]
> >
> > We thought that nested classes is less common than
> nested
> > namespaces.
>
> Either one works; I like the former, but I think you ought
> to be able
> to do both.

Yeah, both need really minor adjustments to the system.

>
>
> >> There is still an issue of to-python conversions for
> wrapped
> >> classes; different ones get generated depending on how
> the class is
> >> "held".  I'm not convinced that dynamically generating
> the smart
> >> pointer conversions is needed, but conversions for
> virtual function
> >> dispatching subclass may be.
> >
> > I don't understand how this has anything to do with
> ordering. Unless
> > you mean that you need to register the types before
> executing
> > python/lua code that uses them, which seems pretty
> obvious. :)
>
> It has nothing to do with ordering; I'm just thinking out
> loud about
> how much dynamic lookup is actually buying in
> Boost.Python.

Ah, ok. :)

>
> >> >> >> How do *add* a way to convert from Python type A
> to C++ type B
> >> >> >> without masking the existing conversion from
> Python type Y to C++
> >> >> >> type Z?
> >> >> >
> >> >> > I don't understand. How are B and Z related? Why
> would a
> >> >> > conversion function for B mask conversions to Z?
> >> >>
> >> >> Sorry, B==Z ;-)
> >> >
> >> > Ah, ok. Well, this isn't finished either. We have a
> >> > (unfinished) system which works like this:
> >> >
> >> > template<>
> >> > struct implicit_conversion<0, B> : from<A> {};
> >> > template<>
> >> > struct implicit_conversion<1, B> : from<Y> {};
> >> >
> >> > Of course, this has all the problems with static
> dispatch as
> >> > well..
> >>
> >> And with multiple implicit conversions being
> contributed by
> >> multiple people.  Also note that in many environments
> there's no
> >> guarantee that different extension modules won't share
> a link
> >> namespace, so you have to watch out for ODR problems.
> >
> > Right. We didn't really intend for luabind to be used in
> this way,
> > but rather for binding closed modules.
>
> I think I'm saying that on some systems (not many),
> there's no such
> thing as a "closed module".  If they're loaded in the same
> process,
> they share a link namespace :(
>
> >> > I think so too. I'm looking around in BPL's
> conversion system now
> >> > trying to understand how I incorporate it in luabind.
> >>
> >> I am not convinced I got it 100% right.  You've forced
> me to think
> >> about the issues again in a new way.  It may be that
> the best
> >> answer blends our two approaches.
> >
> > Your converter implementation with static ref's to the
> > registry entry is really clever.
>
> Thanks!
>
> > Instead of doing this we have general converters which
> is used to
> > convert all user-defined types.
>
> I have the same thing for most from_python conversions;
> the registry
> is only used as a fallback in that case.

Hm, doesn't the conversion of UDT's pass through the normal
conversion system?

>
> > To do this we need a map<..> lookup to find the
> appropriate
> > converter and this really sucks.
>
> I can't understand why you'd need that, but maybe I'm
> missing
> something.  The general mechanism in Boost.Python is that
> instance_holder::holds(type_info) will give you the
> address of the
> contained instance if it's there.

Right, we have a map<const type_info*, ..> when performing
c++ -> lua conversions. You just need to do
registered<T>::conversions.to_python(..); Correct?

>
> > As mentioned before, lua can have multiple states, so it
> would be
> > cool if the converters would be bound to the state
> somehow.
>
> Why?  It doesn't seem like it would be very useful to have
> different
> states doing different conversions.

It can be useful to be able to register different types in
different states. Otherwise class_() would register global
types and def() would register local functions. Or am I
wrong in assuming that class_<T>() instantiates
registered<T> and add's a few converters?

>
> > If so, this could never work between modules compiled
> with different
> > compilers.
>
> If they don't have compatible ABIs you don't want them to
> match
> anyway, but this is currently an area of weakness in the
> system.

Right.

>
> > So it seems to me like this feature can't be that
> useful,
> > what am I missing?
>
> Well, it's terribly useful for teams who are developing
> large
> systems.  Each individual can produce wrappers just for
> just her part
> of it, and they all interact correctly.

Right.

>
> > Anyway, I find your converter system more appealing than
> > ours. There are some issues which need to be taken care
> of;
> > We choose best match, not first match, when trying
> different
> > overloads. This means we need to keep the storage for
> the
> > converter on the stack of a function that is unaware of
> the
> > converter size (at compile time). So we need to either
> have
> > a fixed size buffer on the stack, and hope it works, or
> > allocate the storage at runtime.
>
> I would love to have best match conversion.  I was going
> to do it at
> one point, but realized eventually that users can sort the
> overloads
> so that they always work so I never bothered to code it.

Do you still think best match is worth adding, or is sorting
an acceptable solution?

>
> > For clarification:
> >
> > void dispatcher(..)
> > {
> >   *storage here*
> >   try all overloads
> >   call best overload
> > }
>
> I've already figured out how to solve this problem; if we
> can figure
> out how to share best-conversion technology I'll happily
> code it up
> ;-)

:) How would you do it? I guess you could have static
storage in the match-function and store a pointer to that in
the converter data, but that wouldn't be thread safe.

It seems to me that sharing the conversion code out of the
box is going to be hard. Perhaps we should consider
parameterizing header files?

namespace luabind
{
  #define BOOST_LANG_CONVERSION_PARAMS \
    (2, (lua_State*, int))
  #include <blabla/conversions.hpp>
}

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Mon, 23 Jun 2003 09:30:49 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056375197 31131 80.91.224.249 (23 Jun 2003 13:33:17 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 13:33:17 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 15:33:15 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19URQg-00081H-00
	for <[email protected]>; Mon, 23 Jun 2003 15:32:19 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19URQr-0003Ac-00; Mon, 23 Jun 2003 09:32:29 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19URPu-0002k4-00
	for [email protected]; Mon, 23 Jun 2003 09:31:30 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19URPf-0007vf-00
	for <[email protected]>; Mon, 23 Jun 2003 15:31:15 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19URPd-0007vP-00
	for <[email protected]>; Mon, 23 Jun 2003 15:31:13 +0200
Original-Lines: 164
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:UEI7otZwkmV91f7aeftA3xP/cg4=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:28
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3528
Lines: 164
X-Gnus-Newsgroup: langbinding-mbox:28   Sat Jul 19 11:05:36 2003

"Daniel Wallin" <[email protected]> writes:

>> > Instead of doing this we have general converters which is used to
>> > convert all user-defined types.
>>
>> I have the same thing for most from_python conversions;
>> the registry
>> is only used as a fallback in that case.
>
> Hm, doesn't the conversion of UDT's pass through the normal
> conversion system?

See get_lvalue_from_python in
libs/python/src/converter/from_python.cpp.  First it calls
find_instance_impl, which will always find a pointer to the right type
inside a regular wrapped class if such a pointer is findable.  The
only thing that gets used from the registration in that case is a
type_info object, which has been stored in the registration, as
opposed to being passed as a separate parameter, just to minimize the
amount of object code generated in extension modules which are
invoking the conversion.

That's for from-python conversions, of course.  For to-python
conversions, yes, we nearly always end up consulting the registration
for the type.  But that's cheap, after all - there's just a single
method for converting any type to python so it just pulls the function
pointer out of the registration and invokes it.  Compared to the cost
of constructing a Python object, an indirect call gets lost in the
noise.  The fact that there can only be one way to do that also means
that we can introduce some specializations for conversion to python,
which bypasses indirection for known types such as int or std::string.
Note however that this bypassing actually has a usability cost because
the implicit conversion mechanism actually consults the registration
records directly, and I'm not currently filling in the to-python
registrations for these types with specializations, so some implicit
conversion sequences don't work.  It may have been premature
optimization to use specializations here.

>> > To do this we need a map<..> lookup to find the appropriate
>> > converter and this really sucks.
>>
>> I can't understand why you'd need that, but maybe I'm missing
>> something.  The general mechanism in Boost.Python is that
>> instance_holder::holds(type_info) will give you the address of the
>> contained instance if it's there.
>
> Right, we have a map<const type_info*, ..> when performing
> c++ -> lua conversions. You just need to do
> registered<T>::conversions.to_python(..); Correct?

Roughly speaking, yes.  But what I'm confused about is, if you're
using full compile-time dispatching for from-lua conversions, why you
don't do the same for to-lua conversions.  AFAICT, it's the former
where compile-time dispatch is most useful.  What's the 2nd argument
to the map?

>> > As mentioned before, lua can have multiple states, so it would be
>> > cool if the converters would be bound to the state somehow.
>>
>> Why?  It doesn't seem like it would be very useful to have
>> different states doing different conversions.
>
> It can be useful to be able to register different types in different
> states.

Why?

> Otherwise class_() would register global types and def()
> would register local functions. Or am I wrong in assuming that
> class_<T>() instantiates registered<T> and add's a few converters?

No, you're correct.  However, it also creates a Python type object in
the extension module's dictionary, just as def() creates callable
python objects in the module's dictionary.  I see the converter
registry as a separate data structure which exists in parallel with
the module's dictionary.  I don't see any reason to have a given
module register different sets of type conversions in different
states, even if it is going to contain different types/functions
(though I can't see why you'd want that either).

>> > Anyway, I find your converter system more appealing than
>> > ours. There are some issues which need to be taken care of;
>> > We choose best match, not first match, when trying different
>> > overloads. This means we need to keep the storage for the
>> > converter on the stack of a function that is unaware of the
>> > converter size (at compile time). So we need to either have
>> > a fixed size buffer on the stack, and hope it works, or
>> > allocate the storage at runtime.
>>
>> I would love to have best match conversion.  I was going to do it
>> at one point, but realized eventually that users can sort the
>> overloads so that they always work so I never bothered to code it.
>
> Do you still think best match is worth adding, or is sorting an
> acceptable solution?

I think in many cases, it's more understandable for users to be able
to simply control the order in which converters are tried.  It
certainly is *more efficient* than trying all converters, if you're
going to be truly compulsive about cycles, though I don't really care
about that.  We do have one guy, though, who's got a massively
confusable overload set and I think he's having trouble resolving it
because of the easy conversions between C++ (int, long long) and
Python (int, LONG).

       http://aspn.activestate.com/ASPN/Mail/Message/1652647

In general, I'd prefer to have more things "just work" automatically,
so yeah I think it's worth adding to Boost.Python.

>> > For clarification:
>> >
>> > void dispatcher(..)
>> > {
>> >   *storage here*
>> >   try all overloads
>> >   call best overload
>> > }
>>
>> I've already figured out how to solve this problem; if we can
>> figure out how to share best-conversion technology I'll happily
>> code it up ;-)
>
> :) How would you do it? 

I'll give you a hint, if you agree to cooperate on best-conversion:

     Your cycle-counters would probably go apoplectic.

> I guess you could have static storage in the match-function and
> store a pointer to that in the converter data, but that wouldn't be
> thread safe.

OK, here it is, I'll tell you: you use recursion.

> It seems to me that sharing the conversion code out of the box is
> going to be hard. 

You mean without any modification to existing conversion source?  I
never expected to achieve that.  Remember, I'm considering a
refactoring of the codebase anyway.

> Perhaps we should consider parameterizing header
> files?
>
> namespace luabind
> {
>   #define BOOST_LANG_CONVERSION_PARAMS \
>     (2, (lua_State*, int))
>   #include <blabla/conversions.hpp>
> }

Hmm, I'm not sure what you're trying to achieve here, but that kind of
parameterization seems unneccessary to me. we probably ought to do it
with templates if there's any chance at all that these systems would
have to be compiled together in some context... though I guess with
inclusion into separate namespaces you could get around that.  Well
OK, let's look at the requirements more carefully before we jump into
implementation details.  I may be willing to accept additional state.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Mon, 23 Jun 2003 14:02:52 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056373379 21238 80.91.224.249 (23 Jun 2003 13:02:59 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 13:02:59 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 15:02:54 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UQyD-0005WH-00
	for <[email protected]>; Mon, 23 Jun 2003 15:02:53 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UQyO-0000vq-00; Mon, 23 Jun 2003 09:03:04 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UQyE-0000sN-00
	for [email protected]; Mon, 23 Jun 2003 09:02:54 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5ND2re3014376;
	Mon, 23 Jun 2003 15:02:53 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:29
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3526
Lines: 30
X-Gnus-Newsgroup: langbinding-mbox:29   Sat Jul 19 11:05:36 2003

> > How do you import the converters from one module to
> another?
>
> The system does that; the demand for a converter for a
> given type
> causes the converter chain in the global converter
> registry to be
> bound to a reference at static initialization time.  Since
> all
> modules that work with the same type are referring to the
> same
> registry entry, it "just works"

Ah, right. The registry resides in the boost_python dll..
Clever. :)

>
> > And how does type_info objects compare between dll
> boundries?
>
> On most platforms, just fine because we've normalized them
> using
> boost/python/type_id.hpp.  A few platforms (e.g. SGI)
> still have
> problems, though.

Ok.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Mon, 23 Jun 2003 14:12:47 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056374112 24734 80.91.224.249 (23 Jun 2003 13:15:12 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 13:15:12 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 15:15:11 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UR7t-0006Cx-00
	for <[email protected]>; Mon, 23 Jun 2003 15:12:53 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UR85-0004kv-00; Mon, 23 Jun 2003 09:13:05 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UR7p-0004bw-00
	for [email protected]; Mon, 23 Jun 2003 09:12:49 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5NDCme3026507;
	Mon, 23 Jun 2003 15:12:48 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:30
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3527
Lines: 59
X-Gnus-Newsgroup: langbinding-mbox:30   Sat Jul 19 11:05:36 2003

> --- Daniel Wallin <[email protected]> wrote:
> > I mostly agree with everything you say. However, it may
> > still be of interest to be able to bypass the dynamic
> > dispatch system and use converters with static dispatch.
> I
> > fail to see how wrapping arrays of user-defined types is
> > easier with dynamic dispatch though.
>
> Maybe I wasn't precise enough here. It's not the wrapping
> that is
> easier***, but that fact that I do not have to explicitly
> export and
> import the converters.

Ok.

>
> > How do you import the converters from one module to
> another?
>
> Hm, not having done the implementation I cannot tell for
> sure. I am
> guessing that the registry, which resides in
> boost_python.dll, holds
> essentially a few pointers to functions for the
> convertible() test and
> the construct() stage. The machine code for these
> functions is in the
> extension with the wrappers (i.e. the translation unit
> with the class_<>
> instantiation). The other extensions get these function
> pointers from
> the registry and then use the machine code from the first
> extension.

Ok.

> > And how does type_info objects compare between dll
> > boundries?
>
> Again I can only offer a second-hand view. IIUC, on some
> platforms it is
> possible to compare type_info objects across dll
> boundaries as if they
> are in the same static link unit. I.e. there is nothing
> special. On some
> platforms this is not possible, and type_id::name is used
> instead.
> There is only one platform where relying on type_id::name
> caused a bit
> of a hick-up, namely IRIX/MIPSpro. See the comment near
> the top of the
> flew_fwd.h file (link in my previous message).

Ok. I guess you could unmangle the names to a standardized
format if there are problems with this?

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Mon, 23 Jun 2003 09:57:11 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056376858 7774 80.91.224.249 (23 Jun 2003 14:00:58 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 14:00:58 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 16:00:56 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19URrN-0001wv-00
	for <[email protected]>; Mon, 23 Jun 2003 15:59:54 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19URrZ-0004sm-00; Mon, 23 Jun 2003 10:00:05 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19URrF-0004p9-00
	for [email protected]; Mon, 23 Jun 2003 09:59:45 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19URr1-0001v8-00
	for <[email protected]>; Mon, 23 Jun 2003 15:59:31 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19URp9-0001is-00
	for <[email protected]>; Mon, 23 Jun 2003 15:57:35 +0200
Original-Lines: 50
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:+OaisySvjiL10CWGtnp96sOFdw4=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:31
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3530
Lines: 50
X-Gnus-Newsgroup: langbinding-mbox:31   Sat Jul 19 11:05:36 2003

"Daniel Wallin" <[email protected]> writes:

>> Again I can only offer a second-hand view. IIUC, on some platforms
>> it is possible to compare type_info objects across dll boundaries as
>> if they are in the same static link unit. I.e. there is nothing
>> special. On some platforms this is not possible, and type_id::name
>> is used instead.  There is only one platform where relying on
>> type_id::name caused a bit of a hick-up, namely IRIX/MIPSpro. See
>> the comment near the top of the flew_fwd.h file (link in my previous
>> message).
>
> Ok. I guess you could unmangle the names to a standardized format if
> there are problems with this?

No :(

Sadly, the problem is that typedefs don't always get fully-unwound in
type_info names, e.g.:

      // Module 1, prints ``X<long>::type``

      #include <iostream>

      template <class T>
      struct X
      {
          typedef int type;
      };

      int main()
      {
          std::cout << typeid(X<long>::type).name() << std::endl;
      }
      
      // Module 2, prints ``int``

      #include <iostream>

      int main()
      {
          std::cout << typeid(int).name() << std::endl;
      }
      
There's no issue in different translation units within a module; the
linker just picks a generated name() string from one translation unit.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Ralf W. Grosse-Kunstleve" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Mon, 23 Jun 2003 08:16:10 -0700 (PDT)
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056381981 5417 80.91.224.249 (23 Jun 2003 15:26:21 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 15:26:21 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 17:26:20 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UTCG-0001KO-00
	for <[email protected]>; Mon, 23 Jun 2003 17:25:33 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UTCS-0002b6-00; Mon, 23 Jun 2003 11:25:44 -0400
Original-Received: from web20202.mail.yahoo.com ([216.136.226.57])
	by mail.python.org with smtp (Exim 4.05)
	id 19UT3D-0006GB-00
	for [email protected]; Mon, 23 Jun 2003 11:16:11 -0400
Original-Received: from [12.208.26.202] by web20202.mail.yahoo.com via HTTP; Mon, 23 Jun 2003 08:16:10 PDT
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:32
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3531
Lines: 33
X-Gnus-Newsgroup: langbinding-mbox:32   Sat Jul 19 11:05:36 2003

--- Daniel Wallin <[email protected]> wrote:
> > Again I can only offer a second-hand view. IIUC, on some
> > platforms it is
> > possible to compare type_info objects across dll
> > boundaries as if they
> > are in the same static link unit. I.e. there is nothing
> > special. On some
> > platforms this is not possible, and type_id::name is used
> > instead.
> > There is only one platform where relying on type_id::name
> > caused a bit
> > of a hick-up, namely IRIX/MIPSpro. See the comment near
> > the top of the
> > flew_fwd.h file (link in my previous message).
> 
> Ok. I guess you could unmangle the names to a standardized
> format if there are problems with this?

Yes, as a last resort we could, e.g., manually specialize
boost::python::type_info (in boost/python/type_id.h) for all types
using the cross-module feature. Fortunately that has not been
necessary so far. And I don't see why it should ever be necessary
in hypothetical new platforms since there is TTBOMK no technical reason
for enforcing inconsistent type_id::name results. I.e. if we just tell
the developers of new platforms what we are using type_id::name for
it will most be likely easy for them to give us what we need.
Ralf


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Mon, 23 Jun 2003 21:29:34 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056400199 7853 80.91.224.249 (23 Jun 2003 20:29:59 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 20:29:59 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 22:29:55 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UXwp-000229-00
	for <[email protected]>; Mon, 23 Jun 2003 22:29:55 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UXx0-00026P-00; Mon, 23 Jun 2003 16:30:06 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UXwX-00021I-00
	for [email protected]; Mon, 23 Jun 2003 16:29:37 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5NKTZe3000284;
	Mon, 23 Jun 2003 22:29:36 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:33
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3532
Lines: 298
X-Gnus-Newsgroup: langbinding-mbox:33   Sat Jul 19 11:05:36 2003

> "Daniel Wallin" <[email protected]> writes:
>
> >> > Instead of doing this we have general converters
> which is used to
> >> > convert all user-defined types.
> >>
> >> I have the same thing for most from_python conversions;
> >> the registry
> >> is only used as a fallback in that case.
> >
> > Hm, doesn't the conversion of UDT's pass through the
> normal
> > conversion system?
>
> See get_lvalue_from_python in
> libs/python/src/converter/from_python.cpp.  First it calls
> find_instance_impl, which will always find a pointer to
> the right type
> inside a regular wrapped class if such a pointer is
> findable.  The
> only thing that gets used from the registration in that
> case is a
> type_info object, which has been stored in the
> registration, as
> opposed to being passed as a separate parameter, just to
> minimize the
> amount of object code generated in extension modules which
> are
> invoking the conversion.

Ok. This is roughly what we do too; the pointer is stored in
the lua object, together with a pointer to the class_rep*
associated with the pointee. The class_rep holds the
inheritance tree, so we just compare type_info's and
traverse the tree to perform the needed cast.

>
> That's for from-python conversions, of course.  For
> to-python
> conversions, yes, we nearly always end up consulting the
> registration
> for the type.  But that's cheap, after all - there's just
> a single
> method for converting any type to python so it just pulls
> the function
> pointer out of the registration and invokes it.  Compared
> to the cost
> of constructing a Python object, an indirect call gets
> lost in the
> noise.  The fact that there can only be one way to do that
> also means
> that we can introduce some specializations for conversion
> to python,
> which bypasses indirection for known types such as int or
> std::string.
> Note however that this bypassing actually has a usability
> cost because
> the implicit conversion mechanism actually consults the
> registration
> records directly, and I'm not currently filling in the
> to-python
> registrations for these types with specializations, so
> some implicit
> conversion sequences don't work.  It may have been
> premature
> optimization to use specializations here.

Ok, how do you handle conversions of lvalues from c++ ->
python? The to_python converter associated with a UDT does
rvalue conversion and creates a new object, correct?

>
> >> > To do this we need a map<..> lookup to find the
> appropriate
> >> > converter and this really sucks.
> >>
> >> I can't understand why you'd need that, but maybe I'm
> missing
> >> something.  The general mechanism in Boost.Python is
> that
> >> instance_holder::holds(type_info) will give you the
> address of the
> >> contained instance if it's there.
> >
> > Right, we have a map<const type_info*, ..> when
> performing
> > c++ -> lua conversions. You just need to do
> > registered<T>::conversions.to_python(..); Correct?
>
> Roughly speaking, yes.  But what I'm confused about is, if
> you're
> using full compile-time dispatching for from-lua
> conversions, why you
> don't do the same for to-lua conversions.  AFAICT, it's
> the former
> where compile-time dispatch is most useful.  What's the
> 2nd argument
> to the map?

The second argument is a class_rep*, which holds information
about the exposed type. We need this to create the holding
object in lua.

>
> >> > As mentioned before, lua can have multiple states, so
> it would be
> >> > cool if the converters would be bound to the state
> somehow.
> >>
> >> Why?  It doesn't seem like it would be very useful to
> have
> >> different states doing different conversions.
> >
> > It can be useful to be able to register different types
> in different
> > states.
>
> Why?

Because different states might handle completely different
tasks.

>
> > Otherwise class_() would register global types and def()
> > would register local functions. Or am I wrong in
> assuming that
> > class_<T>() instantiates registered<T> and add's a few
> converters?
>
> No, you're correct.  However, it also creates a Python
> type object in
> the extension module's dictionary, just as def() creates
> callable
> python objects in the module's dictionary.  I see the
> converter
> registry as a separate data structure which exists in
> parallel with
> the module's dictionary.  I don't see any reason to have a
> given
> module register different sets of type conversions in
> different
> states, even if it is going to contain different
> types/functions
> (though I can't see why you'd want that either).

As I said earlier, the states can handle different tasks. A
common usage is object scripting in games, but you might in
the same app use lua for parsing configuration files or
scripting the GUI. It's clear that you don't want all these
systems to have access to _everything_.

I guess you could always register types in the global
registry, and only expose them to the states where they are
needed though, if there's not enough reason to use different
converters for the same type in different states.

>
> >> > Anyway, I find your converter system more appealing
> than
> >> > ours. There are some issues which need to be taken
> care of;
> >> > We choose best match, not first match, when trying
> different
> >> > overloads. This means we need to keep the storage for
> the
> >> > converter on the stack of a function that is unaware
> of the
> >> > converter size (at compile time). So we need to
> either have
> >> > a fixed size buffer on the stack, and hope it works,
> or
> >> > allocate the storage at runtime.
> >>
> >> I would love to have best match conversion.  I was
> going to do it
> >> at one point, but realized eventually that users can
> sort the
> >> overloads so that they always work so I never bothered
> to code it.
> >
> > Do you still think best match is worth adding, or is
> sorting an
> > acceptable solution?
>
> I think in many cases, it's more understandable for users
> to be able
> to simply control the order in which converters are tried.
>  It
> certainly is *more efficient* than trying all converters,
> if you're
> going to be truly compulsive about cycles, though I don't
> really care
> about that.  We do have one guy, though, who's got a
> massively
> confusable overload set and I think he's having trouble
> resolving it
> because of the easy conversions between C++ (int, long
> long) and
> Python (int, LONG).
>
>
> http://aspn.activestate.com/ASPN/Mail/Message/1652647
>
> In general, I'd prefer to have more things "just work"
> automatically,
> so yeah I think it's worth adding to Boost.Python.

Ok great.

>
> >> > For clarification:
> >> >
> >> > void dispatcher(..)
> >> > {
> >> >   *storage here*
> >> >   try all overloads
> >> >   call best overload
> >> > }
> >>
> >> I've already figured out how to solve this problem; if
> we can
> >> figure out how to share best-conversion technology I'll
> happily
> >> code it up ;-)
> >
> > :) How would you do it?
>
> I'll give you a hint, if you agree to cooperate on
> best-conversion:

Agreed.

>
> > I guess you could have static storage in the
> match-function and
> > store a pointer to that in the converter data, but that
> wouldn't be
> > thread safe.
>
> OK, here it is, I'll tell you: you use recursion.

Ah, I have considered that too. But at the time it seemed a
bit complex. You would let the 'matcher' functions call the
next matcher, pass the current best-match value along and
return some information that tells you if there's been a
match further down in the recursion, and just let the
matcher call the function when there's no better match
before it on the stack.

Something like that? It doesn't seem that expensive to me,
the recursion won't be very deep anyway.

>
> > Perhaps we should consider parameterizing header
> > files?
> >
> > namespace luabind
> > {
> >   #define BOOST_LANG_CONVERSION_PARAMS \
> >     (2, (lua_State*, int))
> >   #include <blabla/conversions.hpp>
> > }
>
> Hmm, I'm not sure what you're trying to achieve here, but
> that kind of
> parameterization seems unneccessary to me. we probably
> ought to do it
> with templates if there's any chance at all that these
> systems would
> have to be compiled together in some context... though I
> guess with
> inclusion into separate namespaces you could get around
> that.  Well
> OK, let's look at the requirements more carefully before
> we jump into
> implementation details.  I may be willing to accept
> additional state.

Right. The requirement I was aiming to resolve was that we
need a different set of parameters when doing our
conversions. You have your PyObject*, we have our
(lua_State*, int). I thought that parameterizing the
implementation and including in different namespaces would
solve all issues of that type nicely, though there might be
far better solutions.

Here are some notes for the conversion requirements:

 * We need different sets of additional parameters
   passed through the conversion system. And thus we
   need different types of function pointers stored
   in the registry.

 * We need to have separate registries, so that both
   systems can be used at the same time.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Mon, 23 Jun 2003 17:28:03 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056403872 27090 80.91.224.249 (23 Jun 2003 21:31:12 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 21:31:12 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 23:31:11 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UYtq-00071m-00
	for <[email protected]>; Mon, 23 Jun 2003 23:30:55 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UYu2-0004AU-00; Mon, 23 Jun 2003 17:31:06 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19UYts-00043l-00
	for [email protected]; Mon, 23 Jun 2003 17:30:56 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UYsM-0006tv-00
	for <[email protected]>; Mon, 23 Jun 2003 23:29:22 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UYrT-0006ps-00
	for <[email protected]>; Mon, 23 Jun 2003 23:28:27 +0200
Original-Lines: 282
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:+oshuA8I8bNBlbIy/wGWsF3/DEY=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:34
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3535
Lines: 282
X-Gnus-Newsgroup: langbinding-mbox:34   Sat Jul 19 11:05:36 2003

"Daniel Wallin" <[email protected]> writes:

>> "Daniel Wallin" <[email protected]> writes:
>>
>> >> > Instead of doing this we have general converters which is used
>> >> > to convert all user-defined types.
>> >> I have the same thing for most from_python conversions; the
>> >> registry is only used as a fallback in that case.
>> > Hm, doesn't the conversion of UDT's pass through the normal
>> > conversion system?
>>
>> See get_lvalue_from_python in
>> libs/python/src/converter/from_python.cpp.  First it calls
>> find_instance_impl, which will always find a pointer to the right
>> type inside a regular wrapped class if such a pointer is findable.
>> The only thing that gets used from the registration in that case is
>> a type_info object, which has been stored in the registration, as
>> opposed to being passed as a separate parameter, just to minimize
>> the amount of object code generated in extension modules which are
>> invoking the conversion.
>
> Ok. This is roughly what we do too; the pointer is stored in the lua
> object

The pointer to... what? The wrapped object?

> together with a pointer to the class_rep* associated with the
> pointee. The class_rep holds the inheritance tree, so we just
> compare type_info's and traverse the tree to perform the needed
> cast.

I think that problem is a little more complicated than you're making
it out to be, and that your method ends up being slower than it should
be in inheritance graphs of any size.  First of all, inheritance may
be a DAG and you have to prevent infinite loops if you're actually
going to support cross-casting.  Secondly Boost.Python caches cast
sequences so that given the most-derived type of an object, you only
have to search once for a conversion to any other type, and after that
you can do a simple address calculation.  See
libs/python/src/object/inheritance.cpp.  This probably should be
better commented; the algorithms were hard to figure out and I didn't
write down rationale for them :( On the other hand, maybe being fast
isn't important in this part of the code, and the cacheing should be
eliminated ;-)

>> That's for from-python conversions, of course.  For to-python
>> conversions, yes, we nearly always end up consulting the
>> registration for the type.  But that's cheap, after all - there's
>> just a single method for converting any type to python so it just
>> pulls the function pointer out of the registration and invokes it.
>> Compared to the cost of constructing a Python object, an indirect
>> call gets lost in the noise.  The fact that there can only be one
>> way to do that also means that we can introduce some specializations
>> for conversion to python, which bypasses indirection for known types
>> such as int or std::string.  Note however that this bypassing
>> actually has a usability cost because the implicit conversion
>> mechanism actually consults the registration records directly, and
>> I'm not currently filling in the to-python registrations for these
>> types with specializations, so some implicit conversion sequences
>> don't work.  It may have been premature optimization to use
>> specializations here.
>
> Ok, how do you handle conversions of lvalues from c++ -> python? The
> to_python converter associated with a UDT does rvalue conversion and
> creates a new object, correct?

Yeah.  Implicit conversion of lvalues by itself with no ownership
management is dangerous so you have to tell Boost.Python to do it.
I'm sure you know this, though, since luabind supports "parameter
policies."  Bad name, though: a primary reason for these is to manage
return values (which are not parameters).  So I wonder what you're
really asking?

>> >> > To do this we need a map<..> lookup to find the appropriate
>> >> > converter and this really sucks.
>>
>> >> I can't understand why you'd need that, but maybe I'm missing
>> >> something.  The general mechanism in Boost.Python is that
>> >> instance_holder::holds(type_info) will give you the address of
>> >> the contained instance if it's there.
>>
>> > Right, we have a map<const type_info*, ..> when performing c++ ->
>> > lua conversions. You just need to do
>> > registered<T>::conversions.to_python(..); Correct?
>>
>> Roughly speaking, yes.  But what I'm confused about is, if you're
>> using full compile-time dispatching for from-lua conversions, why
>> you don't do the same for to-lua conversions.  AFAICT, it's the
>> former where compile-time dispatch is most useful.  What's the 2nd
>> argument to the map?
>
> The second argument is a class_rep*, which holds information about the
> exposed type. We need this to create the holding object in lua.

Oh, sure.  I don't have such a limited view of to-python conversions
as that.  It's perfectly possible (and often desirable) to register
converters which cause std::vector<X> to be converted to a Python
built-in list of X objects.  It's the converter function itself which
may access the corresponding PyTypeObject (equivalent of class_rep*),
which it will always get through the static initialization trick.

>> >> > As mentioned before, lua can have multiple states, so it would
>> >> > be cool if the converters would be bound to the state somehow.
>>
>> >> Why?  It doesn't seem like it would be very useful to have
>> >> different states doing different conversions.
>>
>> > It can be useful to be able to register different types in
>> > different states.
>>
>> Why?
>
> Because different states might handle completely different tasks.

Sure, but then aren't they going to handle different C++ types and/or
be running different extension modules?  Do you really want the same
C++ type converted differently *by the same extension module* in two
states?

Sounds like premature generalization to me, but I could be wrong.

>> > Otherwise class_() would register global types and def() would
>> > register local functions. Or am I wrong in assuming that
>> > class_<T>() instantiates registered<T> and add's a few
>> > converters?
>>
>> No, you're correct.  However, it also creates a Python type object
>> in the extension module's dictionary, just as def() creates
>> callable python objects in the module's dictionary.  I see the
>> converter registry as a separate data structure which exists in
>> parallel with the module's dictionary.  I don't see any reason to
>> have a given module register different sets of type conversions in
>> different states, even if it is going to contain different
>> types/functions (though I can't see why you'd want that either).
>
> As I said earlier, the states can handle different tasks. A common
> usage is object scripting in games, but you might in the same app use
> lua for parsing configuration files or scripting the GUI. It's clear
> that you don't want all these systems to have access to
> _everything_.

The question of registry isolation is a separate thing, I think.  I am
trying to suggest that a single extension module doesn't need to work
with different conversion registries in different states.

> I guess you could always register types in the global registry, and
> only expose them to the states where they are needed though, if
> there's not enough reason to use different converters for the same
> type in different states.

I'm not committed to the idea of a single registry.  In fact we've
been discussing a hierarchical registry system where converters are
searched starting with a local module registry and proceeding upward
to the package level and finally ending with a global registry as a
fallback.

>> >> > Anyway, I find your converter system more appealing than
>> >> > ours. There are some issues which need to be taken care of; We
>> >> > choose best match, not first match, when trying different
>> >> > overloads. This means we need to keep the storage for the
>> >> > converter on the stack of a function that is unaware of the
>> >> > converter size (at compile time). So we need to either have a
>> >> > fixed size buffer on the stack, and hope it works, or allocate
>> >> > the storage at runtime.
>>
>> >> I would love to have best match conversion.  I was going to do it
>> >> at one point, but realized eventually that users can sort the
>> >> overloads so that they always work so I never bothered to code
>> >> it.
>>
>> > Do you still think best match is worth adding, or is sorting an
>> > acceptable solution?
>>
>> I think in many cases, it's more understandable for users to be
>> able to simply control the order in which converters are tried.  It
>> certainly is *more efficient* than trying all converters, if you're
>> going to be truly compulsive about cycles, though I don't really
>> care about that.  We do have one guy, though, who's got a massively
>> confusable overload set and I think he's having trouble resolving
>> it because of the easy conversions between C++ (int, long long) and
>> Python (int, LONG).
>>
>> http://aspn.activestate.com/ASPN/Mail/Message/1652647
>> In general, I'd prefer to have more things "just work"
>> automatically, so yeah I think it's worth adding to Boost.Python.
>
> Ok great.
>>
>> >> > For clarification:
>> >> > void dispatcher(..)  { *storage here* try all overloads call best
>> >> > overload }
>> >> I've already figured out how to solve this problem; if we can
>> >> figure out how to share best-conversion technology I'll happily
>> >> code it up ;-)
>> > :) How would you do it?
>> I'll give you a hint, if you agree to cooperate on best-conversion:
>
> Agreed.

OK.

>>
>> > I guess you could have static storage in the match-function and
>> > store a pointer to that in the converter data, but that wouldn't
>> > be thread safe.
>> OK, here it is, I'll tell you: you use recursion.
>
> Ah, I have considered that too. 

Great minds think alike ;-)

> But at the time it seemed a bit complex. You would let the 'matcher'
> functions call the next matcher, pass the current best-match value
> along and return some information that tells you if there's been a
> match further down in the recursion, and just let the matcher call
> the function when there's no better match before it on the stack.
> Something like that?

Yes, something like that.  I don't really think it's too
complicated.  My big problem was trying to figure out a scheme for
assigning match quality.  C++ uses a kind of "substitutaiblity" rule
for resolving partial ordering which seemed like a good way to handle
things.  How do you do it?

> It doesn't seem that expensive to me, the recursion won't be very
> deep anyway.

I agree; it's rare to have huge overload sets.p

>> > Perhaps we should consider parameterizing header files?
>> > namespace luabind { #define BOOST_LANG_CONVERSION_PARAMS \ (2,
>> > (lua_State*, int)) #include <blabla/conversions.hpp> }
>>
>> Hmm, I'm not sure what you're trying to achieve here, but that kind
>> of parameterization seems unneccessary to me. we probably ought to
>> do it with templates if there's any chance at all that these
>> systems would have to be compiled together in some
>> context... though I guess with inclusion into separate namespaces
>> you could get around that.  Well OK, let's look at the requirements
>> more carefully before we jump into implementation details.  I may
>> be willing to accept additional state.
>
> Right. The requirement I was aiming to resolve was that we need a
> different set of parameters when doing our conversions. 

I consider that an implementation detail ;-)

> You have your PyObject*, we have our (lua_State*, int).

What's the int?

> I thought that parameterizing the implementation and including in
> different namespaces would solve all issues of that type nicely,
> though there might be far better solutions.

Maybe; I think there are lots of strategies available and which is
best probably depends on the other issues we need to address.

> Here are some notes for the conversion requirements:
>
>  * We need different sets of additional parameters passed through the
> conversion system. And thus we need different types of function
> pointers stored in the registry.

Sure.

>  * We need to have separate registries, so that both systems can be
> used at the same time.

We need separate registries within Boost.Python too; we just don't
have them, yet.  There's also a potential issue with thread safety if
you have modules using the same registry initializing concurrently.
With a single Python interpreter state, it's not an issue, since
extension module code is always entered on the main thread until a
mutex is explicitly released.  Anyway, I want to discuss the whole
issue of registry isolation in the larger context of what's desirable
for both systems and their evolution into the future.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Mon, 23 Jun 2003 21:36:30 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056400614 9844 80.91.224.249 (23 Jun 2003 20:36:54 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 20:36:54 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 22:36:52 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UY3Y-0002YV-00
	for <[email protected]>; Mon, 23 Jun 2003 22:36:52 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UY3l-0004iy-00; Mon, 23 Jun 2003 16:37:05 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UY3E-000404-00
	for [email protected]; Mon, 23 Jun 2003 16:36:32 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5NKaVe3003066;
	Mon, 23 Jun 2003 22:36:31 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:35
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3533
Lines: 33
X-Gnus-Newsgroup: langbinding-mbox:35   Sat Jul 19 11:05:36 2003

> "Daniel Wallin" <[email protected]> writes:
>
> >> Again I can only offer a second-hand view. IIUC, on
> some platforms
> >> it is possible to compare type_info objects across dll
> boundaries as
> >> if they are in the same static link unit. I.e. there is
> nothing
> >> special. On some platforms this is not possible, and
> type_id::name
> >> is used instead.  There is only one platform where
> relying on
> >> type_id::name caused a bit of a hick-up, namely
> IRIX/MIPSpro. See
> >> the comment near the top of the flew_fwd.h file (link
> in my previous
> >> message).
> >
> > Ok. I guess you could unmangle the names to a
> standardized format if
> > there are problems with this?
>
> No :(
>
> Sadly, the problem is that typedefs don't always get
> fully-unwound in
> type_info names, e.g.:

Oh, ok. So you would need to unwound the types manually with
specialization.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Mon, 23 Jun 2003 17:30:18 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056404582 30973 80.91.224.249 (23 Jun 2003 21:43:02 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 21:43:02 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 23:42:58 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UZ4T-0007xv-00
	for <[email protected]>; Mon, 23 Jun 2003 23:41:53 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UZ4g-0000ZQ-00; Mon, 23 Jun 2003 17:42:06 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19UZ3z-0008Gr-00
	for [email protected]; Mon, 23 Jun 2003 17:41:23 -0400
Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UZ2s-0007r1-00
	for <[email protected]>; Mon, 23 Jun 2003 23:40:14 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UYtd-00071N-00
	for <[email protected]>; Mon, 23 Jun 2003 23:30:41 +0200
Original-Lines: 45
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:NeMW+UIJ1VxWZb9/OG4T2CjYim4=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:36
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3536
Lines: 45
X-Gnus-Newsgroup: langbinding-mbox:36   Sat Jul 19 11:05:36 2003

"Daniel Wallin" <[email protected]> writes:

>> "Daniel Wallin" <[email protected]> writes:
>>
>> >> Again I can only offer a second-hand view. IIUC, on
>> some platforms
>> >> it is possible to compare type_info objects across dll
>> boundaries as
>> >> if they are in the same static link unit. I.e. there is
>> nothing
>> >> special. On some platforms this is not possible, and
>> type_id::name
>> >> is used instead.  There is only one platform where
>> relying on
>> >> type_id::name caused a bit of a hick-up, namely
>> IRIX/MIPSpro. See
>> >> the comment near the top of the flew_fwd.h file (link
>> in my previous
>> >> message).
>> >
>> > Ok. I guess you could unmangle the names to a
>> standardized format if
>> > there are problems with this?
>>
>> No :(
>>
>> Sadly, the problem is that typedefs don't always get
>> fully-unwound in
>> type_info names, e.g.:
>
> Oh, ok. So you would need to unwound the types manually with
> specialization.

That doesn't even work the way you expect; they don't neccessarily
unwind completely.  It's just a matter of exposing one way to get the
type at the beginning of every translation unit.  But it works,
eventually, though it's ugly as sin.  Fortunately EDG knows about
this and has fixed the problem in their compiler.  Unfortunately it's
unclear when SGI will release anything that works based on a modern
EDG. :(

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Mon, 23 Jun 2003 21:37:51 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056400766 10668 80.91.224.249 (23 Jun 2003 20:39:26 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Mon, 23 Jun 2003 20:39:26 +0000 (UTC)
Original-X-From: [email protected] Mon Jun 23 22:39:19 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UY5u-0002l3-00
	for <[email protected]>; Mon, 23 Jun 2003 22:39:19 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UY67-0006NE-00; Mon, 23 Jun 2003 16:39:31 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UY4X-00058V-00
	for [email protected]; Mon, 23 Jun 2003 16:37:53 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5NKbqe3003549;
	Mon, 23 Jun 2003 22:37:52 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:37
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3534
Lines: 45
X-Gnus-Newsgroup: langbinding-mbox:37   Sat Jul 19 11:05:36 2003

> --- Daniel Wallin <[email protected]> wrote:
> > > Again I can only offer a second-hand view. IIUC, on
> some
> > > platforms it is
> > > possible to compare type_info objects across dll
> > > boundaries as if they
> > > are in the same static link unit. I.e. there is
> nothing
> > > special. On some
> > > platforms this is not possible, and type_id::name is
> used
> > > instead.
> > > There is only one platform where relying on
> type_id::name
> > > caused a bit
> > > of a hick-up, namely IRIX/MIPSpro. See the comment
> near
> > > the top of the
> > > flew_fwd.h file (link in my previous message).
> >
> > Ok. I guess you could unmangle the names to a
> standardized
> > format if there are problems with this?
>
> Yes, as a last resort we could, e.g., manually specialize
> boost::python::type_info (in boost/python/type_id.h) for
> all types
> using the cross-module feature. Fortunately that has not
> been
> necessary so far. And I don't see why it should ever be
> necessary
> in hypothetical new platforms since there is TTBOMK no
> technical reason
> for enforcing inconsistent type_id::name results. I.e. if
> we just tell
> the developers of new platforms what we are using
> type_id::name for
> it will most be likely easy for them to give us what we
> need.

Right. It seems the problems with this are far smaller than
I thought..

--
Daniel Wallin
From nobody Sat Jul 19 11:05:36 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Tue, 24 Jun 2003 11:35:56 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056451015 30547 80.91.224.249 (24 Jun 2003 10:36:55 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 24 Jun 2003 10:36:55 +0000 (UTC)
Original-X-From: [email protected] Tue Jun 24 12:36:52 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UlAS-0007wD-00
	for <[email protected]>; Tue, 24 Jun 2003 12:36:52 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UlAf-0006Xj-00; Tue, 24 Jun 2003 06:37:05 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Ul9a-0006MP-00
	for [email protected]; Tue, 24 Jun 2003 06:35:58 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5OAZue3000213;
	Tue, 24 Jun 2003 12:35:56 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:38
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3539
Lines: 494
X-Gnus-Newsgroup: langbinding-mbox:38   Sat Jul 19 11:05:37 2003

> "Daniel Wallin" <[email protected]> writes:
>
> >> "Daniel Wallin" <[email protected]> writes:
> >>
> >> >> > Instead of doing this we have general converters
> which is used
> >> >> > to convert all user-defined types.
> >> >> I have the same thing for most from_python
> conversions; the
> >> >> registry is only used as a fallback in that case.
> >> > Hm, doesn't the conversion of UDT's pass through the
> normal
> >> > conversion system?
> >>
> >> See get_lvalue_from_python in
> >> libs/python/src/converter/from_python.cpp.  First it
> calls
> >> find_instance_impl, which will always find a pointer to
> the right
> >> type inside a regular wrapped class if such a pointer
> is findable.
> >> The only thing that gets used from the registration in
> that case is
> >> a type_info object, which has been stored in the
> registration, as
> >> opposed to being passed as a separate parameter, just
> to minimize
> >> the amount of object code generated in extension
> modules which are
> >> invoking the conversion.
> >
> > Ok. This is roughly what we do too; the pointer is
> stored in the lua
> > object
>
> The pointer to... what? The wrapped object?

Right.

>
> > together with a pointer to the class_rep* associated
> with the
> > pointee. The class_rep holds the inheritance tree, so we
> just
> > compare type_info's and traverse the tree to perform the
> needed
> > cast.
>
> I think that problem is a little more complicated than
> you're making
> it out to be, and that your method ends up being slower
> than it should
> be in inheritance graphs of any size.  First of all,
> inheritance may
> be a DAG and you have to prevent infinite loops if you're
> actually
> going to support cross-casting.  Secondly Boost.Python
> caches cast
> sequences so that given the most-derived type of an
> object, you only
> have to search once for a conversion to any other type,
> and after that
> you can do a simple address calculation.  See
> libs/python/src/object/inheritance.cpp.  This probably
> should be
> better commented; the algorithms were hard to figure out
> and I didn't
> write down rationale for them :( On the other hand, maybe
> being fast
> isn't important in this part of the code, and the cacheing
> should be
> eliminated ;-)

We only support upcasting, so our method isn't that slow.
Generally it's just a linked list traversal. We don't cache
though, and caching is a good thing. :)

>
> >> That's for from-python conversions, of course.  For
> to-python
> >> conversions, yes, we nearly always end up consulting
> the
> >> registration for the type.  But that's cheap, after all
> - there's
> >> just a single method for converting any type to python
> so it just
> >> pulls the function pointer out of the registration and
> invokes it.
> >> Compared to the cost of constructing a Python object,
> an indirect
> >> call gets lost in the noise.  The fact that there can
> only be one
> >> way to do that also means that we can introduce some
> specializations
> >> for conversion to python, which bypasses indirection
> for known types
> >> such as int or std::string.  Note however that this
> bypassing
> >> actually has a usability cost because the implicit
> conversion
> >> mechanism actually consults the registration records
> directly, and
> >> I'm not currently filling in the to-python
> registrations for these
> >> types with specializations, so some implicit conversion
> sequences
> >> don't work.  It may have been premature optimization to
> use
> >> specializations here.
> >
> > Ok, how do you handle conversions of lvalues from c++ ->
> python? The
> > to_python converter associated with a UDT does rvalue
> conversion and
> > creates a new object, correct?
>
> Yeah.  Implicit conversion of lvalues by itself with no
> ownership
> management is dangerous so you have to tell Boost.Python
> to do it.
> I'm sure you know this, though, since luabind supports
> "parameter
> policies."  Bad name, though: a primary reason for these
> is to manage
> return values (which are not parameters).  So I wonder
> what you're
> really asking?

We convert lvalues to lua with no management by default. I
don't think this is more dangerous than copying the objects,
it's just seg faults instead of silent errors. Both ways are
equaly easy to make mistakes with.

Our policies primary reason is not to handle return values,
but to handle conversion in both directions. For example,
adopt() can be used to steal objects that are owned by the
interpreter.

void f(A*);
def("f", &f, adopt(_1))

But yes, the name should indicate both directions..
ConversionPolicy perhaps.

>
> >> >> > To do this we need a map<..> lookup to find the
> appropriate
> >> >> > converter and this really sucks.
> >>
> >> >> I can't understand why you'd need that, but maybe
> I'm missing
> >> >> something.  The general mechanism in Boost.Python is
> that
> >> >> instance_holder::holds(type_info) will give you the
> address of
> >> >> the contained instance if it's there.
> >>
> >> > Right, we have a map<const type_info*, ..> when
> performing c++ ->
> >> > lua conversions. You just need to do
> >> > registered<T>::conversions.to_python(..); Correct?
> >>
> >> Roughly speaking, yes.  But what I'm confused about is,
> if you're
> >> using full compile-time dispatching for from-lua
> conversions, why
> >> you don't do the same for to-lua conversions.  AFAICT,
> it's the
> >> former where compile-time dispatch is most useful.
> What's the 2nd
> >> argument to the map?
> >
> > The second argument is a class_rep*, which holds
> information about the
> > exposed type. We need this to create the holding object
> in lua.
>
> Oh, sure.  I don't have such a limited view of to-python
> conversions
> as that.  It's perfectly possible (and often desirable) to
> register
> converters which cause std::vector<X> to be converted to a
> Python
> built-in list of X objects.  It's the converter function
> itself which
> may access the corresponding PyTypeObject (equivalent of
> class_rep*),
> which it will always get through the static initialization
> trick.

Right, in our case it's also the converter that may access
the class_rep*, and it is also possible to create converters
which maps std::vector<X> <-> lua table. So we seem to be
doing pretty much the same thing here. Except we access it
with a map<..> and you do it alot faster. :)

>
> >> >> > As mentioned before, lua can have multiple states,
> so it would
> >> >> > be cool if the converters would be bound to the
> state somehow.
> >>
> >> >> Why?  It doesn't seem like it would be very useful
> to have
> >> >> different states doing different conversions.
> >>
> >> > It can be useful to be able to register different
> types in
> >> > different states.
> >>
> >> Why?
> >
> > Because different states might handle completely
> different tasks.
>
> Sure, but then aren't they going to handle different C++
> types and/or
> be running different extension modules?  Do you really
> want the same
> C++ type converted differently *by the same extension
> module* in two
> states?
>
> Sounds like premature generalization to me, but I could be
> wrong.

I don't know.. It does seem reasonable to not allow
different conversions for the same type.
>
> >> > Otherwise class_() would register global types and
> def() would
> >> > register local functions. Or am I wrong in assuming
> that
> >> > class_<T>() instantiates registered<T> and add's a
> few
> >> > converters?
> >>
> >> No, you're correct.  However, it also creates a Python
> type object
> >> in the extension module's dictionary, just as def()
> creates
> >> callable python objects in the module's dictionary.  I
> see the
> >> converter registry as a separate data structure which
> exists in
> >> parallel with the module's dictionary.  I don't see any
> reason to
> >> have a given module register different sets of type
> conversions in
> >> different states, even if it is going to contain
> different
> >> types/functions (though I can't see why you'd want that
> either).
> >
> > As I said earlier, the states can handle different
> tasks. A common
> > usage is object scripting in games, but you might in the
> same app use
> > lua for parsing configuration files or scripting the
> GUI. It's clear
> > that you don't want all these systems to have access to
> > _everything_.
>
> The question of registry isolation is a separate thing, I
> think.  I am
> trying to suggest that a single extension module doesn't
> need to work
> with different conversion registries in different states.
>
> > I guess you could always register types in the global
> registry, and
> > only expose them to the states where they are needed
> though, if
> > there's not enough reason to use different converters
> for the same
> > type in different states.
>
> I'm not committed to the idea of a single registry.  In
> fact we've
> been discussing a hierarchical registry system where
> converters are
> searched starting with a local module registry and
> proceeding upward
> to the package level and finally ending with a global
> registry as a
> fallback.

Right, that seems reasonable.

>
> >> >> > Anyway, I find your converter system more
> appealing than
> >> >> > ours. There are some issues which need to be taken
> care of; We
> >> >> > choose best match, not first match, when trying
> different
> >> >> > overloads. This means we need to keep the storage
> for the
> >> >> > converter on the stack of a function that is
> unaware of the
> >> >> > converter size (at compile time). So we need to
> either have a
> >> >> > fixed size buffer on the stack, and hope it works,
> or allocate
> >> >> > the storage at runtime.
> >>
> >> >> I would love to have best match conversion.  I was
> going to do it
> >> >> at one point, but realized eventually that users can
> sort the
> >> >> overloads so that they always work so I never
> bothered to code
> >> >> it.
> >>
> >> > Do you still think best match is worth adding, or is
> sorting an
> >> > acceptable solution?
> >>
> >> I think in many cases, it's more understandable for
> users to be
> >> able to simply control the order in which converters
> are tried.  It
> >> certainly is *more efficient* than trying all
> converters, if you're
> >> going to be truly compulsive about cycles, though I
> don't really
> >> care about that.  We do have one guy, though, who's got
> a massively
> >> confusable overload set and I think he's having trouble
> resolving
> >> it because of the easy conversions between C++ (int,
> long long) and
> >> Python (int, LONG).
> >>
> >> http://aspn.activestate.com/ASPN/Mail/Message/1652647
> >> In general, I'd prefer to have more things "just work"
> >> automatically, so yeah I think it's worth adding to
> Boost.Python.
> >
> > Ok great.
> >>
> >> >> > For clarification:
> >> >> > void dispatcher(..)  { *storage here* try all
> overloads call best
> >> >> > overload }
> >> >> I've already figured out how to solve this problem;
> if we can
> >> >> figure out how to share best-conversion technology
> I'll happily
> >> >> code it up ;-)
> >> > :) How would you do it?
> >> I'll give you a hint, if you agree to cooperate on
> best-conversion:
> >
> > Agreed.
>
> OK.
>
> >>
> >> > I guess you could have static storage in the
> match-function and
> >> > store a pointer to that in the converter data, but
> that wouldn't
> >> > be thread safe.
> >> OK, here it is, I'll tell you: you use recursion.
> >
> > Ah, I have considered that too.
>
> Great minds think alike ;-)
>
> > But at the time it seemed a bit complex. You would let
> the 'matcher'
> > functions call the next matcher, pass the current
> best-match value
> > along and return some information that tells you if
> there's been a
> > match further down in the recursion, and just let the
> matcher call
> > the function when there's no better match before it on
> the stack.
> > Something like that?
>
> Yes, something like that.  I don't really think it's too
> complicated.  My big problem was trying to figure out a
> scheme for
> assigning match quality.  C++ uses a kind of
> "substitutaiblity" rule
> for resolving partial ordering which seemed like a good
> way to handle
> things.  How do you do it?

We just let every converter return a value indicating how
good the match was, where 0 is perfect match and -1 is no
match. When performing implicit conversions, every step in
the conversions inreases the match value.

Maybe I'm naive, but is there need for anything more
complicated?

>
> > It doesn't seem that expensive to me, the recursion
> won't be very
> > deep anyway.
>
> I agree; it's rare to have huge overload sets.p
>
> >> > Perhaps we should consider parameterizing header
> files?
> >> > namespace luabind { #define
> BOOST_LANG_CONVERSION_PARAMS \ (2,
> >> > (lua_State*, int)) #include <blabla/conversions.hpp>
> }
> >>
> >> Hmm, I'm not sure what you're trying to achieve here,
> but that kind
> >> of parameterization seems unneccessary to me. we
> probably ought to
> >> do it with templates if there's any chance at all that
> these
> >> systems would have to be compiled together in some
> >> context... though I guess with inclusion into separate
> namespaces
> >> you could get around that.  Well OK, let's look at the
> requirements
> >> more carefully before we jump into implementation
> details.  I may
> >> be willing to accept additional state.
> >
> > Right. The requirement I was aiming to resolve was that
> we need a
> > different set of parameters when doing our conversions.
>
> I consider that an implementation detail ;-)
>
> > You have your PyObject*, we have our (lua_State*, int).
>
> What's the int?

An index to the object being converted on the lua stack.

>
> > I thought that parameterizing the implementation and
> including in
> > different namespaces would solve all issues of that type
> nicely,
> > though there might be far better solutions.
>
> Maybe; I think there are lots of strategies available and
> which is
> best probably depends on the other issues we need to
> address.
>
> > Here are some notes for the conversion requirements:
> >
> >  * We need different sets of additional parameters
> passed through the
> > conversion system. And thus we need different types of
> function
> > pointers stored in the registry.
>
> Sure.
>
> >  * We need to have separate registries, so that both
> systems can be
> > used at the same time.
>
> We need separate registries within Boost.Python too; we
> just don't
> have them, yet.  There's also a potential issue with
> thread safety if
> you have modules using the same registry initializing
> concurrently.
> With a single Python interpreter state, it's not an issue,
> since
> extension module code is always entered on the main thread
> until a
> mutex is explicitly released.  Anyway, I want to discuss
> the whole
> issue of registry isolation in the larger context of
> what's desirable
> for both systems and their evolution into the future.

Right. For luabind it seems reasonable to accept a single
registry for every module, and perhaps global registry used
by interacting modules as well.

It doesn't seem that interesting to register different
conversions for different states anymore. (at least not to
me, but I could be wrong..). But if we where to increase the
isolation of the registries, each state could just as well
get their own registry.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Tue, 24 Jun 2003 07:54:53 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056455762 21191 80.91.224.249 (24 Jun 2003 11:56:02 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 24 Jun 2003 11:56:02 +0000 (UTC)
Original-X-From: [email protected] Tue Jun 24 13:55:53 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UmOu-0005Ur-00
	for <[email protected]>; Tue, 24 Jun 2003 13:55:52 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UmP7-0007j5-00; Tue, 24 Jun 2003 07:56:05 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19UmOe-0007hp-00
	for [email protected]; Tue, 24 Jun 2003 07:55:36 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UmOO-0005Rh-00
	for <[email protected]>; Tue, 24 Jun 2003 13:55:20 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UmOM-0005RU-00
	for <[email protected]>; Tue, 24 Jun 2003 13:55:18 +0200
Original-Lines: 236
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:XwE0orw9noPNoE+Cw/yKuof0glM=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:39
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3542
Lines: 236
X-Gnus-Newsgroup: langbinding-mbox:39   Sat Jul 19 11:05:37 2003

Daniel,

[Please try to cut out irrelevant quoting; thanks]

"Daniel Wallin" <[email protected]> writes:

>> "Daniel Wallin" <[email protected]> writes:
>>
>> > together with a pointer to the class_rep* associated
>> > with the pointee. The class_rep holds the inheritance
>> > tree, so we just compare type_info's and traverse the
>> > tree to perform the needed cast.
>>
>> I think that problem is a little more complicated than
>> you're making it out to be, and that your method ends up
>> being slower than it should be in inheritance graphs of
>> any size.  First of all, inheritance may be a DAG and you
>> have to prevent infinite loops if you're actually going
>> to support cross-casting.  Secondly Boost.Python caches
>> cast sequences so that given the most-derived type of an
>> object, you only have to search once for a conversion to
>> any other type, and after that you can do a simple
>> address calculation.  See
>> libs/python/src/object/inheritance.cpp.  This probably
>> should be better commented; the algorithms were hard to
>> figure out and I didn't write down rationale for them :(
>> On the other hand, maybe being fast isn't important in
>> this part of the code, and the cacheing should be
>> eliminated ;-)
>
> We only support upcasting, so our method isn't that slow.  

Surely you want to be able to go in both directions, though?
Surely not everyone using lua is interested in just speed
and not usability?

> Generally it's just a linked list traversal. We don't
> cache though, and caching is a good thing. :)

Yeah, probably.  It would be good to share all of that.

>> > Ok, how do you handle conversions of lvalues from c++
>> > -> python?  The to_python converter associated with a
>> > UDT does rvalue conversion and creates a new object,
>> > correct?
>>
>> Yeah.  Implicit conversion of lvalues by itself with no
>> ownership management is dangerous so you have to tell
>> Boost.Python to do it.  I'm sure you know this, though,
>> since luabind supports "parameter policies."  Bad name,
>> though: a primary reason for these is to manage return
>> values (which are not parameters).  So I wonder what
>> you're really asking?
>
> We convert lvalues to lua with no management by default. I
> don't think this is more dangerous than copying the
> objects, it's just seg faults instead of silent
> errors. 

<shiver>
Your way, mistakes by the user of the *interpreter* can
easily crash the system.  My way, only the guy/gal doing the
wrapping has to be careful:

         >>> x = X()
         >>> z = x.y
         >>> del x
         >>> z.foo()  # crash

The users of these interpreted environments have an
expectation that their interpreter won't *crash* just
because of the way they've used it.
</shiver>

> Both ways are equaly easy to make mistakes with.

Totally disagree.  Done my way, we force the guy/gal to
consider whether he really wants to do something unsafe
before he does it.  You probably think I copy objects by
default, but I don't. That was BPLv1.  In BPLv2 I issue an
error unless the user supplies a call policy.

Finally, let me point out that although we currently use
Python weak references to accomplish this I realized last
night that there's a *much* easier and more-efficient way
to do it using a special kind of smart pointer to refer to
the referenced object.

> Our policies primary reason is not to handle return
> values, but to handle conversion in both directions. For
> example, adopt() can be used to steal objects that are
> owned by the interpreter.
>
> void f(A*); def("f", &f, adopt(_1))

What, you just leak a reference here?  Or is it something
else?  I had a major client who was sure he was going to
need to leak references, but he eventually discovered that
the provided call policies could always be made to do
something more-intelligent, so I never put the
reference-leaker in the library.  I haven't had a single
request for it since, either.

> But yes, the name should indicate both
> directions..  ConversionPolicy perhaps.

Hmm, this is really very specific to calls, because it
*does* manage arguments and return values.  I really think
CallPolicy is better.  In any case I think we should
converge on this, one way or another; there will be more
languages, and you do want to be able to steal my users,
right? <wink>.  That'll be a lot easier if they see
familiar terminology ;-)

>> Oh, sure.  I don't have such a limited view of to-python
>> conversions as that.  It's perfectly possible (and often
>> desirable) to register converters which cause
>> std::vector<X> to be converted to a Python built-in list
>> of X objects.  It's the converter function itself which
>> may access the corresponding PyTypeObject (equivalent of
>> class_rep*), which it will always get through the static
>> initialization trick.
>
> Right, in our case it's also the converter that may access
> the class_rep*, and it is also possible to create
> converters which maps std::vector<X> <-> lua table. So we
> seem to be doing pretty much the same thing here. Except
> we access it with a map<..> and you do it alot faster. :)

OK.

>> >> >> > As mentioned before, lua can have multiple
>> >> >> > states, so it would be cool if the converters
>> >> >> > would be bound to the state somehow.
>> >>
>> >> >> Why?  It doesn't seem like it would be very useful
>> >> >> to have different states doing different
>> >> >> conversions.
>> >>
>> >> > It can be useful to be able to register different
>> >> > types in different states.
>>
>> >> Why?
>>
>> > Because different states might handle completely
>> > different tasks.
>>
>> Sure, but then aren't they going to handle different C++
>> types and/or be running different extension modules?  Do
>> you really want the same C++ type converted differently
>> *by the same extension module* in two states?  Sounds
>> like premature generalization to me, but I could be
>> wrong.
>
> I don't know.. It does seem reasonable to not allow
> different conversions for the same type.

Phew! ;-)

>> I'm not committed to the idea of a single registry.  In
>> fact we've been discussing a hierarchical registry system
>> where converters are searched starting with a local
>> module registry and proceeding upward to the package
>> level and finally ending with a global registry as a
>> fallback.
>
> Right, that seems reasonable.

Cool.  And let me also point out that if the module doesn't
have to collaborate with other modules, you don't even need
a registry lookup at static initialization time.  A static
data member of a class template is enough to create an area
of storage associated with a C++ type.  There's no central
registry at all in that case.  I have grave doubts about
whether it's worth special-casing the code for this, but it
might make threading easier to cope with.

>> My big problem was trying to figure out a scheme for
>> assigning match quality.  C++ uses a kind of
>> "substitutaiblity" rule for resolving partial ordering
>> which seemed like a good way to handle things.  How do
>> you do it?
>
> We just let every converter return a value indicating how
> good the match was, where 0 is perfect match and -1 is no
> match. When performing implicit conversions, every step in
> the conversions inreases the match value.
>
> Maybe I'm naive, but is there need for anything more complicated?

Well, it's the "multimethod problem": consider base and
derived class formal arguments which both match an actual
argument, or int <--> float conversions.  How much do you
increase the match value by for a particular match?

>> > Right. The requirement I was aiming to resolve was that we need a
>> > different set of parameters when doing our conversions.
>>
>> I consider that an implementation detail ;-)
>>
>> > You have your PyObject*, we have our (lua_State*, int).
>>
>> What's the int?
>
> An index to the object being converted on the lua stack.

Oh, I guess lua hasn't handed you a pointer to an object at
that point?  Well, OK.

>> We need separate registries within Boost.Python too; we
>> just don't have them, yet.  There's also a potential
>> issue with thread safety if you have modules using the
>> same registry initializing concurrently.  With a single
>> Python interpreter state, it's not an issue, since
>> extension module code is always entered on the main
>> thread until a mutex is explicitly released.  Anyway, I
>> want to discuss the whole issue of registry isolation in
>> the larger context of what's desirable for both systems
>> and their evolution into the future.
>
> Right. For luabind it seems reasonable to accept a single
> registry for every module, and perhaps global registry
> used by interacting modules as well.
>
> It doesn't seem that interesting to register different
> conversions for different states anymore. (at least not to
> me, but I could be wrong..). But if we where to increase
> the isolation of the registries, each state could just as
> well get their own registry.

Let's continue poking at the issues until we get clarity.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: "Ralf W. Grosse-Kunstleve" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Tue, 24 Jun 2003 05:47:55 -0700 (PDT)
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056458887 4119 80.91.224.249 (24 Jun 2003 12:48:07 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 24 Jun 2003 12:48:07 +0000 (UTC)
Original-X-From: [email protected] Tue Jun 24 14:48:02 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UnDN-000143-00
	for <[email protected]>; Tue, 24 Jun 2003 14:48:01 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UnDb-0001gJ-00; Tue, 24 Jun 2003 08:48:15 -0400
Original-Received: from web20209.mail.yahoo.com ([216.136.226.64])
	by mail.python.org with smtp (Exim 4.05)
	id 19UnDJ-0001U9-00
	for [email protected]; Tue, 24 Jun 2003 08:47:57 -0400
Original-Received: from [12.208.26.202] by web20209.mail.yahoo.com via HTTP; Tue, 24 Jun 2003 05:47:55 PDT
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:40
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3544
Lines: 29
X-Gnus-Newsgroup: langbinding-mbox:40   Sat Jul 19 11:05:37 2003

--- David Abrahams <[email protected]> wrote:
> <shiver>
> Your way, mistakes by the user of the *interpreter* can
> easily crash the system.  My way, only the guy/gal doing the
> wrapping has to be careful:
> 
>          >>> x = X()
>          >>> z = x.y
>          >>> del x
>          >>> z.foo()  # crash
> 
> The users of these interpreted environments have an
> expectation that their interpreter won't *crash* just
> because of the way they've used it.
> </shiver>

As a user who (finally!) writes mainly new Python code I really value
the safe-but-certain approach. If the interpreter crashes somewhere deep
down in the application without printing a backtrace it is often very
frustrating and time-consuming to isolate the problem by adding print
statements. In a large-scale application it is crucial that all
components are rock-solid.
Ralf


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: "Ralf W. Grosse-Kunstleve" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Tue, 24 Jun 2003 07:23:48 -0700 (PDT)
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056464804 4065 80.91.224.249 (24 Jun 2003 14:26:44 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 24 Jun 2003 14:26:44 +0000 (UTC)
Original-X-From: [email protected] Tue Jun 24 16:26:43 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19Uoi8-0000nB-00
	for <[email protected]>; Tue, 24 Jun 2003 16:23:53 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UoiM-0005eS-00; Tue, 24 Jun 2003 10:24:06 -0400
Original-Received: from web20206.mail.yahoo.com ([216.136.226.61])
	by mail.python.org with smtp (Exim 4.05)
	id 19Uoi5-0005dl-00
	for [email protected]; Tue, 24 Jun 2003 10:23:49 -0400
Original-Received: from [12.208.26.202] by web20206.mail.yahoo.com via HTTP; Tue, 24 Jun 2003 07:23:48 PDT
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:41
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3547
Lines: 11
X-Gnus-Newsgroup: langbinding-mbox:41   Sat Jul 19 11:05:37 2003

--- "Ralf W. Grosse-Kunstleve" <[email protected]> wrote:
> the safe-but-certain approach. If the interpreter crashes somewhere deep
      ^^^^^^^^^^^^^^^^

Oops, what was I thinking?!?


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Tue, 24 Jun 2003 11:21:47 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056468856 27555 80.91.224.249 (24 Jun 2003 15:34:16 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 24 Jun 2003 15:34:16 +0000 (UTC)
Original-X-From: [email protected] Tue Jun 24 17:34:11 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UpoB-0007A3-00
	for <[email protected]>; Tue, 24 Jun 2003 17:34:11 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Upn7-0001c7-00; Tue, 24 Jun 2003 11:33:05 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19Upll-0000VD-00
	for [email protected]; Tue, 24 Jun 2003 11:31:41 -0400
Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UpkI-0006ps-00
	for <[email protected]>; Tue, 24 Jun 2003 17:30:10 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UpcZ-0006Di-00
	for <[email protected]>; Tue, 24 Jun 2003 17:22:11 +0200
Original-Lines: 14
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:m62ly987y7AeGpeXmseEkNehTE4=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:42
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3549
Lines: 14
X-Gnus-Newsgroup: langbinding-mbox:42   Sat Jul 19 11:05:37 2003

"Ralf W. Grosse-Kunstleve" <[email protected]> writes:

> --- "Ralf W. Grosse-Kunstleve" <[email protected]> wrote:
>> the safe-but-certain approach. If the interpreter crashes somewhere deep
>       ^^^^^^^^^^^^^^^^
>
> Oops, what was I thinking?!?

Not sure.  What's the matter with what you wrote?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: Nicodemus <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Tue, 24 Jun 2003 16:28:22 -0300
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1056482938 2714 80.91.224.249 (24 Jun 2003 19:28:58 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 24 Jun 2003 19:28:58 +0000 (UTC)
Original-X-From: [email protected] Tue Jun 24 21:28:54 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UtTJ-0000hV-00
	for <[email protected]>; Tue, 24 Jun 2003 21:28:54 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UtTW-0005N9-00; Tue, 24 Jun 2003 15:29:06 -0400
Original-Received: from terra.inf.ufsc.br ([150.162.60.10])
	by mail.python.org with esmtp (Exim 4.05)
	id 19UtT1-0005K6-00
	for [email protected]; Tue, 24 Jun 2003 15:28:35 -0400
Original-Received: from localhost (localhost [127.0.0.1])
	by terra.inf.ufsc.br (Departamento de Informatica e Estatistica (INE/CTC/UFSC)) with ESMTP id 1174B193D4
	for <[email protected]>; Tue, 24 Jun 2003 16:28:30 -0300 (BRT)
Original-Received: from globalite.com.br (200-180-008-093.fnsce7002.dsl.brasiltelecom.net.br [200.180.8.93])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by terra.inf.ufsc.br (Departamento de Informatica e Estatistica (INE/CTC/UFSC)) with ESMTP id 3E4D8190FD
	for <[email protected]>; Tue, 24 Jun 2003 16:28:24 -0300 (BRT)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
Original-To: [email protected]
In-Reply-To: <[email protected]>
X-Virus-Scanned: by AMaViS 0.3.12pre5
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:43
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3553
Lines: 38
X-Gnus-Newsgroup: langbinding-mbox:43   Sat Jul 19 11:05:37 2003

Ralf W. Grosse-Kunstleve wrote:

>--- David Abrahams <[email protected]> wrote:
>  
>
>><shiver>
>>Your way, mistakes by the user of the *interpreter* can
>>easily crash the system.  My way, only the guy/gal doing the
>>wrapping has to be careful:
>>
>>         >>> x = X()
>>         >>> z = x.y
>>         >>> del x
>>         >>> z.foo()  # crash
>>
>>The users of these interpreted environments have an
>>expectation that their interpreter won't *crash* just
>>because of the way they've used it.
>></shiver>
>>    
>>
>
>As a user who (finally!) writes mainly new Python code I really value
>the safe-but-certain approach. If the interpreter crashes somewhere deep
>down in the application without printing a backtrace it is often very
>frustrating and time-consuming to isolate the problem by adding print
>statements. In a large-scale application it is crucial that all
>components are rock-solid.
>Ralf
>

We use Boost.Python at our company developing large applications, and I 
agree with Ralf.
Plus, I believe it is against Python philosophy to get a core dump, 
since Python itself goes great lenghts to prevent explicit memory 
management by the user.

BTW, this discussion about LuaBind is really interesting. 8)
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: Dirk Gerrits <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Tue, 24 Jun 2003 22:39:41 +0200
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1056487607 25780 80.91.224.249 (24 Jun 2003 20:46:47 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 24 Jun 2003 20:46:47 +0000 (UTC)
Original-X-From: [email protected] Tue Jun 24 22:46:45 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19Uueq-0006VA-00
	for <[email protected]>; Tue, 24 Jun 2003 22:44:52 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Uuf3-0001HS-00; Tue, 24 Jun 2003 16:45:05 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19Uuet-0001G2-00
	for [email protected]; Tue, 24 Jun 2003 16:44:55 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UucX-0006Fk-00
	for <[email protected]>; Tue, 24 Jun 2003 22:42:29 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UuZV-0005zp-00
	for <[email protected]>; Tue, 24 Jun 2003 22:39:21 +0200
Original-Lines: 31
Original-X-Complaints-To: [email protected]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:44
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3555
Lines: 30
X-Gnus-Newsgroup: langbinding-mbox:44   Sat Jul 19 11:05:37 2003

Nicodemus wrote:
> Ralf W. Grosse-Kunstleve wrote:
>
>> As a user who (finally!) writes mainly new Python code I really value
>> the safe-but-certain approach. If the interpreter crashes somewhere deep
>> down in the application without printing a backtrace it is often very
>> frustrating and time-consuming to isolate the problem by adding print
>> statements. In a large-scale application it is crucial that all
>> components are rock-solid.
>> Ralf
>>
> 
> We use Boost.Python at our company developing large applications, and I 
> agree with Ralf.
> Plus, I believe it is against Python philosophy to get a core dump, 
> since Python itself goes great lenghts to prevent explicit memory 
> management by the user.

I concur. Anything that has gone wrong with my Python programs so far 
has always resulted in a nice and clear exception with a traceback. If 
only that would have been the case in C++... :P Great libraries like the 
STL and Boost alleviate the pain though.

> BTW, this discussion about LuaBind is really interesting. 8)

I agree! And perhaps some of it can serve as a fine basis for that 
'Boost.Python core documentation'?

Regards,
Dirk Gerrits
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Tue, 24 Jun 2003 19:05:39 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056478090 10802 80.91.224.249 (24 Jun 2003 18:08:10 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 24 Jun 2003 18:08:10 +0000 (UTC)
Original-X-From: [email protected] Tue Jun 24 20:08:06 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UsCP-0002jv-00
	for <[email protected]>; Tue, 24 Jun 2003 20:07:21 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UsCL-0006eD-00; Tue, 24 Jun 2003 14:07:17 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19UsAq-0005Gk-00
	for [email protected]; Tue, 24 Jun 2003 14:05:44 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5OI5eDQ076062;
	Tue, 24 Jun 2003 20:05:41 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:45
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3550
Lines: 264
X-Gnus-Newsgroup: langbinding-mbox:45   Sat Jul 19 11:05:37 2003

> >> I think that problem is a little more complicated than
> >> you're making it out to be, and that your method ends
> up
> >> being slower than it should be in inheritance graphs of
> >> any size.  First of all, inheritance may be a DAG and
> you
> >> have to prevent infinite loops if you're actually going
> >> to support cross-casting.  Secondly Boost.Python caches
> >> cast sequences so that given the most-derived type of
> an
> >> object, you only have to search once for a conversion
> to
> >> any other type, and after that you can do a simple
> >> address calculation.  See
> >> libs/python/src/object/inheritance.cpp.  This probably
> >> should be better commented; the algorithms were hard to
> >> figure out and I didn't write down rationale for them
> :(
> >> On the other hand, maybe being fast isn't important in
> >> this part of the code, and the cacheing should be
> >> eliminated ;-)
> >
> > We only support upcasting, so our method isn't that
> slow.
>
> Surely you want to be able to go in both directions,
> though?
> Surely not everyone using lua is interested in just speed
> and not usability?

We probably would like to be able to go in both directions.
We also don't want to force the user to compile with RTTI
turned on, so we currently supply a LUABIND_TYPEID macro to
overload the typeid calls for a unique id for the type. This
of course causes some problems if we want to downcast, so we
would need to be able to turn downcasting off, or let the
user supply their own RTTI-system somehow.

>
> > Generally it's just a linked list traversal. We don't
> > cache though, and caching is a good thing. :)
>
> Yeah, probably.  It would be good to share all of that.

Sure.

>
> >> > Ok, how do you handle conversions of lvalues from c++
> >> > -> python?  The to_python converter associated with a
> >> > UDT does rvalue conversion and creates a new object,
> >> > correct?
> >>
> >> Yeah.  Implicit conversion of lvalues by itself with no
> >> ownership management is dangerous so you have to tell
> >> Boost.Python to do it.  I'm sure you know this, though,
> >> since luabind supports "parameter policies."  Bad name,
> >> though: a primary reason for these is to manage return
> >> values (which are not parameters).  So I wonder what
> >> you're really asking?
> >
> > We convert lvalues to lua with no management by default.
> I
> > don't think this is more dangerous than copying the
> > objects, it's just seg faults instead of silent
> > errors.
>
> <shiver>
> Your way, mistakes by the user of the *interpreter* can
> easily crash the system.  My way, only the guy/gal doing
> the
> wrapping has to be careful:
>
>          >>> x = X()
>          >>> z = x.y
>          >>> del x
>          >>> z.foo()  # crash
>
> The users of these interpreted environments have an
> expectation that their interpreter won't *crash* just
> because of the way they've used it.
> </shiver>

Right, I thought you always copied the object. My mistake.

>
> > Both ways are equaly easy to make mistakes with.
>
> Totally disagree.  Done my way, we force the guy/gal to
> consider whether he really wants to do something unsafe
> before he does it.  You probably think I copy objects by
> default, but I don't. That was BPLv1.  In BPLv2 I issue an
> error unless the user supplies a call policy.
>
> Finally, let me point out that although we currently use
> Python weak references to accomplish this I realized last
> night that there's a *much* easier and more-efficient way
> to do it using a special kind of smart pointer to refer to
> the referenced object.

Ah ok, function which returns lvalues causes compile time
errors. When we decided to do it our way we thought
returning unmanaged lvalue's would be the most common usage.
We only considered copying the object as an alternative,
perhaps it's better to give compile time errors.

>
> > Our policies primary reason is not to handle return
> > values, but to handle conversion in both directions. For
> > example, adopt() can be used to steal objects that are
> > owned by the interpreter.
> >
> > void f(A*); def("f", &f, adopt(_1))
>
> What, you just leak a reference here?  Or is it something
> else?  I had a major client who was sure he was going to
> need to leak references, but he eventually discovered that
> the provided call policies could always be made to do
> something more-intelligent, so I never put the
> reference-leaker in the library.  I haven't had a single
> request for it since, either.

The above is (almost) the equivalent of:
void f(auto_ptr<A>*);

It is very useful when wrapping interfaces which expects the
user to create objects and give up ownership.

>
> > But yes, the name should indicate both
> > directions..  ConversionPolicy perhaps.
>
> Hmm, this is really very specific to calls, because it
> *does* manage arguments and return values.  I really think
> CallPolicy is better.  In any case I think we should
> converge on this, one way or another; there will be more
> languages, and you do want to be able to steal my users,
> right? <wink>.  That'll be a lot easier if they see
> familiar terminology ;-)

I don't think it's specific to calls, but to all conversion
of types between the languages. We can use policies when
fetching values from lua, or when calling lua functions from
c++:

A* stolen_obj = object_cast<A*>(get_globals(L)["obj"],
adopt(result));

call_function<void>(L, "f", stolen_obj) [ adopt(_1) ];

And yeah, of course stealing your users is our goal. :)

> >> I'm not committed to the idea of a single registry.  In
> >> fact we've been discussing a hierarchical registry
> system
> >> where converters are searched starting with a local
> >> module registry and proceeding upward to the package
> >> level and finally ending with a global registry as a
> >> fallback.
> >
> > Right, that seems reasonable.
>
> Cool.  And let me also point out that if the module
> doesn't
> have to collaborate with other modules, you don't even
> need
> a registry lookup at static initialization time.  A static
> data member of a class template is enough to create an
> area
> of storage associated with a C++ type.  There's no central
> registry at all in that case.  I have grave doubts about
> whether it's worth special-casing the code for this, but
> it
> might make threading easier to cope with.

I can't see why it would be worth it. If the module doesn't
interact with other modules threading wouldn't be an issue?
So how could it make it easier?

>
> >> My big problem was trying to figure out a scheme for
> >> assigning match quality.  C++ uses a kind of
> >> "substitutaiblity" rule for resolving partial ordering
> >> which seemed like a good way to handle things.  How do
> >> you do it?
> >
> > We just let every converter return a value indicating
> how
> > good the match was, where 0 is perfect match and -1 is
> no
> > match. When performing implicit conversions, every step
> in
> > the conversions inreases the match value.
> >
> > Maybe I'm naive, but is there need for anything more
> complicated?
>
> Well, it's the "multimethod problem": consider base and
> derived class formal arguments which both match an actual
> argument, or int <--> float conversions.  How much do you
> increase the match value by for a particular match?

I don't know if I get this.

We just increase the match value by one for every casting
step that is needed for converting the types.

>
> >> > Right. The requirement I was aiming to resolve was
> that we need a
> >> > different set of parameters when doing our
> conversions.
> >>
> >> I consider that an implementation detail ;-)
> >>
> >> > You have your PyObject*, we have our (lua_State*,
> int).
> >>
> >> What's the int?
> >
> > An index to the object being converted on the lua stack.
>
> Oh, I guess lua hasn't handed you a pointer to an object
> at
> that point?  Well, OK.

Right. Also, you can't get a pointer to all objects in lua,
only "userdata" objects. If the object being converted is of
primitive type, you can only access it directly from the
stack with lua_toXXX() calls.

>
> >> We need separate registries within Boost.Python too; we
> >> just don't have them, yet.  There's also a potential
> >> issue with thread safety if you have modules using the
> >> same registry initializing concurrently.  With a single
> >> Python interpreter state, it's not an issue, since
> >> extension module code is always entered on the main
> >> thread until a mutex is explicitly released.  Anyway, I
> >> want to discuss the whole issue of registry isolation
> in
> >> the larger context of what's desirable for both systems
> >> and their evolution into the future.
> >
> > Right. For luabind it seems reasonable to accept a
> single
> > registry for every module, and perhaps global registry
> > used by interacting modules as well.
> >
> > It doesn't seem that interesting to register different
> > conversions for different states anymore. (at least not
> to
> > me, but I could be wrong..). But if we where to increase
> > the isolation of the registries, each state could just
> as
> > well get their own registry.
>
> Let's continue poking at the issues until we get clarity.
>

Yeah, I'll have to think about this for a bit, the whole
registry thing is quite new to me.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Tue, 24 Jun 2003 16:42:04 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056487657 26095 80.91.224.249 (24 Jun 2003 20:47:37 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 24 Jun 2003 20:47:37 +0000 (UTC)
Original-X-From: [email protected] Tue Jun 24 22:47:33 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19UuhR-0006ma-00
	for <[email protected]>; Tue, 24 Jun 2003 22:47:33 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19Uuhg-0002Rt-00; Tue, 24 Jun 2003 16:47:48 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19Uugr-0001bg-00
	for [email protected]; Tue, 24 Jun 2003 16:46:57 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19Uuen-0006Ul-00
	for <[email protected]>; Tue, 24 Jun 2003 22:44:49 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19UucZ-0006G1-00
	for <[email protected]>; Tue, 24 Jun 2003 22:42:31 +0200
Original-Lines: 311
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:vnwct5DfGdQYJL1g4gQtvx5aEdI=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:46
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3556
Lines: 311
X-Gnus-Newsgroup: langbinding-mbox:46   Sat Jul 19 11:05:37 2003

"Daniel Wallin" <[email protected]> writes:

>> >> I think that problem is a little more complicated than
>> >> you're making it out to be, and that your method ends
>> >> up being slower than it should be in inheritance
>> >> graphs of any size.  First of all, inheritance may be
>> >> a DAG and you have to prevent infinite loops if you're
>> >> actually going to support cross-casting.  Secondly
>> >> Boost.Python caches cast sequences so that given the
>> >> most-derived type of an object, you only have to
>> >> search once for a conversion to any other type, and
>> >> after that you can do a simple address calculation.
>> >> See libs/python/src/object/inheritance.cpp.  This
>> >> probably should be better commented; the algorithms
>> >> were hard to figure out and I didn't write down
>> >> rationale for them :( On the other hand, maybe being
>> >> fast isn't important in this part of the code, and the
>> >> cacheing should be eliminated ;-)
>> >
>> > We only support upcasting, so our method isn't that
>> > slow.
>>
>> Surely you want to be able to go in both directions,
>> though?  Surely not everyone using lua is interested in
>> just speed and not usability?
>
> We probably would like to be able to go in both
> directions.  We also don't want to force the user to
> compile with RTTI turned on

I'm sure that's a capability some Boost.Python users would
appreciate, too.

> so we currently supply a LUABIND_TYPEID macro to overload
> the typeid calls for a unique id for the type. 

This functions something like a specialization?

> This of course causes some problems if we want to
> downcast

And if you want to support CBD (component based development,
i.e. cross-module conversions), unless you can somehow get
all authors to agree on how to identify types.  Well, I
guess they could use strings and manually supply what
std::type_info::name() does.

> so we would need to be able to turn downcasting off, or
> let the user supply their own RTTI-system somehow.

That's pretty straightforward, fortunately.

We need to be careful about what kinds of reconfigurability
is available through macros.  Extensions linked to the same
shared library all share a link symbol space and thus are
subject to ODR problems.

>> >> > Ok, how do you handle conversions of lvalues from c++
>> >> > -> python?  The to_python converter associated with a
>> >> > UDT does rvalue conversion and creates a new object,
>> >> > correct?
>> >>
>> >> Yeah.  Implicit conversion of lvalues by itself with
>> >> no ownership management is dangerous so you have to
>> >> tell Boost.Python to do it.  I'm sure you know this,
>> >> though, since luabind supports "parameter policies."
>> >> Bad name, though: a primary reason for these is to
>> >> manage return values (which are not parameters).  So I
>> >> wonder what you're really asking?
>> >
>> > We convert lvalues to lua with no management by
>> > default. I don't think this is more dangerous than
>> > copying the objects, it's just seg faults instead of
>> > silent errors.
>>
>> <shiver>
>> Your way, mistakes by the user of the *interpreter* can
>> easily crash the system.  My way, only the guy/gal doing
>> the wrapping has to be careful:
>>
>>          >>> x = X()
>>          >>> z = x.y
>>          >>> del x
>>          >>> z.foo()  # crash
>>
>> The users of these interpreted environments have an
>> expectation that their interpreter won't *crash* just
>> because of the way they've used it.
>> </shiver>
>
> Right, I thought you always copied the object. My mistake.

OK, sorry for the heat.

>> > Both ways are equaly easy to make mistakes with.
>>
>> Totally disagree.  Done my way, we force the guy/gal to
>> consider whether he really wants to do something unsafe
>> before he does it.  You probably think I copy objects by
>> default, but I don't. That was BPLv1.  In BPLv2 I issue an
>> error unless the user supplies a call policy.
>>
>> Finally, let me point out that although we currently use
>> Python weak references to accomplish this I realized last
>> night that there's a *much* easier and more-efficient way
>> to do it using a special kind of smart pointer to refer to
>> the referenced object.
>
> Ah ok, function which returns lvalues causes compile time
> errors. 

Relatively pretty ones, too.  See
boost/python/default_call_policies.hpp

> When we decided to do it our way we thought returning
> unmanaged lvalue's would be the most common usage.  We
> only considered copying the object as an alternative,
> perhaps it's better to give compile time errors.

It's *miles* better.  Otherwise users will just blindly wrap
these things unsafely without considering the consequences.
Remember that the segfault may not occur in their tests, due
to (un)lucky usage patterns.

>> > Our policies primary reason is not to handle return
>> > values, but to handle conversion in both
>> > directions. For example, adopt() can be used to steal
>> > objects that are owned by the interpreter.
>> >
>> > void f(A*); def("f", &f, adopt(_1))
>>
>> What, you just leak a reference here?  Or is it something
>> else?  I had a major client who was sure he was going to
>> need to leak references, but he eventually discovered
>> that the provided call policies could always be made to
>> do something more-intelligent, so I never put the
>> reference-leaker in the library.  I haven't had a single
>> request for it since, either.
>
> The above is (almost) the equivalent of:
> void f(auto_ptr<A>*);

What's the significance of a pointer-to-auto_ptr?  I'd
understand what you meant if you wrote:

     void f(auto_ptr<A>);

instead.  I'm going to assume that's what you meant.

> It is very useful when wrapping interfaces which expects the
> user to create objects and give up ownership.

Sure, great.  It's a function-call-oriented thing.  Before
you object, read on.

>> Hmm, this is really very specific to calls, because it
>> *does* manage arguments and return values.  I really think
>> CallPolicy is better.  In any case I think we should
>> converge on this, one way or another; there will be more
>> languages, and you do want to be able to steal my users,
>> right? <wink>.  That'll be a lot easier if they see
>> familiar terminology ;-)
>
> I don't think it's specific to calls, but to all conversion
> of types between the languages. We can use policies when
> fetching values from lua, or when calling lua functions from
> c++:
>
> A* stolen_obj = object_cast<A*>(get_globals(L)["obj"],
> adopt(result));

What is result?  A placeholder?

could be spelled:

    std::auto_ptr<A> stolen
        = extract<std::auto_ptr<A> >(get_globals(L)["obj"]);

in Boost.Python.

[I assume this means that all of your C++ objects are held
within their lua wrappers by pointer.  I went to
considerable lengths to allow them to be held by-value,
though I'm not sure the efficiency gain is worth the cost
in flexibility.]

> call_function<void>(L, "f", stolen_obj) [ adopt(_1) ];

That's spelled:

  call_function<void>(L, "f", std::auto_ptr<A>(stolen));

I can begin to see the syntactic convenience of your way,
but I worry about the parameterizability.  In the first case
"result" is the only possible appropriate arg and in the 2nd
case it's "_1".

> And yeah, of course stealing your users is our goal. :)

I certainly hope so!  Likewise, I'm sure!

>> >> I'm not committed to the idea of a single registry.
>> >> In fact we've been discussing a hierarchical registry
>> >> system where converters are searched starting with a
>> >> local module registry and proceeding upward to the
>> >> package level and finally ending with a global
>> >> registry as a fallback.
>> >
>> > Right, that seems reasonable.
>>
>> Cool.  And let me also point out that if the module
>> doesn't have to collaborate with other modules, you don't
>> even need a registry lookup at static initialization
>> time.  A static data member of a class template is enough
>> to create an area of storage associated with a C++ type.
>> There's no central registry at all in that case.  I have
>> grave doubts about whether it's worth special-casing the
>> code for this, but it might make threading easier to cope
>> with.
>
> I can't see why it would be worth it. 

I like your attitude.

> If the module doesn't interact with other modules
> threading wouldn't be an issue?  So how could it make it
> easier?

I guess only in the case that the modules are loadedq
multiple times by different threads *and* the compiler
provides threadsafe static initializers, you wouldn't have
to worry about the central registry being modified while
someone was reading it.  A minor issue, really.  Mutexes
handle everything.

>> >> My big problem was trying to figure out a scheme for
>> >> assigning match quality.  C++ uses a kind of
>> >> "substitutaiblity" rule for resolving partial ordering
>> >> which seemed like a good way to handle things.  How do
>> >> you do it?
>> >
>> > We just let every converter return a value indicating
>> > how good the match was, where 0 is perfect match and -1
>> > is no match. When performing implicit conversions,
>> > every step in the conversions inreases the match value.
>> >
>> > Maybe I'm naive, but is there need for anything more
>> > complicated?
>>
>> Well, it's the "multimethod problem": consider base and
>> derived class formal arguments which both match an actual
>> argument, or int <--> float conversions.  How much do you
>> increase the match value by for a particular match?
>
> I don't know if I get this.

Are you familiar with the problems of multimethod
dispatching?  Google can help.

> We just increase the match value by one for every casting
> step that is needed for converting the types.

That seems to work for all the trivial cases, but the
problem is always phrased in more-complicated terms, I
presume for a reason.  See http://tinyurl.com/f5t6

One example of a place where it might not work is:

struct B {}; struct D : B {};

void f(B*, python::list)
void f(D*, std::vector<int>)

   >>> f(D(), [1, 2, 3])

I want this to choose the first overload, since it requires
only lvalue conversions.

Other links of interest:
  http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1463.html
  http://tinyurl.com/f5vi

None of these uses such a trivial algorithm for rating
matches.  Coincidence?

> Right. Also, you can't get a pointer to all objects in lua,
> only "userdata" objects. If the object being converted is of
> primitive type, you can only access it directly from the
> stack with lua_toXXX() calls.

OK

>> > It doesn't seem that interesting to register different
>> > conversions for different states anymore. (at least not
>> > to me, but I could be wrong..). But if we where to
>> > increase the isolation of the registries, each state
>> > could just as well get their own registry.
>>
>> Let's continue poking at the issues until we get clarity.
>
> Yeah, I'll have to think about this for a bit, the whole
> registry thing is quite new to me.

OK.  FYI I'm going on vacation 6/26-7/6.  I find this
conversation really interesting, though, so I'll try to
keep an eye on it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Wed, 25 Jun 2003 11:00:22 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056535300 8714 80.91.224.249 (25 Jun 2003 10:01:40 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 25 Jun 2003 10:01:40 +0000 (UTC)
Original-X-From: [email protected] Wed Jun 25 12:01:38 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19V75B-0002D5-00
	for <[email protected]>; Wed, 25 Jun 2003 12:00:53 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19V75P-00073M-00; Wed, 25 Jun 2003 06:01:07 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19V74i-0006tY-00
	for [email protected]; Wed, 25 Jun 2003 06:00:24 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5PA0MDQ034668;
	Wed, 25 Jun 2003 12:00:23 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:47
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3564
Lines: 312
X-Gnus-Newsgroup: langbinding-mbox:47   Sat Jul 19 11:05:37 2003

> "Daniel Wallin" <[email protected]> writes:
> >> Surely you want to be able to go in both directions,
> >> though?  Surely not everyone using lua is interested in
> >> just speed and not usability?
> >
> > We probably would like to be able to go in both
> > directions.  We also don't want to force the user to
> > compile with RTTI turned on
>
> I'm sure that's a capability some Boost.Python users would
> appreciate, too.
>
> > so we currently supply a LUABIND_TYPEID macro to
> overload
> > the typeid calls for a unique id for the type.
>
> This functions something like a specialization?

Right. You could do something like:

#define LUABIND_TYPE_INFO int
#define LUABIND_TYPEID(type) my_type_id<type>::value

>
> > This of course causes some problems if we want to
> > downcast
>
> And if you want to support CBD (component based
> development,
> i.e. cross-module conversions), unless you can somehow get
> all authors to agree on how to identify types.  Well, I
> guess they could use strings and manually supply what
> std::type_info::name() does.

It doesn't seem wrong that the authors need to use the same
typeid. If you aren't developing a closed system, don't
change typeid system.

>
> > so we would need to be able to turn downcasting off, or
> > let the user supply their own RTTI-system somehow.
>
> That's pretty straightforward, fortunately.
>
> We need to be careful about what kinds of
> reconfigurability
> is available through macros.  Extensions linked to the
> same
> shared library all share a link symbol space and thus are
> subject to ODR problems.

Right. We currently have quite a few configuration macros.

LUABIND_MAX_ARITY
LUABIND_MAX_BASES
LUABIND_NO_ERROR_CHECKING
LUABIND_DONT_COPY_STRINGS
LUABIND_NO_EXCEPTIONS
. and the typeid macros.

Most are results of user requests. Massive configuration is
quite important to our users, since lua is used alot on
embedded systems.

> >> > Both ways are equaly easy to make mistakes with.
> >>
> >> Totally disagree.  Done my way, we force the guy/gal to
> >> consider whether he really wants to do something unsafe
> >> before he does it.  You probably think I copy objects
> by
> >> default, but I don't. That was BPLv1.  In BPLv2 I issue
> an
> >> error unless the user supplies a call policy.
> >>
> >> Finally, let me point out that although we currently
> use
> >> Python weak references to accomplish this I realized
> last
> >> night that there's a *much* easier and more-efficient
> way
> >> to do it using a special kind of smart pointer to refer
> to
> >> the referenced object.
> >
> > Ah ok, function which returns lvalues causes compile
> time
> > errors.
>
> Relatively pretty ones, too.  See
> boost/python/default_call_policies.hpp

Looks good. We have similar ones in some policies (for
example adopt can only convert pointers).

>
> > When we decided to do it our way we thought returning
> > unmanaged lvalue's would be the most common usage.  We
> > only considered copying the object as an alternative,
> > perhaps it's better to give compile time errors.
>
> It's *miles* better.  Otherwise users will just blindly
> wrap
> these things unsafely without considering the
> consequences.
> Remember that the segfault may not occur in their tests,
> due
> to (un)lucky usage patterns.

You're probably right. We saw the convenience of not having
to type a policy name as important.

>
> >> > Our policies primary reason is not to handle return
> >> > values, but to handle conversion in both
> >> > directions. For example, adopt() can be used to steal
> >> > objects that are owned by the interpreter.
> >> >
> >> > void f(A*); def("f", &f, adopt(_1))
> >>
> >> What, you just leak a reference here?  Or is it
> something
> >> else?  I had a major client who was sure he was going
> to
> >> need to leak references, but he eventually discovered
> >> that the provided call policies could always be made to
> >> do something more-intelligent, so I never put the
> >> reference-leaker in the library.  I haven't had a
> single
> >> request for it since, either.
> >
> > The above is (almost) the equivalent of:
> > void f(auto_ptr<A>*);
>
> What's the significance of a pointer-to-auto_ptr?  I'd
> understand what you meant if you wrote:
>
>      void f(auto_ptr<A>);
>
> instead.  I'm going to assume that's what you meant.

Yeah, that's what I meant. I'm lazy and copy-pasted and
forgot to remove the *. :)

>
> > It is very useful when wrapping interfaces which expects
> the
> > user to create objects and give up ownership.
>
> Sure, great.  It's a function-call-oriented thing.  Before
> you object, read on.
>
> >> Hmm, this is really very specific to calls, because it
> >> *does* manage arguments and return values.  I really
> think
> >> CallPolicy is better.  In any case I think we should
> >> converge on this, one way or another; there will be
> more
> >> languages, and you do want to be able to steal my
> users,
> >> right? <wink>.  That'll be a lot easier if they see
> >> familiar terminology ;-)
> >
> > I don't think it's specific to calls, but to all
> conversion
> > of types between the languages. We can use policies when
> > fetching values from lua, or when calling lua functions
> from
> > c++:
> >
> > A* stolen_obj = object_cast<A*>(get_globals(L)["obj"],
> > adopt(result));
>
> What is result?  A placeholder?

Exactly. boost::arg<0> result;

>
> could be spelled:
>
>     std::auto_ptr<A> stolen
>         = extract<std::auto_ptr<A>
> >(get_globals(L)["obj"]);
>
> in Boost.Python.
>
> [I assume this means that all of your C++ objects are held
> within their lua wrappers by pointer.  I went to
> considerable lengths to allow them to be held by-value,
> though I'm not sure the efficiency gain is worth the cost
> in flexibility.]

Correct. We hold all C++ objects by pointer. I can see why
it could be interesting to be able to hold objects by value
though, especially with small objects. I'm not sure it would
be worth it though, since the user can just provide a custom
pool allocator if allocation is an issue.

>
> > call_function<void>(L, "f", stolen_obj) [ adopt(_1) ];
>
> That's spelled:
>
>   call_function<void>(L, "f", std::auto_ptr<A>(stolen));

Wouldn't both the examples you provided require A to be held
by auto_ptr<A> in python?

>
> I can begin to see the syntactic convenience of your way,
> but I worry about the parameterizability.  In the first
> case
> "result" is the only possible appropriate arg and in the
> 2nd
> case it's "_1".

What exactly do you worry about? That someone would use the
wrong placeholder? I think the intended use is quite clear.

It's trivial to STATIC_ASSERT if someone uses the wrong
placeholder though.

> >> >> My big problem was trying to figure out a scheme for
> >> >> assigning match quality.  C++ uses a kind of
> >> >> "substitutaiblity" rule for resolving partial
> ordering
> >> >> which seemed like a good way to handle things.  How
> do
> >> >> you do it?
> >> >
> >> > We just let every converter return a value indicating
> >> > how good the match was, where 0 is perfect match and
> -1
> >> > is no match. When performing implicit conversions,
> >> > every step in the conversions inreases the match
> value.
> >> >
> >> > Maybe I'm naive, but is there need for anything more
> >> > complicated?
> >>
> >> Well, it's the "multimethod problem": consider base and
> >> derived class formal arguments which both match an
> actual
> >> argument, or int <--> float conversions.  How much do
> you
> >> increase the match value by for a particular match?
> >
> > I don't know if I get this.
>
> Are you familiar with the problems of multimethod
> dispatching?  Google can help.

I wasn't no, and google didn't seem to like me. :)

>
> > We just increase the match value by one for every
> casting
> > step that is needed for converting the types.
>
> That seems to work for all the trivial cases, but the
> problem is always phrased in more-complicated terms, I
> presume for a reason.  See http://tinyurl.com/f5t6
>
> One example of a place where it might not work is:
>
> struct B {}; struct D : B {};
>
> void f(B*, python::list)
> void f(D*, std::vector<int>)
>
>    >>> f(D(), [1, 2, 3])
>
> I want this to choose the first overload, since it
> requires
> only lvalue conversions.

rvalue conversions could always give much larger errors than
lvalue conversions. This would solve some cases, but it
isn't clear to me what you want. Do you always want to
choose the first overload, no matter how many lvalue
conversions it involves?

void f(B*, B*, B*, python::list)
void f(D*, D*, D*, std::vector<int>)

f(D(), D(), D(), [1, 2, 3])

To me it's sufficient to have a really simple overload
system, and if that doesn't work the user can register the
overloads with different names.

> >> > It doesn't seem that interesting to register
> different
> >> > conversions for different states anymore. (at least
> not
> >> > to me, but I could be wrong..). But if we where to
> >> > increase the isolation of the registries, each state
> >> > could just as well get their own registry.
> >>
> >> Let's continue poking at the issues until we get
> clarity.
> >
> > Yeah, I'll have to think about this for a bit, the whole
> > registry thing is quite new to me.
>
> OK.  FYI I'm going on vacation 6/26-7/6.  I find this
> conversation really interesting, though, so I'll try to
> keep an eye on it.

Ok great, have fun.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Wed, 25 Jun 2003 07:22:02 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056540179 29745 80.91.224.249 (25 Jun 2003 11:22:59 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 25 Jun 2003 11:22:59 +0000 (UTC)
Original-X-From: [email protected] Wed Jun 25 13:22:58 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19V8Mc-0007jc-00
	for <[email protected]>; Wed, 25 Jun 2003 13:22:58 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19V8Mq-0004c5-00; Wed, 25 Jun 2003 07:23:12 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19V8MQ-0004XD-00
	for [email protected]; Wed, 25 Jun 2003 07:22:46 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19V8M8-0007h3-00
	for <[email protected]>; Wed, 25 Jun 2003 13:22:28 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19V8M7-0007gi-00
	for <[email protected]>; Wed, 25 Jun 2003 13:22:27 +0200
Original-Lines: 256
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:ny5QYyNdn9Rdw30PM6urOJGp/dI=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:48
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3566
Lines: 256
X-Gnus-Newsgroup: langbinding-mbox:48   Sat Jul 19 11:05:37 2003

"Daniel Wallin" <[email protected]> writes:

>> "Daniel Wallin" <[email protected]> writes:
>> >> Surely you want to be able to go in both directions,
>> >> though?  Surely not everyone using lua is interested in
>> >> just speed and not usability?
>> >
>> > We probably would like to be able to go in both
>> > directions.  We also don't want to force the user to
>> > compile with RTTI turned on
>>
>> I'm sure that's a capability some Boost.Python users would
>> appreciate, too.
>>
>> > so we currently supply a LUABIND_TYPEID macro to
>> > overload the typeid calls for a unique id for the type.
>>
>> This functions something like a specialization?
>
> Right. You could do something like:
>
> #define LUABIND_TYPE_INFO int
> #define LUABIND_TYPEID(type) my_type_id<type>::value

I don't see any reason to get macros involved here.  Users
could just specialize or overload boost::luapython::type_id,
which, in the no-RTTI case, has no no default definition.

>> > This of course causes some problems if we want to
>> > downcast
>>
>> And if you want to support CBD (component based
>> development, i.e. cross-module conversions), unless you
>> can somehow get all authors to agree on how to identify
>> types.  Well, I guess they could use strings and manually
>> supply what std::type_info::name() does.
>
> It doesn't seem wrong that the authors need to use the
> same typeid. If you aren't developing a closed system,
> don't change typeid system.

I was thinking more of id collisions among extensions which
don't intend to share types.  It becomes less of an issue
if people use string ids.

>> > so we would need to be able to turn downcasting off, or
>> > let the user supply their own RTTI-system somehow.
>>
>> That's pretty straightforward, fortunately.
>>
>> We need to be careful about what kinds of
>> reconfigurability is available through macros.
>> Extensions linked to the same shared library all share a
>> link symbol space and thus are subject to ODR problems.
>
> Right. We currently have quite a few configuration macros.
>
> LUABIND_MAX_ARITY
> LUABIND_MAX_BASES

It's pretty easy to avoid these causing any real-world ODR
problems.

> LUABIND_NO_ERROR_CHECKING

What kind of error checking gets turned off?

> LUABIND_DONT_COPY_STRINGS

What kind of string copying gets disabled?

> LUABIND_NO_EXCEPTIONS

This one, at least, is clear.

> . and the typeid macros.
>
> Most are results of user requests. Massive configuration
> is quite important to our users, since lua is used alot on
> embedded systems.

Have your users come back after getting these features and
given you any feedback about how much performance they've
gained or space they've saved?

>> Relatively pretty ones, too.  See
>> boost/python/default_call_policies.hpp
>
> Looks good. We have similar ones in some policies (for
> example adopt can only convert pointers).

Good.  Another place we could create common infrastructure.

>> > When we decided to do it our way we thought returning
>> > unmanaged lvalue's would be the most common usage.  We
>> > only considered copying the object as an alternative,
>> > perhaps it's better to give compile time errors.
>>
>> It's *miles* better.  Otherwise users will just blindly
>> wrap these things unsafely without considering the
>> consequences.  Remember that the segfault may not occur
>> in their tests, due to (un)lucky usage patterns.
>
> You're probably right. We saw the convenience of not
> having to type a policy name as important.

It is good to be the king.

>> What's the significance of a pointer-to-auto_ptr?  I'd
>> understand what you meant if you wrote:
>>
>>      void f(auto_ptr<A>);
>>
>> instead.  I'm going to assume that's what you meant.
>
> Yeah, that's what I meant. I'm lazy and copy-pasted and
> forgot to remove the *. :)
>
>>
>> > It is very useful when wrapping interfaces which expects the
>> > user to create objects and give up ownership.
>>
>> Sure, great.  It's a function-call-oriented thing.  Before
>> you object, read on.
>>
>> >> Hmm, this is really very specific to calls, because it
>> >> *does* manage arguments and return values.  I really
>> >> think CallPolicy is better.  In any case I think we
>> >> should converge on this, one way or another; there
>> >> will be more languages, and you do want to be able to
>> >> steal my users, right? <wink>.  That'll be a lot
>> >> easier if they see familiar terminology ;-)
>> >
>> > I don't think it's specific to calls, but to all
>> > conversion of types between the languages. We can use
>> > policies when fetching values from lua, or when calling
>> > lua functions from c++:
>> >
>> > A* stolen_obj = object_cast<A*>(get_globals(L)["obj"],
>> > adopt(result));
>>
>> What is result?  A placeholder?
>
> Exactly. boost::arg<0> result;
>
>>
>> could be spelled:
>>
>>     std::auto_ptr<A> stolen
>>         = extract<std::auto_ptr<A>
>> >(get_globals(L)["obj"]);
>>
>> in Boost.Python.
>>
>> [I assume this means that all of your C++ objects are held
>> within their lua wrappers by pointer.  I went to
>> considerable lengths to allow them to be held by-value,
>> though I'm not sure the efficiency gain is worth the cost
>> in flexibility.]
>
> Correct. We hold all C++ objects by pointer. I can see why
> it could be interesting to be able to hold objects by value
> though, especially with small objects. I'm not sure it would
> be worth it though, since the user can just provide a custom
> pool allocator if allocation is an issue.

Still costs an extra 4 bytes (gasp!) for the pointer.  Yeah,
it was in one of my contract specs, so I had to implement
it.  Besides, it seemed like fun, but I bet nobody notices
and I'd be very happy to rip it out and follow your lead on
this.

>> > call_function<void>(L, "f", stolen_obj) [ adopt(_1) ];
>>
>> That's spelled:
>>
>>   call_function<void>(L, "f", std::auto_ptr<A>(stolen));
>
> Wouldn't both the examples you provided require A to be held
> by auto_ptr<A> in python?

Only the A created by call_function for this callback.  You
can have As held any number of ways in the same program.

>> I can begin to see the syntactic convenience of your way,
>> but I worry about the parameterizability.  In the first
>> case "result" is the only possible appropriate arg and in
>> the 2nd case it's "_1".
>
> What exactly do you worry about? That someone would use
> the wrong placeholder? I think the intended use is quite
> clear.

I guess I'm just a worrywart.  Do the other policies have
similar broad applicability?  If so, I'm inclined to accept
that you have the right idea.

> It's trivial to STATIC_ASSERT if someone uses the wrong
> placeholder though.

Sure.

>> Are you familiar with the problems of multimethod
>> dispatching?  Google can help.
>
> I wasn't no, and google didn't seem to like me. :)

Did my links help?

>> > We just increase the match value by one for every
>> > casting step that is needed for converting the types.
>>
>> That seems to work for all the trivial cases, but the
>> problem is always phrased in more-complicated terms, I
>> presume for a reason.  See http://tinyurl.com/f5t6
>>
>> One example of a place where it might not work is:
>>
>> struct B {}; struct D : B {};
>>
>> void f(B*, python::list)
>> void f(D*, std::vector<int>)
>>
>>    >>> f(D(), [1, 2, 3])
>>
>> I want this to choose the first overload, since it
>> requires only lvalue conversions.
>
> rvalue conversions could always give much larger errors
> than lvalue conversions. This would solve some cases, but
> it isn't clear to me what you want. Do you always want to
> choose the first overload, no matter how many lvalue
> conversions it involves?
>
> void f(B*, B*, B*, python::list)
> void f(D*, D*, D*, std::vector<int>)
>
> f(D(), D(), D(), [1, 2, 3])

Yeah, I guess that looks right, but I don't know.  At some
point things are just ambiguous.

> To me it's sufficient to have a really simple overload
> system, and if that doesn't work the user can register the
> overloads with different names.

Hmm.  I like your philosophy.  

As a last resort, let me ask someone I know who's done a lot
of multimethod dispatching stuff if there's any reason to do
something more complicated.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Wed, 25 Jun 2003 11:25:24 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056536756 14789 80.91.224.249 (25 Jun 2003 10:25:56 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Wed, 25 Jun 2003 10:25:56 +0000 (UTC)
Original-X-From: [email protected] Wed Jun 25 12:25:51 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19V7TL-0003q7-00
	for <[email protected]>; Wed, 25 Jun 2003 12:25:51 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19V7Ta-0000Lc-00; Wed, 25 Jun 2003 06:26:06 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19V7Sv-0000LP-00
	for [email protected]; Wed, 25 Jun 2003 06:25:25 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5PAPODQ058714;
	Wed, 25 Jun 2003 12:25:24 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:49
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3565
Lines: 40
X-Gnus-Newsgroup: langbinding-mbox:49   Sat Jul 19 11:05:37 2003

> Nicodemus wrote:
> > Ralf W. Grosse-Kunstleve wrote:
> >
> >> As a user who (finally!) writes mainly new Python code
> I really value
> >> the safe-but-certain approach. If the interpreter
> crashes somewhere deep
> >> down in the application without printing a backtrace it
> is often very
> >> frustrating and time-consuming to isolate the problem
> by adding print
> >> statements. In a large-scale application it is crucial
> that all
> >> components are rock-solid.
> >> Ralf
> >>
> >
> > We use Boost.Python at our company developing large
> applications, and I
> > agree with Ralf.
> > Plus, I believe it is against Python philosophy to get a
> core dump,
> > since Python itself goes great lenghts to prevent
> explicit memory
> > management by the user.
>
> I concur. Anything that has gone wrong with my Python
> programs so far
> has always resulted in a nice and clear exception with a
> traceback. If
> only that would have been the case in C++... :P Great
> libraries like the
> STL and Boost alleviate the pain though.

I agree, I said core dump is just as good as silent errors
because I was under the impression that BPL copied objects
by default.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:37 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu, 26 Jun 2003 13:29:15 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056630594 29771 80.91.224.249 (26 Jun 2003 12:29:54 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 26 Jun 2003 12:29:54 +0000 (UTC)
Original-X-From: [email protected] Thu Jun 26 14:29:50 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19VVss-0007ji-00
	for <[email protected]>; Thu, 26 Jun 2003 14:29:50 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19VVt8-0004Hj-00; Thu, 26 Jun 2003 08:30:06 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19VVsO-0004Gd-00
	for [email protected]; Thu, 26 Jun 2003 08:29:20 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5QCTGDQ022787;
	Thu, 26 Jun 2003 14:29:16 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:50
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3573
Lines: 311
X-Gnus-Newsgroup: langbinding-mbox:50   Sat Jul 19 11:05:37 2003

> "Daniel Wallin" <[email protected]> writes:
>
> >> "Daniel Wallin" <[email protected]> writes:
> >> >> Surely you want to be able to go in both directions,
> >> >> though?  Surely not everyone using lua is interested
> in
> >> >> just speed and not usability?
> >> >
> >> > We probably would like to be able to go in both
> >> > directions.  We also don't want to force the user to
> >> > compile with RTTI turned on
> >>
> >> I'm sure that's a capability some Boost.Python users
> would
> >> appreciate, too.
> >>
> >> > so we currently supply a LUABIND_TYPEID macro to
> >> > overload the typeid calls for a unique id for the
> type.
> >>
> >> This functions something like a specialization?
> >
> > Right. You could do something like:
> >
> > #define LUABIND_TYPE_INFO int
> > #define LUABIND_TYPEID(type) my_type_id<type>::value
>
> I don't see any reason to get macros involved here.  Users
> could just specialize or overload
> boost::luapython::type_id,
> which, in the no-RTTI case, has no no default definition.

Note that we need to store the type_info object, and that's
why we have macros for this. So that the user can change the
type of that object. This wouldn't really work with
specialization.

> >> > This of course causes some problems if we want to
> >> > downcast
> >>
> >> And if you want to support CBD (component based
> >> development, i.e. cross-module conversions), unless you
> >> can somehow get all authors to agree on how to identify
> >> types.  Well, I guess they could use strings and
> manually
> >> supply what std::type_info::name() does.
> >
> > It doesn't seem wrong that the authors need to use the
> > same typeid. If you aren't developing a closed system,
> > don't change typeid system.
>
> I was thinking more of id collisions among extensions
> which
> don't intend to share types.  It becomes less of an issue
> if people use string ids.

But like I said, if you intend to use your module with other
modules; don't change the typeid system. I don't like
forcing the id type, if you want to use int's I think you
should be allowed to.

>
> >> > so we would need to be able to turn downcasting off,
> or
> >> > let the user supply their own RTTI-system somehow.
> >>
> >> That's pretty straightforward, fortunately.
> >>
> >> We need to be careful about what kinds of
> >> reconfigurability is available through macros.
> >> Extensions linked to the same shared library all share
> a
> >> link symbol space and thus are subject to ODR problems.
> >
> > Right. We currently have quite a few configuration
> macros.
> >
> > LUABIND_MAX_ARITY
> > LUABIND_MAX_BASES
>
> It's pretty easy to avoid these causing any real-world ODR
> problems.

Right. They are only used to control the number of template
parameters to a few metaprogramming struct's.

>
> > LUABIND_NO_ERROR_CHECKING
>
> What kind of error checking gets turned off?

Error checking when performing overload matching. In
particular it turns off the pretty error messages.

>
> > LUABIND_DONT_COPY_STRINGS
>
> What kind of string copying gets disabled?

It causes names to be held by const char* instead of
std::string. (class names, function names etc).

> > . and the typeid macros.
> >
> > Most are results of user requests. Massive configuration
> > is quite important to our users, since lua is used alot
> on
> > embedded systems.
>
> Have your users come back after getting these features and
> given you any feedback about how much performance they've
> gained or space they've saved?

No. But some of them is a must-have for alot of developers.
In particular the ability to turn off exception handling.

> >> What's the significance of a pointer-to-auto_ptr?  I'd
> >> understand what you meant if you wrote:
> >>
> >>      void f(auto_ptr<A>);
> >>
> >> instead.  I'm going to assume that's what you meant.
> >
> > Yeah, that's what I meant. I'm lazy and copy-pasted and
> > forgot to remove the *. :)
> >
> >>
> >> > It is very useful when wrapping interfaces which
> expects the
> >> > user to create objects and give up ownership.
> >>
> >> Sure, great.  It's a function-call-oriented thing.
> Before
> >> you object, read on.
> >>
> >> >> Hmm, this is really very specific to calls, because
> it
> >> >> *does* manage arguments and return values.  I really
> >> >> think CallPolicy is better.  In any case I think we
> >> >> should converge on this, one way or another; there
> >> >> will be more languages, and you do want to be able
> to
> >> >> steal my users, right? <wink>.  That'll be a lot
> >> >> easier if they see familiar terminology ;-)
> >> >
> >> > I don't think it's specific to calls, but to all
> >> > conversion of types between the languages. We can use
> >> > policies when fetching values from lua, or when
> calling
> >> > lua functions from c++:
> >> >
> >> > A* stolen_obj =
> object_cast<A*>(get_globals(L)["obj"],
> >> > adopt(result));
> >>
> >> What is result?  A placeholder?
> >
> > Exactly. boost::arg<0> result;
> >
> >>
> >> could be spelled:
> >>
> >>     std::auto_ptr<A> stolen
> >>         = extract<std::auto_ptr<A>
> >> >(get_globals(L)["obj"]);
> >>
> >> in Boost.Python.
> >>
> >> [I assume this means that all of your C++ objects are
> held
> >> within their lua wrappers by pointer.  I went to
> >> considerable lengths to allow them to be held by-value,
> >> though I'm not sure the efficiency gain is worth the
> cost
> >> in flexibility.]
> >
> > Correct. We hold all C++ objects by pointer. I can see
> why
> > it could be interesting to be able to hold objects by
> value
> > though, especially with small objects. I'm not sure it
> would
> > be worth it though, since the user can just provide a
> custom
> > pool allocator if allocation is an issue.
>
> Still costs an extra 4 bytes (gasp!) for the pointer.
> Yeah,
> it was in one of my contract specs, so I had to implement
> it.  Besides, it seemed like fun, but I bet nobody notices
> and I'd be very happy to rip it out and follow your lead
> on
> this.

Need to think about this some more. It's no special case in
BPL though, it's just another type of instance_holder,
correct?

>
> >> > call_function<void>(L, "f", stolen_obj) [ adopt(_1)
> ];
> >>
> >> That's spelled:
> >>
> >>   call_function<void>(L, "f",
> std::auto_ptr<A>(stolen));
> >
> > Wouldn't both the examples you provided require A to be
> held
> > by auto_ptr<A> in python?
>
> Only the A created by call_function for this callback.
> You
> can have As held any number of ways in the same program.

Ah, right. You just instantiate different instance_holder's.
Does this mean there's special handling of auto_ptr's?
Otherwise, how can you tell which type is being held by the
pointer? (In the call_function example).

>
> >> I can begin to see the syntactic convenience of your
> way,
> >> but I worry about the parameterizability.  In the first
> >> case "result" is the only possible appropriate arg and
> in
> >> the 2nd case it's "_1".
> >
> > What exactly do you worry about? That someone would use
> > the wrong placeholder? I think the intended use is quite
> > clear.
>
> I guess I'm just a worrywart.  Do the other policies have
> similar broad applicability?  If so, I'm inclined to
> accept
> that you have the right idea.

Most conversion policies have double direction, and even the
ones that doesn't can still be used in different contexts.
('result' when doing C++ -> lua, and '_N' when doing lua ->
C++).

> >> Are you familiar with the problems of multimethod
> >> dispatching?  Google can help.
> >
> > I wasn't no, and google didn't seem to like me. :)
>
> Did my links help?

A little. But I don't feel even remotly comfortable on the
subject. :)

>
> >> > We just increase the match value by one for every
> >> > casting step that is needed for converting the types.
> >>
> >> That seems to work for all the trivial cases, but the
> >> problem is always phrased in more-complicated terms, I
> >> presume for a reason.  See http://tinyurl.com/f5t6
> >>
> >> One example of a place where it might not work is:
> >>
> >> struct B {}; struct D : B {};
> >>
> >> void f(B*, python::list)
> >> void f(D*, std::vector<int>)
> >>
> >>    >>> f(D(), [1, 2, 3])
> >>
> >> I want this to choose the first overload, since it
> >> requires only lvalue conversions.
> >
> > rvalue conversions could always give much larger errors
> > than lvalue conversions. This would solve some cases,
> but
> > it isn't clear to me what you want. Do you always want
> to
> > choose the first overload, no matter how many lvalue
> > conversions it involves?
> >
> > void f(B*, B*, B*, python::list)
> > void f(D*, D*, D*, std::vector<int>)
> >
> > f(D(), D(), D(), [1, 2, 3])
>
> Yeah, I guess that looks right, but I don't know.  At some
> point things are just ambiguous.

Exactly. Perhaps introducing weights on conversions might
increase the ambiguity for the user, since it's hard to tell
at which point the overload system will turn around and
choose another overload. Does this make any sense?

>
> > To me it's sufficient to have a really simple overload
> > system, and if that doesn't work the user can register
> the
> > overloads with different names.
>
> Hmm.  I like your philosophy.
>
> As a last resort, let me ask someone I know who's done a
> lot
> of multimethod dispatching stuff if there's any reason to
> do
> something more complicated.

Great, do that.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:39 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Fri, 27 Jun 2003 17:31:15 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056750085 16233 80.91.224.249 (27 Jun 2003 21:41:25 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 27 Jun 2003 21:41:25 +0000 (UTC)
Original-X-From: [email protected] Fri Jun 27 23:41:23 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19W0xc-00049y-00
	for <[email protected]>; Fri, 27 Jun 2003 23:40:48 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19W0xu-0007qL-00; Fri, 27 Jun 2003 17:41:06 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19W0p4-0006rY-00
	for [email protected]; Fri, 27 Jun 2003 17:31:58 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19W0oh-0003SD-00
	for <[email protected]>; Fri, 27 Jun 2003 23:31:35 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19W0og-0003S0-00
	for <[email protected]>; Fri, 27 Jun 2003 23:31:34 +0200
Original-Lines: 244
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:0iMi9t1DofNu+YnzzQDmDr8588g=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:51
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3588
Lines: 244
X-Gnus-Newsgroup: langbinding-mbox:51   Sat Jul 19 11:05:39 2003

"Daniel Wallin" <[email protected]> writes:

>> "Daniel Wallin" <[email protected]> writes:
>>
>> >> "Daniel Wallin" <[email protected]> writes:
>> >> >> Surely you want to be able to go in both
>> >> >> directions, though?  Surely not everyone using lua
>> >> >> is interested in just speed and not usability?
>> >> >
>> >> > We probably would like to be able to go in both
>> >> > directions.  We also don't want to force the user to
>> >> > compile with RTTI turned on
>> >>
>> >> I'm sure that's a capability some Boost.Python users
>> >> would appreciate, too.
>> >>
>> >> > so we currently supply a LUABIND_TYPEID macro to
>> >> > overload the typeid calls for a unique id for the
>> >> > type.
>> >>
>> >> This functions something like a specialization?
>> >
>> > Right. You could do something like:
>> >
>> > #define LUABIND_TYPE_INFO int
>> > #define LUABIND_TYPEID(type) my_type_id<type>::value
>>
>> I don't see any reason to get macros involved here.
>> Users could just specialize or overload
>> boost::luapython::type_id, which, in the no-RTTI case,
>> has no no default definition.
>
> Note that we need to store the type_info object, and
> that's why we have macros for this. So that the user can
> change the type of that object. This wouldn't really work
> with specialization.

    template <class T> struct type_info
    #ifndef NO_RTTI
    {
       typedef std::type_info type;
       static type get();
    }
    #endif
    ;

    template <int n> 
    struct int_type_info
    {
        typedef int type;
        static int get() { return n; }
    };

    template <>
    struct type_info<Foo>
      : int_type_info<42>
    {};

Of course I have no objection to using macros to generate
specializations.

>> >> > This of course causes some problems if we want to
>> >> > downcast
>> >>
>> >> And if you want to support CBD (component based
>> >> development, i.e. cross-module conversions), unless you
>> >> can somehow get all authors to agree on how to identify
>> >> types.  Well, I guess they could use strings and manually
>> >> supply what std::type_info::name() does.
>> >
>> > It doesn't seem wrong that the authors need to use the
>> > same typeid. If you aren't developing a closed system,
>> > don't change typeid system.
>>
>> I was thinking more of id collisions among extensions
>> which don't intend to share types.  It becomes less of an
>> issue if people use string ids.
>
> But like I said, if you intend to use your module with other
> modules; don't change the typeid system. 

I'm not talking about changing systems, just the need to
ensure unique type IDs for different types across modules.

> I don't like forcing the id type, if you want to use int's
> I think you should be allowed to.

Sure; I have no objection to that.

>> > LUABIND_NO_ERROR_CHECKING
>>
>> What kind of error checking gets turned off?
>
> Error checking when performing overload matching. In
> particular it turns off the pretty error messages.

Another feature I want to steal from you.  It's good that
it's configurable.

>> > LUABIND_DONT_COPY_STRINGS
>>
>> What kind of string copying gets disabled?
>
> It causes names to be held by const char* instead of
> std::string. (class names, function names etc).

Why not always do that?

>> > . and the typeid macros.
>> >
>> > Most are results of user requests. Massive configuration
>> > is quite important to our users, since lua is used alot on
>> > embedded systems.
>>
>> Have your users come back after getting these features and
>> given you any feedback about how much performance they've
>> gained or space they've saved?
>
> No. But some of them is a must-have for alot of
> developers.  In particular the ability to turn off
> exception handling.

Oh sure, I believe that one, especially because some shops
(advisedly or no) have a policy against EH and RTTI.  You
don't want to just leave them out.  I am just leery of
configurability in general and would tend to resist making
any new macros part of the official release until users had
told me it made a big difference to them in alpha/beta
stages.  In particular, "massive" configurability is not
neccessarily desirable.  It creates "massive" maintenance
and testing headaches.

>> >> [I assume this means that all of your C++ objects are held
>> >> within their lua wrappers by pointer.  I went to
>> >> considerable lengths to allow them to be held by-value,
>> >> though I'm not sure the efficiency gain is worth the cost
>> >> in flexibility.]
>> >
>> > Correct. We hold all C++ objects by pointer. I can see why
>> > it could be interesting to be able to hold objects by value
>> > though, especially with small objects. I'm not sure it would
>> > be worth it though, since the user can just provide a custom
>> > pool allocator if allocation is an issue.
>>
>> Still costs an extra 4 bytes (gasp!) for the pointer.
>> Yeah, it was in one of my contract specs, so I had to
>> implement it.  Besides, it seemed like fun, but I bet
>> nobody notices and I'd be very happy to rip it out and
>> follow your lead on this.
>
> Need to think about this some more. It's no special case
> in BPL though, it's just another type of instance_holder,
> correct?

Not only that.  It's an issue of where the instance holder
gets constructed.  In this case it is constructed directly
in the storage for the Python object.

>> > Wouldn't both the examples you provided require A to be held
>> > by auto_ptr<A> in python?
>>
>> Only the A created by call_function for this callback.
>> You can have As held any number of ways in the same
>> program.
>
> Ah, right. You just instantiate different instance_holder's.
> Does this mean there's special handling of auto_ptr's?

What do you mean by "special handling"?  I think the answer
is no, though I also think there should be special handling
for convenience and efficiency.

> Otherwise, how can you tell which type is being held by
> the pointer? (In the call_function example).

The to-python converter that gets registered for auto_ptr<T>
by using it in a class<T, std::auto_ptr<T>, ... > or by
using register_pointer_to_python<std::auto_ptr<T> > knows
what to do.

>> >> I can begin to see the syntactic convenience of your way,
>> >> but I worry about the parameterizability.  In the first
>> >> case "result" is the only possible appropriate arg and in
>> >> the 2nd case it's "_1".
>> >
>> > What exactly do you worry about? That someone would use
>> > the wrong placeholder? I think the intended use is quite
>> > clear.
>>
>> I guess I'm just a worrywart.  Do the other policies have
>> similar broad applicability?  If so, I'm inclined to
>> accept
>> that you have the right idea.
>
> Most conversion policies have double direction

Cool, I accept your scheme.

> and even the
> ones that doesn't can still be used in different contexts.
> ('result' when doing C++ -> lua, and '_N' when doing lua ->
> C++).

How is that *not* a case of bidirectionality?

That rule makes me nervous, because the terms are backwards
when calling lua/python from C++.  Do people get confused?

>> > void f(B*, B*, B*, python::list)
>> > void f(D*, D*, D*, std::vector<int>)
>> >
>> > f(D(), D(), D(), [1, 2, 3])
>>
>> Yeah, I guess that looks right, but I don't know.  At some
>> point things are just ambiguous.
>
> Exactly. Perhaps introducing weights on conversions might
> increase the ambiguity for the user, since it's hard to tell
> at which point the overload system will turn around and
> choose another overload. Does this make any sense?

Yes.  But as I meant to say to Andrei, none of the "classic"
multimethod systems account for coercion, so if there's some
reason they can't use your simple rule it has to be
something you can understand in terms of simple inheritance
hierarchies.

>> > To me it's sufficient to have a really simple overload
>> > system, and if that doesn't work the user can register the
>> > overloads with different names.
>>
>> Hmm.  I like your philosophy.
>>
>> As a last resort, let me ask someone I know who's done a
>> lot of multimethod dispatching stuff if there's any
>> reason to do something more complicated.
>
> Great, do that.

Too bad it didn't pan out :(
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:39 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Sat, 28 Jun 2003 00:02:07 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056755449 10718 80.91.224.249 (27 Jun 2003 23:10:49 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 27 Jun 2003 23:10:49 +0000 (UTC)
Original-X-From: [email protected] Sat Jun 28 01:10:48 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19W2Mh-0002mg-00
	for <[email protected]>; Sat, 28 Jun 2003 01:10:47 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19W2N1-0002yn-00; Fri, 27 Jun 2003 19:11:07 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19W2EL-0001iM-00
	for [email protected]; Fri, 27 Jun 2003 19:02:09 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5RN27DQ007836;
	Sat, 28 Jun 2003 01:02:07 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:52
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3593
Lines: 279
X-Gnus-Newsgroup: langbinding-mbox:52   Sat Jul 19 11:05:39 2003

> "Daniel Wallin" <[email protected]> writes:
> >> Users could just specialize or overload
> >> boost::luapython::type_id, which, in the no-RTTI case,
> >> has no no default definition.
> >
> > Note that we need to store the type_info object, and
> > that's why we have macros for this. So that the user can
> > change the type of that object. This wouldn't really
> work
> > with specialization.
>
>     template <class T> struct type_info
>     #ifndef NO_RTTI
>     {
>        typedef std::type_info type;
>        static type get();
>     }
>     #endif
>     ;
>
>     template <int n>
>     struct int_type_info
>     {
>         typedef int type;
>         static int get() { return n; }
>     };
>
>     template <>
>     struct type_info<Foo>
>       : int_type_info<42>
>     {};
>
> Of course I have no objection to using macros to generate
> specializations.

The type of the type-identifier needs to be known to the
library though, so my point is that it can't be a template
which the user just specializes. You also need to set the
type for the compiled part of the library. Or am I missing
something here?

>
> >> >> > This of course causes some problems if we want to
> >> >> > downcast
> >> >>
> >> >> And if you want to support CBD (component based
> >> >> development, i.e. cross-module conversions), unless
> you
> >> >> can somehow get all authors to agree on how to
> identify
> >> >> types.  Well, I guess they could use strings and
> manually
> >> >> supply what std::type_info::name() does.
> >> >
> >> > It doesn't seem wrong that the authors need to use
> the
> >> > same typeid. If you aren't developing a closed
> system,
> >> > don't change typeid system.
> >>
> >> I was thinking more of id collisions among extensions
> >> which don't intend to share types.  It becomes less of
> an
> >> issue if people use string ids.
> >
> > But like I said, if you intend to use your module with
> other
> > modules; don't change the typeid system.
>
> I'm not talking about changing systems, just the need to
> ensure unique type IDs for different types across modules.

Yeah I know, what I'm saying is that you will only get
problems like that if you change your type_info
represantation to something like 'int'. In which case you
have changed type id system. This isn't a problem as long as
you stick to typeid() and type_info?

> >> > LUABIND_DONT_COPY_STRINGS
> >>
> >> What kind of string copying gets disabled?
> >
> > It causes names to be held by const char* instead of
> > std::string. (class names, function names etc).
>
> Why not always do that?

Hold const char*? Because you can't control their lifetime?
:)

>
> >> > . and the typeid macros.
> >> >
> >> > Most are results of user requests. Massive
> configuration
> >> > is quite important to our users, since lua is used
> alot on
> >> > embedded systems.
> >>
> >> Have your users come back after getting these features
> and
> >> given you any feedback about how much performance
> they've
> >> gained or space they've saved?
> >
> > No. But some of them is a must-have for alot of
> > developers.  In particular the ability to turn off
> > exception handling.
>
> Oh sure, I believe that one, especially because some shops
> (advisedly or no) have a policy against EH and RTTI.  You
> don't want to just leave them out.  I am just leery of
> configurability in general and would tend to resist making
> any new macros part of the official release until users
> had
> told me it made a big difference to them in alpha/beta
> stages.  In particular, "massive" configurability is not
> neccessarily desirable.  It creates "massive" maintenance
> and testing headaches.

I agree. I can ask around on our mailing list later about
what kind of configuration people think is interesting, and
how much of what we have now they are using.

>
> >> >> [I assume this means that all of your C++ objects
> are held
> >> >> within their lua wrappers by pointer.  I went to
> >> >> considerable lengths to allow them to be held
> by-value,
> >> >> though I'm not sure the efficiency gain is worth the
> cost
> >> >> in flexibility.]
> >> >
> >> > Correct. We hold all C++ objects by pointer. I can
> see why
> >> > it could be interesting to be able to hold objects by
> value
> >> > though, especially with small objects. I'm not sure
> it would
> >> > be worth it though, since the user can just provide a
> custom
> >> > pool allocator if allocation is an issue.
> >>
> >> Still costs an extra 4 bytes (gasp!) for the pointer.
> >> Yeah, it was in one of my contract specs, so I had to
> >> implement it.  Besides, it seemed like fun, but I bet
> >> nobody notices and I'd be very happy to rip it out and
> >> follow your lead on this.
> >
> > Need to think about this some more. It's no special case
> > in BPL though, it's just another type of
> instance_holder,
> > correct?
>
> Not only that.  It's an issue of where the instance holder
> gets constructed.  In this case it is constructed directly
> in the storage for the Python object.

Right, that's pretty cool.

>
> >> > Wouldn't both the examples you provided require A to
> be held
> >> > by auto_ptr<A> in python?
> >>
> >> Only the A created by call_function for this callback.
> >> You can have As held any number of ways in the same
> >> program.
> >
> > Ah, right. You just instantiate different
> instance_holder's.
> > Does this mean there's special handling of auto_ptr's?
>
> What do you mean by "special handling"?  I think the
> answer
> is no, though I also think there should be special
> handling
> for convenience and efficiency.

I meant like an overload to extract the type held by the
auto_ptr. But you already answered that.

>
> > Otherwise, how can you tell which type is being held by
> > the pointer? (In the call_function example).
>
> The to-python converter that gets registered for
> auto_ptr<T>
> by using it in a class<T, std::auto_ptr<T>, ... > or by
> using register_pointer_to_python<std::auto_ptr<T> > knows
> what to do.

Ah, right. It's pretty nice to be able to hold the instances
in different kind of holders.

>
> >> >> I can begin to see the syntactic convenience of your
> way,
> >> >> but I worry about the parameterizability.  In the
> first
> >> >> case "result" is the only possible appropriate arg
> and in
> >> >> the 2nd case it's "_1".
> >> >
> >> > What exactly do you worry about? That someone would
> use
> >> > the wrong placeholder? I think the intended use is
> quite
> >> > clear.
> >>
> >> I guess I'm just a worrywart.  Do the other policies
> have
> >> similar broad applicability?  If so, I'm inclined to
> >> accept
> >> that you have the right idea.
> >
> > Most conversion policies have double direction
>
> Cool, I accept your scheme.

Great.

>
> > and even the
> > ones that doesn't can still be used in different
> contexts.
> > ('result' when doing C++ -> lua, and '_N' when doing lua
> ->
> > C++).
>
> How is that *not* a case of bidirectionality?

:) It is, my fault. I meant it could be used in different
contexts with the same direction, it should read something
like: 'result' when calling a C++ function, '_N' when
calling a lua function.

> That rule makes me nervous, because the terms are
> backwards
> when calling lua/python from C++.  Do people get confused?

I don't think they do, I don't think anyone has reported any
problems with it yet. It's backwards for a reason though,
and it's pretty clear when to use which placeholder. (except
in some special cases, where documentation helps).

>
> >> > void f(B*, B*, B*, python::list)
> >> > void f(D*, D*, D*, std::vector<int>)
> >> >
> >> > f(D(), D(), D(), [1, 2, 3])
> >>
> >> Yeah, I guess that looks right, but I don't know.  At
> some
> >> point things are just ambiguous.
> >
> > Exactly. Perhaps introducing weights on conversions
> might
> > increase the ambiguity for the user, since it's hard to
> tell
> > at which point the overload system will turn around and
> > choose another overload. Does this make any sense?
>
> Yes.  But as I meant to say to Andrei, none of the
> "classic"
> multimethod systems account for coercion, so if there's
> some
> reason they can't use your simple rule it has to be
> something you can understand in terms of simple
> inheritance
> hierarchies.

Right. I'll try to read up on this a bit more, I missed
those Andrei mails you cc:ed yesterday, gonna read them
today.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:39 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Sat, 28 Jun 2003 11:51:46 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056815509 29756 80.91.224.249 (28 Jun 2003 15:51:49 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sat, 28 Jun 2003 15:51:49 +0000 (UTC)
Original-X-From: [email protected] Sat Jun 28 17:51:47 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19WHzP-0007jf-00
	for <[email protected]>; Sat, 28 Jun 2003 17:51:47 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19WHzi-0006hv-00; Sat, 28 Jun 2003 11:52:06 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19WHzW-0006ah-00
	for [email protected]; Sat, 28 Jun 2003 11:51:54 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19WHz8-0007is-00
	for <[email protected]>; Sat, 28 Jun 2003 17:51:30 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19WHz7-0007ii-00
	for <[email protected]>; Sat, 28 Jun 2003 17:51:29 +0200
Original-Lines: 176
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:9gGDq/lfUE4UHOA8Br5z7EOVLFQ=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:53
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3595
Lines: 176
X-Gnus-Newsgroup: langbinding-mbox:53   Sat Jul 19 11:05:39 2003

"Daniel Wallin" <[email protected]> writes:

>> "Daniel Wallin" <[email protected]> writes:
>
> The type of the type-identifier needs to be known to the
> library though, so my point is that it can't be a template
> which the user just specializes. You also need to set the
> type for the compiled part of the library. Or am I missing
> something here?

Probably not; I think you have a good point, at least, if we
need runtime polymorphism among type id objects or if they
need to be manipulated in the compiled part of the library.

typedefs still work, though.

>> >> >> > This of course causes some problems if we want to
>> >> >> > downcast
>> >> >>
>> >> >> And if you want to support CBD (component based
>> >> >> development, i.e. cross-module conversions), unless
>> >> >> you can somehow get all authors to agree on how to
>> >> >> identify types.  Well, I guess they could use
>> >> >> strings and manually supply what
>> >> >> std::type_info::name() does.
>> >> >
>> >> > It doesn't seem wrong that the authors need to use the
>> >> > same typeid. If you aren't developing a closed system,
>> >> > don't change typeid system.
>> >>
>> >> I was thinking more of id collisions among extensions
>> >> which don't intend to share types.  It becomes less of an
>> >> issue if people use string ids.
>> >
>> > But like I said, if you intend to use your module with other
>> > modules; don't change the typeid system.
>>
>> I'm not talking about changing systems, just the need to
>> ensure unique type IDs for different types across modules.
>
> Yeah I know, what I'm saying is that you will only get
> problems like that if you change your type_info
> represantation to something like 'int'. In which case you
> have changed type id system. This isn't a problem as long
> as you stick to typeid() and type_info?

Assuming a single compiler and the use of distinct
namespaces, no.

>> >> > LUABIND_DONT_COPY_STRINGS
>> >>
>> >> What kind of string copying gets disabled?
>> >
>> > It causes names to be held by const char* instead of
>> > std::string. (class names, function names etc).
>>
>> Why not always do that?
>
> Hold const char*? Because you can't control their
> lifetime?  :)

You mean that some people want to compute these things
dynamically instead of using string literals?  Nobody has
ever asked me for that.  I bet this is one area of
configurability that could be dropped.

>> >> > . and the typeid macros.
>> >> >
>> >> > Most are results of user requests. Massive configuration
>> >> > is quite important to our users, since lua is used alot on
>> >> > embedded systems.
>> >>
>> >> Have your users come back after getting these features and
>> >> given you any feedback about how much performance they've
>> >> gained or space they've saved?
>> >
>> > No. But some of them is a must-have for alot of
>> > developers.  In particular the ability to turn off
>> > exception handling.
>>
>> Oh sure, I believe that one, especially because some
>> shops (advisedly or no) have a policy against EH and
>> RTTI.  You don't want to just leave them out.  I am just
>> leery of configurability in general and would tend to
>> resist making any new macros part of the official release
>> until users had told me it made a big difference to them
>> in alpha/beta stages.  In particular, "massive"
>> configurability is not neccessarily desirable.  It
>> creates "massive" maintenance and testing headaches.
>
> I agree. I can ask around on our mailing list later about
> what kind of configuration people think is interesting,
> and how much of what we have now they are using.

Cool.

>> >> >> [I assume this means that all of your C++ objects are held
>> >> >> within their lua wrappers by pointer.  I went to
>> >> >> considerable lengths to allow them to be held by-value,
>> >> >> though I'm not sure the efficiency gain is worth the cost
>> >> >> in flexibility.]
>> >> >
>> >> > Correct. We hold all C++ objects by pointer. I can see why
>> >> > it could be interesting to be able to hold objects by value
>> >> > though, especially with small objects. I'm not sure it would
>> >> > be worth it though, since the user can just provide a custom
>> >> > pool allocator if allocation is an issue.
>> >>
>> >> Still costs an extra 4 bytes (gasp!) for the pointer.
>> >> Yeah, it was in one of my contract specs, so I had to
>> >> implement it.  Besides, it seemed like fun, but I bet
>> >> nobody notices and I'd be very happy to rip it out and
>> >> follow your lead on this.
>> >
>> > Need to think about this some more. It's no special
>> > case in BPL though, it's just another type of
>> > instance_holder, correct?
>>
>> Not only that.  It's an issue of where the instance holder
>> gets constructed.  In this case it is constructed directly
>> in the storage for the Python object.
>
> Right, that's pretty cool.

Yeah, but I doubt it's saving much, and it leads to much
complication (c.f. instance_new and instance_dealloc in
libs/python/src/object/class.cpp).  If objects are getting
created and destroyed a *lot* it could reduce fragmentation
and increase locality... but as I said I have big doubts.

>> The to-python converter that gets registered for
>> auto_ptr<T> by using it in a class<T, std::auto_ptr<T>,
>> ... > or by using
>> register_pointer_to_python<std::auto_ptr<T> > knows what
>> to do.
>
> Ah, right. It's pretty nice to be able to hold the instances
> in different kind of holders.

Yeah.  

Note also that shared_ptr is "magic", in that any wrapped T
can be converted to shared_ptr<T> regardless of holder, and
the resulting shared_ptr<T> can be converted back to the
original Python object (not just a new one sharing the same
C++ object).

>> > and even the
>> > ones that doesn't can still be used in different contexts.
>> > ('result' when doing C++ -> lua, and '_N' when doing lua ->
>> > C++).
>>
>> How is that *not* a case of bidirectionality?
>
> :) It is, my fault. I meant it could be used in different
> contexts with the same direction, it should read something
> like: 'result' when calling a C++ function, '_N' when
> calling a lua function.
>
>> That rule makes me nervous, because the terms are
>> backwards when calling lua/python from C++.  Do people
>> get confused?
>
> I don't think they do, I don't think anyone has reported any
> problems with it yet. It's backwards for a reason though,
> and it's pretty clear when to use which placeholder. (except
> in some special cases, where documentation helps).

OK.  Maybe we could allow a default argument which would
"just work" for these cases.  Another option is "_", which
is used in MPL for something similar.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:39 2003
Path: main.gmane.org!not-for-mail
From: "Daniel Wallin" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Sat, 28 Jun 2003 21:41:56 +0100
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: main.gmane.org 1056832909 6804 80.91.224.249 (28 Jun 2003 20:41:49 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sat, 28 Jun 2003 20:41:49 +0000 (UTC)
Original-X-From: [email protected] Sat Jun 28 22:41:48 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19WMW0-0001l6-00
	for <[email protected]>; Sat, 28 Jun 2003 22:41:44 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19WMWL-0000SU-00; Sat, 28 Jun 2003 16:42:05 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19WMWE-0000SL-00
	for [email protected]; Sat, 28 Jun 2003 16:41:58 -0400
Original-Received: from student.umu.se (custer.umdac.umu.se [130.239.8.14])
	by mail.umu.se (8.12.4/8.12.4) with SMTP id h5SKfvDQ020307;
	Sat, 28 Jun 2003 22:41:57 +0200 (MEST)
Original-To: [email protected]
X-Mailer: "webmail.umu.se (UMDAC)"
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
X-Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:54
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3597
Lines: 185
X-Gnus-Newsgroup: langbinding-mbox:54   Sat Jul 19 11:05:39 2003

> "Daniel Wallin" <[email protected]> writes:
>
> >> "Daniel Wallin" <[email protected]> writes:
> >
> > The type of the type-identifier needs to be known to the
> > library though, so my point is that it can't be a
> template
> > which the user just specializes. You also need to set
> the
> > type for the compiled part of the library. Or am I
> missing
> > something here?
>
> Probably not; I think you have a good point, at least, if
> we
> need runtime polymorphism among type id objects or if they
> need to be manipulated in the compiled part of the
> library.
>
> typedefs still work, though.

Yeah, a typedef would have been a much better solution. I
think the reason we use macro's is because we used const
type_info* directly, instead of wrapping it in a class. So
we couldn't simply use < and == when comparing the types.

>
> >> >> >> > This of course causes some problems if we want
> to
> >> >> >> > downcast
> >> >> >>
> >> >> >> And if you want to support CBD (component based
> >> >> >> development, i.e. cross-module conversions),
> unless
> >> >> >> you can somehow get all authors to agree on how
> to
> >> >> >> identify types.  Well, I guess they could use
> >> >> >> strings and manually supply what
> >> >> >> std::type_info::name() does.
> >> >> >
> >> >> > It doesn't seem wrong that the authors need to use
> the
> >> >> > same typeid. If you aren't developing a closed
> system,
> >> >> > don't change typeid system.
> >> >>
> >> >> I was thinking more of id collisions among
> extensions
> >> >> which don't intend to share types.  It becomes less
> of an
> >> >> issue if people use string ids.
> >> >
> >> > But like I said, if you intend to use your module
> with other
> >> > modules; don't change the typeid system.
> >>
> >> I'm not talking about changing systems, just the need
> to
> >> ensure unique type IDs for different types across
> modules.
> >
> > Yeah I know, what I'm saying is that you will only get
> > problems like that if you change your type_info
> > represantation to something like 'int'. In which case
> you
> > have changed type id system. This isn't a problem as
> long
> > as you stick to typeid() and type_info?
>
> Assuming a single compiler and the use of distinct
> namespaces, no.

Right.

>
> >> >> > LUABIND_DONT_COPY_STRINGS
> >> >>
> >> >> What kind of string copying gets disabled?
> >> >
> >> > It causes names to be held by const char* instead of
> >> > std::string. (class names, function names etc).
> >>
> >> Why not always do that?
> >
> > Hold const char*? Because you can't control their
> > lifetime?  :)
>
> You mean that some people want to compute these things
> dynamically instead of using string literals?  Nobody has
> ever asked me for that.  I bet this is one area of
> configurability that could be dropped.

We actually have one user that uses this feature, I don't
know if he actually needs to though. So yeah, it could
probably be dropped.

> >> > Need to think about this some more. It's no special
> >> > case in BPL though, it's just another type of
> >> > instance_holder, correct?
> >>
> >> Not only that.  It's an issue of where the instance
> holder
> >> gets constructed.  In this case it is constructed
> directly
> >> in the storage for the Python object.
> >
> > Right, that's pretty cool.
>
> Yeah, but I doubt it's saving much, and it leads to much
> complication (c.f. instance_new and instance_dealloc in
> libs/python/src/object/class.cpp).  If objects are getting
> created and destroyed a *lot* it could reduce
> fragmentation
> and increase locality... but as I said I have big doubts.

Yeah, fragmentation issues can always be solved with pool
allocation. Is the complexity only due to value-holders, or
just different kind of holders? Seems to me (without having
looked at instance_new/instance_dealloc yet..) like you
would need the same allocation routines for pointer-holders
as well.

> >> The to-python converter that gets registered for
> >> auto_ptr<T> by using it in a class<T, std::auto_ptr<T>,
> >> ... > or by using
> >> register_pointer_to_python<std::auto_ptr<T> > knows
> what
> >> to do.
> >
> > Ah, right. It's pretty nice to be able to hold the
> instances
> > in different kind of holders.
>
> Yeah.
>
> Note also that shared_ptr is "magic", in that any wrapped
> T
> can be converted to shared_ptr<T> regardless of holder,
> and
> the resulting shared_ptr<T> can be converted back to the
> original Python object (not just a new one sharing the
> same
> C++ object).

Ok. I noticed that while browsing the code. The custom
deleter is a powerful tool. :)

> >> > and even the
> >> > ones that doesn't can still be used in different
> contexts.
> >> > ('result' when doing C++ -> lua, and '_N' when doing
> lua ->
> >> > C++).
> >>
> >> How is that *not* a case of bidirectionality?
> >
> > :) It is, my fault. I meant it could be used in
> different
> > contexts with the same direction, it should read
> something
> > like: 'result' when calling a C++ function, '_N' when
> > calling a lua function.
> >
> >> That rule makes me nervous, because the terms are
> >> backwards when calling lua/python from C++.  Do people
> >> get confused?
> >
> > I don't think they do, I don't think anyone has reported
> any
> > problems with it yet. It's backwards for a reason
> though,
> > and it's pretty clear when to use which placeholder.
> (except
> > in some special cases, where documentation helps).
>
> OK.  Maybe we could allow a default argument which would
> "just work" for these cases.  Another option is "_", which
> is used in MPL for something similar.

Sure, that would be nice. You can also introduce additional
placeholder aliases for the cases where '_N' and 'result'
doesn't fit very well.

--
Daniel Wallin
From nobody Sat Jul 19 11:05:39 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Sat, 28 Jun 2003 18:34:30 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1056839689 30955 80.91.224.249 (28 Jun 2003 22:34:49 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sat, 28 Jun 2003 22:34:49 +0000 (UTC)
Original-X-From: [email protected] Sun Jun 29 00:34:46 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19WOHO-000833-00
	for <[email protected]>; Sun, 29 Jun 2003 00:34:46 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19WOHj-0002WF-00; Sat, 28 Jun 2003 18:35:07 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19WOHG-0002PG-00
	for [email protected]; Sat, 28 Jun 2003 18:34:38 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19WOGr-000820-00
	for <[email protected]>; Sun, 29 Jun 2003 00:34:13 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19WOGq-00081p-00
	for <[email protected]>; Sun, 29 Jun 2003 00:34:12 +0200
Original-Lines: 130
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:4fGjLJyU/mYPHZuA9145WQWny8A=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:55
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3598
Lines: 130
X-Gnus-Newsgroup: langbinding-mbox:55   Sat Jul 19 11:05:39 2003

"Daniel Wallin" <[email protected]> writes:

>> >> > Need to think about this some more. It's no special
>> >> > case in BPL though, it's just another type of
>> >> > instance_holder, correct?
>> >>
>> >> Not only that.  It's an issue of where the instance
>> >> holder gets constructed.  In this case it is
>> >> constructed directly in the storage for the Python
>> >> object.
>> >
>> > Right, that's pretty cool.
>>
>> Yeah, but I doubt it's saving much, and it leads to much
>> complication (c.f. instance_new and instance_dealloc in
>> libs/python/src/object/class.cpp).  If objects are
>> getting created and destroyed a *lot* it could reduce
>> fragmentation and increase locality... but as I said I
>> have big doubts.
>
> Yeah, fragmentation issues can always be solved with pool
> allocation. 

But locality can't, for what that's worth.  Frankly I think
it's not worth much.

> Is the complexity only due to value-holders, or just
> different kind of holders? Seems to me (without having
> looked at instance_new/instance_dealloc yet..) like you
> would need the same allocation routines for
> pointer-holders as well.

I'm trying to tell you it has nothing to do with the how the
holders contain their data [though see below]; it's about
how/where the holders themselves are constructed.

The object model is something like this: every wrapped class
instance contains an endogenous linked list of holders (to
handle multiple inheritance from wrapped classes) and some
raw storage to use for holder allocation.  A class wrapper
knows the size and alignment of its default holder, so
usually the holder will be allocated right in the raw
storage.  If the holder turns out to be too big for that
storage, e.g. the default holder contains an auto_ptr<T> but
for some reason a value_holder<T> is used, or a
value_holder<U> is used where U is derived from T, then the
holder will be dynamically allocated instead.  Additional
holders in MI situations can also end up being dynamically
allocated.  Arranging for the extra storage in the Python
object means we have to fool Python into thinking the
objects are variable-length (like a tuple), and incurs a few
other complications.

Well, OK, actually I suppose the argument forwarding problem
(http://tinyurl.com/fist) causes a lot of additional
complexity because references need to be passed through
reference_wrapper<T> arguments, and that would go away if
there were no value_holders.  I barely even notice that
anymore, since it was part of BPLv1... but now that you
mention it, value_holder is probably causing more
complication in the code than in-place holder allocation.
Eliminating both might be a huge simplification.
Additionally, it might become possible to convert nearly any
object to nearly any kind of smart pointer.  value_holders
impose some real limitations on usability.

>> >> The to-python converter that gets registered for
>> >> auto_ptr<T> by using it in a class<T, std::auto_ptr<T>,
>> >> ... > or by using
>> >> register_pointer_to_python<std::auto_ptr<T> > knows what
>> >> to do.
>> >
>> > Ah, right. It's pretty nice to be able to hold the instances
>> > in different kind of holders.
>>
>> Yeah.
>>
>> Note also that shared_ptr is "magic", in that any wrapped
>> T can be converted to shared_ptr<T> regardless of holder,
>> and the resulting shared_ptr<T> can be converted back to
>> the original Python object (not just a new one sharing
>> the same C++ object).
>
> Ok. I noticed that while browsing the code. The custom
> deleter is a powerful tool. :)

Yeah, Peter's design really is beautiful.

>> >> > and even the
>> >> > ones that doesn't can still be used in different contexts.
>> >> > ('result' when doing C++ -> lua, and '_N' when doing lua ->
>> >> > C++).
>> >>
>> >> How is that *not* a case of bidirectionality?
>> >
>> > :) It is, my fault. I meant it could be used in different
>> > contexts with the same direction, it should read something
>> > like: 'result' when calling a C++ function, '_N' when
>> > calling a lua function.
>> >
>> >> That rule makes me nervous, because the terms are
>> >> backwards when calling lua/python from C++.  Do people
>> >> get confused?
>> >
>> > I don't think they do, I don't think anyone has reported any
>> > problems with it yet. It's backwards for a reason though,
>> > and it's pretty clear when to use which placeholder. (except
>> > in some special cases, where documentation helps).
>>
>> OK.  Maybe we could allow a default argument which would
>> "just work" for these cases.  Another option is "_", which
>> is used in MPL for something similar.
>
> Sure, that would be nice. You can also introduce additional
> placeholder aliases for the cases where '_N' and 'result'
> doesn't fit very well.

My point is that I'm trying to get away from a scenario
where users have to think about which choice is right, when
the context dictates that there can only be one right
choice.  Adding different names for the choices doesn't
help with that problem.  This is a minor nit.

It sounds like we're converging quite rapidly.  What other
issues do we need to deal with?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:39 2003
Path: main.gmane.org!not-for-mail
From: Daniel Wallin <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Tue, 01 Jul 2003 20:51:33 +0200
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Trace: main.gmane.org 1057085381 26708 80.91.224.249 (1 Jul 2003 18:49:41 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 1 Jul 2003 18:49:41 +0000 (UTC)
Original-X-From: [email protected] Tue Jul 01 20:49:39 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19XQCA-0006wP-00
	for <[email protected]>; Tue, 01 Jul 2003 20:49:38 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19XQCb-0002FZ-00; Tue, 01 Jul 2003 14:50:05 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19XQBm-0000mA-00
	for [email protected]; Tue, 01 Jul 2003 14:49:14 -0400
Original-Received: from dj.student.umu.se (h81172170009.kund.kommunicera.umea.se [81.172.170.9])
	by mail.umu.se (8.12.4/8.12.4) with ESMTP id h61In8FM047356
	for <[email protected]>; Tue, 1 Jul 2003 20:49:10 +0200 (MEST)
X-Sender: [email protected]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:56
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3612
Lines: 101
X-Gnus-Newsgroup: langbinding-mbox:56   Sat Jul 19 11:05:39 2003

At 00:34 2003-06-29, you wrote:
>"Daniel Wallin" <[email protected]> writes:
>
> >> Yeah, but I doubt it's saving much, and it leads to much
> >> complication (c.f. instance_new and instance_dealloc in
> >> libs/python/src/object/class.cpp).  If objects are
> >> getting created and destroyed a *lot* it could reduce
> >> fragmentation and increase locality... but as I said I
> >> have big doubts.
> >
> > Yeah, fragmentation issues can always be solved with pool
> > allocation.
>
>But locality can't, for what that's worth.  Frankly I think
>it's not worth much.

Me neither.

> > Is the complexity only due to value-holders, or just
> > different kind of holders? Seems to me (without having
> > looked at instance_new/instance_dealloc yet..) like you
> > would need the same allocation routines for
> > pointer-holders as well.
>
>I'm trying to tell you it has nothing to do with the how the
>holders contain their data [though see below]; it's about
>how/where the holders themselves are constructed.
>
>The object model is something like this: every wrapped class
>instance contains an endogenous linked list of holders (to
>handle multiple inheritance from wrapped classes) and some
>raw storage to use for holder allocation.  A class wrapper
>knows the size and alignment of its default holder, so
>usually the holder will be allocated right in the raw
>storage.  If the holder turns out to be too big for that
>storage, e.g. the default holder contains an auto_ptr<T> but
>for some reason a value_holder<T> is used, or a
>value_holder<U> is used where U is derived from T, then the
>holder will be dynamically allocated instead.  Additional
>holders in MI situations can also end up being dynamically
>allocated.  Arranging for the extra storage in the Python
>object means we have to fool Python into thinking the
>objects are variable-length (like a tuple), and incurs a few
>other complications.

Ok, I have very little knowledge in how Python memory management
works. In luabind we always allocate dynamically. We also don't
support multiple inheritance from wrapped classes.

>Well, OK, actually I suppose the argument forwarding problem
>(http://tinyurl.com/fist) causes a lot of additional
>complexity because references need to be passed through
>reference_wrapper<T> arguments, and that would go away if
>there were no value_holders.  I barely even notice that
>anymore, since it was part of BPLv1... but now that you
>mention it, value_holder is probably causing more
>complication in the code than in-place holder allocation.
>Eliminating both might be a huge simplification.
>Additionally, it might become possible to convert nearly any
>object to nearly any kind of smart pointer.  value_holders
>impose some real limitations on usability.

The actual allocation of the holders could be in a language dependent
layer though, in which case it would be an implementation detail if it's
in-place or heap allocated. We don't have any issues with allocating
the holder memory together with the instance object in lua.

> >> >> That rule makes me nervous, because the terms are
> >> >> backwards when calling lua/python from C++.  Do people
> >> >> get confused?
> >> >
> >> > I don't think they do, I don't think anyone has reported any
> >> > problems with it yet. It's backwards for a reason though,
> >> > and it's pretty clear when to use which placeholder. (except
> >> > in some special cases, where documentation helps).
> >>
> >> OK.  Maybe we could allow a default argument which would
> >> "just work" for these cases.  Another option is "_", which
> >> is used in MPL for something similar.
> >
> > Sure, that would be nice. You can also introduce additional
> > placeholder aliases for the cases where '_N' and 'result'
> > doesn't fit very well.
>
>My point is that I'm trying to get away from a scenario
>where users have to think about which choice is right, when
>the context dictates that there can only be one right
>choice.  Adding different names for the choices doesn't
>help with that problem.  This is a minor nit.

Yeah, for those cases (object_cast, object::assign for instance)
we could use default argument or a 'magic' placeholder.

>It sounds like we're converging quite rapidly.  What other
>issues do we need to deal with?

I don't know. I'm sure more issues will pop up later on though. :)
How do we proceed from here?


Daniel Wallin, [email protected]
From nobody Sat Jul 19 11:05:39 2003
Path: main.gmane.org!not-for-mail
From: Rene Rivera <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Tue,  1 Jul 2003 15:04:37 -0500
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1057089921 19595 80.91.224.249 (1 Jul 2003 20:05:21 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Tue, 1 Jul 2003 20:05:21 +0000 (UTC)
Original-X-From: [email protected] Tue Jul 01 22:05:19 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19XRMj-00052W-00
	for <[email protected]>; Tue, 01 Jul 2003 22:04:37 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19XRN9-0000sJ-00; Tue, 01 Jul 2003 16:05:03 -0400
Original-Received: from 42.muja.mlwk.chcgil24.dsl.att.net
	([12.100.89.42] helo=redshift-software.com ident=root)
	by mail.python.org with esmtp (Exim 4.05)
	id 19XRMe-0000ru-00
	for [email protected]; Tue, 01 Jul 2003 16:04:32 -0400
X-AuthUser: [email protected]
Original-Received: from 12.100.89.43 (12.100.89.43)
	by redshift-software.com with [XMail 1.12 (FreeBSD/Ix86) ESMTP Server]
	id <S126B3> for <[email protected]> from <[email protected]>;
	Tue, 01 Jul 2003 15:04:29 -0500
Original-To: [email protected]
X-Priority: 3
In-Reply-To: <[email protected]>
X-Mailer: Mailsmith 1.1.8 (Bluto)
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:57
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3613
Lines: 33
X-Gnus-Newsgroup: langbinding-mbox:57   Sat Jul 19 11:05:39 2003

[2003-07-01] Daniel Wallin wrote:

>At 00:34 2003-06-29, you wrote:
>>It sounds like we're converging quite rapidly.  What other
>>issues do we need to deal with?
>
>I don't know. I'm sure more issues will pop up later on though. :)
>How do we proceed from here?

Even though I followed most of this conversation... I'd personally like to
see a summary of decisions.

After that finding out what I and others can help with; deciding where to
put the work; what to name / where to put the common code; do we want to
move the dev discussion to a dedicated list; etc.

Some possible answers to those:

I imagine doing some of this in the boost-sandbox project is best. Question
is do we do all the dev work there or do we keep the LuaBind part where it
is? I can contact Jeremy about adding Daniel and Arvid to it, so that Dave
can continue enjoying his vacation ;-)

As for the name of the common code, I think there was one previous
suggestion which I can't remember. But my suggestion is Boost.Tie. It's on
par with Boost.Bind, but tie is one of the terms used for binding at
runtime/dynamically. I would assume Boost.Lua would be the conterpart to
Boost.Python.


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
From nobody Sat Jul 19 11:05:39 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Thu, 03 Jul 2003 13:33:57 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1057265553 16110 80.91.224.249 (3 Jul 2003 20:52:33 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 3 Jul 2003 20:52:33 +0000 (UTC)
Original-X-From: [email protected] Thu Jul 03 22:52:31 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YB4A-0004BV-00
	for <[email protected]>; Thu, 03 Jul 2003 22:52:31 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YB4h-0005EG-00; Thu, 03 Jul 2003 16:53:03 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19YB3w-0004M2-00
	for [email protected]; Thu, 03 Jul 2003 16:52:16 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YB3N-00047M-00
	for <[email protected]>; Thu, 03 Jul 2003 22:51:41 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YB3J-00046r-00
	for <[email protected]>; Thu, 03 Jul 2003 22:51:37 +0200
Original-Lines: 52
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:ed1DJrBjbEfICx8U1wgUi+ZAFwo=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:58
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3641
Lines: 52
X-Gnus-Newsgroup: langbinding-mbox:58   Sat Jul 19 11:05:39 2003

Rene Rivera <[email protected]> writes:

> [2003-07-01] Daniel Wallin wrote:
>
>>At 00:34 2003-06-29, you wrote:
>>>It sounds like we're converging quite rapidly.  What other
>>>issues do we need to deal with?
>>
>>I don't know. I'm sure more issues will pop up later on though. :)
>>How do we proceed from here?
>
> Even though I followed most of this conversation... I'd personally
> like to see a summary of decisions.

I think that would be great.  Volunteers?

> After that finding out what I and others can help with; deciding
> where to put the work; what to name / where to put the common code;
> do we want to move the dev discussion to a dedicated list; etc.
>
> Some possible answers to those:
>
> I imagine doing some of this in the boost-sandbox project is
> best. 

I'm not sure; I want to refactor parts of Boost.Python anyway.  Given
that we have a pile of tests, etc., I think it would be better to do
this evolution in the main CVS.  On a branch, if nothing else.

> Question is do we do all the dev work there or do we keep the
> LuaBind part where it is? I can contact Jeremy about adding Daniel
> and Arvid to it, so that Dave can continue enjoying his vacation ;-)

I think it's best to have everything in one repository so we can be
aggressive about sharing architecture and technology.

> As for the name of the common code, I think there was one previous
> suggestion which I can't remember. But my suggestion is
> Boost.Tie. It's on par with Boost.Bind, but tie is one of the terms
> used for binding at runtime/dynamically. I would assume Boost.Lua
> would be the conterpart to Boost.Python.

Tie already has a meaning in the tuples library.  I think we ought to
consider something that has more connotations of _dynamic_ _language_
binding.  It's a bit unfortunate because we probably don't like some
of the connotations, but "Boost.Script" might be the most apporpriate
name.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:40 2003
Path: main.gmane.org!not-for-mail
From: Rene Rivera <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu,  3 Jul 2003 18:59:14 -0500
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1057276774 28034 80.91.224.249 (3 Jul 2003 23:59:34 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 3 Jul 2003 23:59:34 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 01:59:30 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YDz8-0007HR-00
	for <[email protected]>; Fri, 04 Jul 2003 01:59:30 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YDzf-0007wC-00; Thu, 03 Jul 2003 20:00:03 -0400
Original-Received: from 42.muja.mlwk.chcgil24.dsl.att.net
	([12.100.89.42] helo=redshift-software.com ident=root)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YDyk-0006ya-00
	for [email protected]; Thu, 03 Jul 2003 19:59:06 -0400
X-AuthUser: [email protected]
Original-Received: from 12.100.89.43 (12.100.89.43)
	by redshift-software.com with [XMail 1.12 (FreeBSD/Ix86) ESMTP Server]
	id <S1285D> for <[email protected]> from <[email protected]>;
	Thu, 03 Jul 2003 18:59:04 -0500
Original-To: [email protected]
X-Priority: 3
In-Reply-To: <[email protected]>
X-Mailer: Mailsmith 1.1.8 (Bluto)
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:59
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3654
Lines: 49
X-Gnus-Newsgroup: langbinding-mbox:59   Sat Jul 19 11:05:40 2003

[2003-07-03] David Abrahams wrote:

>Rene Rivera <[email protected]> writes:
>
>> [2003-07-01] Daniel Wallin wrote:
>>
>>>At 00:34 2003-06-29, you wrote:
>>>>It sounds like we're converging quite rapidly.  What other
>>>>issues do we need to deal with?
>>>
>>>I don't know. I'm sure more issues will pop up later on though. :)
>>>How do we proceed from here?
>>
>> Even though I followed most of this conversation... I'd personally
>> like to see a summary of decisions.
>
>I think that would be great.  Volunteers?

I can try and go through the thread, reading more carefully than the first
time around, and collect some of the info. (will take a few days) And post
the results :-)

>> After that finding out what I and others can help with; deciding
>> where to put the work; what to name / where to put the common code;
>> do we want to move the dev discussion to a dedicated list; etc.
>>
>> Some possible answers to those:
>>
>> I imagine doing some of this in the boost-sandbox project is
>> best. 
>
>I'm not sure; I want to refactor parts of Boost.Python anyway.  Given
>that we have a pile of tests, etc., I think it would be better to do
>this evolution in the main CVS.  On a branch, if nothing else.

I thought that for such a restructuring you would not want to mess with the
current BP, even if on a branch? But I can see that it would be easier than
copying over a bunch of BP code.


Any ideas/preferences on: Where do we discuss the refactoring of the common
code and the laubind dev? It seems like noise polution to keep it on this
list. Daniel do you have a non-user list set up for LuaBind? Or we can add a
list to the SF boost project.


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
From nobody Sat Jul 19 11:05:40 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Thu, 03 Jul 2003 22:50:14 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1057287035 7735 80.91.224.249 (4 Jul 2003 02:50:35 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 02:50:35 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 04:50:30 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YGec-00020D-00
	for <[email protected]>; Fri, 04 Jul 2003 04:50:30 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YGf9-0007Jg-00; Thu, 03 Jul 2003 22:51:03 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19YGeo-0007Ey-00
	for [email protected]; Thu, 03 Jul 2003 22:50:42 -0400
Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YGeF-0001z8-00
	for <[email protected]>; Fri, 04 Jul 2003 04:50:07 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YGdx-0001yI-00
	for <[email protected]>; Fri, 04 Jul 2003 04:49:49 +0200
Original-Lines: 25
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:eUGg+uivbTAXcZwu76YXspj4YT4=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:60
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3669
Lines: 25
X-Gnus-Newsgroup: langbinding-mbox:60   Sat Jul 19 11:05:40 2003

Rene Rivera <[email protected]> writes:

> I thought that for such a restructuring you would not want to mess with the
> current BP, even if on a branch? 

That's what branches are for!

> But I can see that it would be easier than copying over a bunch of
> BP code.

Yep.

> Any ideas/preferences on: Where do we discuss the refactoring of the
> common code and the laubind dev? It seems like noise polution to
> keep it on this list. Daniel do you have a non-user list set up for
> LuaBind? Or we can add a list to the SF boost project.

I prefer here, but only a little.  Those interested in Boost.Python
internals (I'm thinking of people like Brett Calcott and Dirk Gerrits
here) would have to subscribe to whatever other forum we pick.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:40 2003
Path: main.gmane.org!not-for-mail
From: Daniel Wallin <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Fri, 04 Jul 2003 08:45:06 +0200
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Trace: main.gmane.org 1057300955 11109 80.91.224.249 (4 Jul 2003 06:42:35 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 06:42:35 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 08:42:31 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YKH9-0002se-00
	for <[email protected]>; Fri, 04 Jul 2003 08:42:31 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YKHf-0002Vy-00; Fri, 04 Jul 2003 02:43:03 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YKHI-00022P-00
	for [email protected]; Fri, 04 Jul 2003 02:42:41 -0400
Original-Received: from dj.student.umu.se (h81172170009.kund.kommunicera.umea.se [81.172.170.9])
	by mail.umu.se (8.12.4/8.12.4) with ESMTP id h646geFM025478
	for <[email protected]>; Fri, 4 Jul 2003 08:42:40 +0200 (MEST)
X-Sender: [email protected]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:61
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3674
Lines: 28
X-Gnus-Newsgroup: langbinding-mbox:61   Sat Jul 19 11:05:40 2003

At 01:59 2003-07-04, you wrote:
>[2003-07-03] David Abrahams wrote:
>
> >> After that finding out what I and others can help with; deciding
> >> where to put the work; what to name / where to put the common code;
> >> do we want to move the dev discussion to a dedicated list; etc.
> >>
> >> Some possible answers to those:
> >>
> >> I imagine doing some of this in the boost-sandbox project is
> >> best.
> >
> >I'm not sure; I want to refactor parts of Boost.Python anyway.  Given
> >that we have a pile of tests, etc., I think it would be better to do
> >this evolution in the main CVS.  On a branch, if nothing else.
>
><snip>
>
>Any ideas/preferences on: Where do we discuss the refactoring of the common
>code and the laubind dev? It seems like noise polution to keep it on this
>list. Daniel do you have a non-user list set up for LuaBind? Or we can add a
>list to the SF boost project.

We don't have any non-user list, but I could add one if needed.
I think I would prefer a separate list, for easy archiving purposes. :)


Daniel Wallin, [email protected]
From nobody Sat Jul 19 11:05:40 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Fri, 04 Jul 2003 19:55:04 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1057362943 27740 80.91.224.249 (4 Jul 2003 23:55:43 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 23:55:43 +0000 (UTC)
Original-X-From: [email protected] Sat Jul 05 01:55:41 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YaOz-0007D9-00
	for <[email protected]>; Sat, 05 Jul 2003 01:55:41 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YaPX-0002Jk-00; Fri, 04 Jul 2003 19:56:15 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19YaOc-00020g-00
	for [email protected]; Fri, 04 Jul 2003 19:55:18 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YaO1-0007AW-00
	for <[email protected]>; Sat, 05 Jul 2003 01:54:41 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YaNx-0007A3-00
	for <[email protected]>; Sat, 05 Jul 2003 01:54:37 +0200
Original-Lines: 18
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:QiDK2R50tabJCwjzi1cKIogDTVQ=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:62
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3690
Lines: 18
X-Gnus-Newsgroup: langbinding-mbox:62   Sat Jul 19 11:05:40 2003

Daniel Wallin <[email protected]> writes:

>>Any ideas/preferences on: Where do we discuss the refactoring of the common
>>code and the laubind dev? It seems like noise polution to keep it on this
>>list. Daniel do you have a non-user list set up for LuaBind? Or we can add a
>>list to the SF boost project.
>
> We don't have any non-user list, but I could add one if needed.
> I think I would prefer a separate list, for easy archiving purposes. :)

OK, I just requested [email protected].  When it is
activeated sometime in the next 24 hours you can subscribe at
http://lists.sourceforge.net/mailman/listinfo/boost-langbinding

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Fri, 04 Jul 2003 20:46:12 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
 <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1057365994 12958 80.91.224.249 (5 Jul 2003 00:46:34 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sat, 5 Jul 2003 00:46:34 +0000 (UTC)
Original-X-From: [email protected] Sat Jul 05 02:46:30 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YbCA-0003Ma-00
	for <[email protected]>; Sat, 05 Jul 2003 02:46:30 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YbCh-00026d-00; Fri, 04 Jul 2003 20:47:03 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19YbC2-0001Zy-00
	for [email protected]; Fri, 04 Jul 2003 20:46:22 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YbBR-0003LF-00
	for <[email protected]>; Sat, 05 Jul 2003 02:45:45 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YbBQ-0003L5-00
	for <[email protected]>; Sat, 05 Jul 2003 02:45:44 +0200
Original-Lines: 22
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:69t68oeCwgB9ioV3BSFBNC/bVUw=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:63
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3694
Lines: 22
X-Gnus-Newsgroup: langbinding-mbox:63   Sat Jul 19 11:05:41 2003

David Abrahams <[email protected]> writes:

> Daniel Wallin <[email protected]> writes:
>
>>>Any ideas/preferences on: Where do we discuss the refactoring of the common
>>>code and the laubind dev? It seems like noise polution to keep it on this
>>>list. Daniel do you have a non-user list set up for LuaBind? Or we can add a
>>>list to the SF boost project.
>>
>> We don't have any non-user list, but I could add one if needed.
>> I think I would prefer a separate list, for easy archiving purposes. :)
>
> OK, I just requested [email protected].  When it is
> activeated sometime in the next 24 hours you can subscribe at
> http://lists.sourceforge.net/mailman/listinfo/boost-langbinding

It's up now.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: Daniel Wallin <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Sat, 05 Jul 2003 15:59:04 +0200
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
 <[email protected]>
 <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Trace: main.gmane.org 1057413392 32469 80.91.224.249 (5 Jul 2003 13:56:32 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Sat, 5 Jul 2003 13:56:32 +0000 (UTC)
Original-X-From: [email protected] Sat Jul 05 15:56:30 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YnWf-0008RO-00
	for <[email protected]>; Sat, 05 Jul 2003 15:56:30 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YnXD-0000tY-00; Sat, 05 Jul 2003 09:57:03 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YnWp-0000sa-00
	for [email protected]; Sat, 05 Jul 2003 09:56:39 -0400
Original-Received: from dj.student.umu.se (h81172170009.kund.kommunicera.umea.se [81.172.170.9])
	by mail.umu.se (8.12.4/8.12.4) with ESMTP id h65DucFM066902
	for <[email protected]>; Sat, 5 Jul 2003 15:56:38 +0200 (MEST)
X-Sender: [email protected]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:64
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3710
Lines: 17
X-Gnus-Newsgroup: langbinding-mbox:64   Sat Jul 19 11:05:41 2003

At 02:46 2003-07-05, you wrote:
>David Abrahams <[email protected]> writes:
>
> > Daniel Wallin <[email protected]> writes:
> >> We don't have any non-user list, but I could add one if needed.
> >> I think I would prefer a separate list, for easy archiving purposes. :)
> >
> > OK, I just requested [email protected].  When it is
> > activeated sometime in the next 24 hours you can subscribe at
> > http://lists.sourceforge.net/mailman/listinfo/boost-langbinding
>
>It's up now.

Ok great.

---
Daniel Wallin
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: Daniel Wallin <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu, 03 Jul 2003 23:50:59 +0200
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
 <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Trace: main.gmane.org 1057268917 31274 80.91.224.249 (3 Jul 2003 21:48:37 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 3 Jul 2003 21:48:37 +0000 (UTC)
Original-X-From: [email protected] Thu Jul 03 23:48:35 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YBwR-00088A-00
	for <[email protected]>; Thu, 03 Jul 2003 23:48:35 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YBws-0004FQ-00; Thu, 03 Jul 2003 17:49:02 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YBwR-0004Cm-00
	for [email protected]; Thu, 03 Jul 2003 17:48:35 -0400
Original-Received: from dj.student.umu.se (h81172170009.kund.kommunicera.umea.se [81.172.170.9])
	by mail.umu.se (8.12.4/8.12.4) with ESMTP id h63LmYFM089415
	for <[email protected]>; Thu, 3 Jul 2003 23:48:34 +0200 (MEST)
X-Sender: [email protected]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:65
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3647
Lines: 42
X-Gnus-Newsgroup: langbinding-mbox:65   Sat Jul 19 11:05:41 2003

At 19:33 2003-07-03, you wrote:
>Rene Rivera <[email protected]> writes:
>
> > [2003-07-01] Daniel Wallin wrote:
> >
> >>
> >>I don't know. I'm sure more issues will pop up later on though. :)
> >>How do we proceed from here?
>
> > After that finding out what I and others can help with; deciding
> > where to put the work; what to name / where to put the common code;
> > do we want to move the dev discussion to a dedicated list; etc.
> >
> > Some possible answers to those:
> >
> > Question is do we do all the dev work there or do we keep the
> > LuaBind part where it is? I can contact Jeremy about adding Daniel
> > and Arvid to it, so that Dave can continue enjoying his vacation ;-)
>
>I think it's best to have everything in one repository so we can be
>aggressive about sharing architecture and technology.

I agree.


> > As for the name of the common code, I think there was one previous
> > suggestion which I can't remember. But my suggestion is
> > Boost.Tie. It's on par with Boost.Bind, but tie is one of the terms
> > used for binding at runtime/dynamically. I would assume Boost.Lua
> > would be the conterpart to Boost.Python.
>
>Tie already has a meaning in the tuples library.  I think we ought to
>consider something that has more connotations of _dynamic_ _language_
>binding.  It's a bit unfortunate because we probably don't like some
>of the connotations, but "Boost.Script" might be the most apporpriate
>name.

Script it better.. It doesn't feel good though, but it might just take
some time to get used to. :)


Daniel Wallin, [email protected]
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: Rene Rivera <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu,  3 Jul 2003 19:12:40 -0500
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1057277553 30472 80.91.224.249 (4 Jul 2003 00:12:33 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 00:12:33 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 02:12:31 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YEBi-0007vD-00
	for <[email protected]>; Fri, 04 Jul 2003 02:12:30 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YECF-00075z-00; Thu, 03 Jul 2003 20:13:03 -0400
Original-Received: from 42.muja.mlwk.chcgil24.dsl.att.net
	([12.100.89.42] helo=redshift-software.com ident=root)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YEBh-0006QE-00
	for [email protected]; Thu, 03 Jul 2003 20:12:29 -0400
X-AuthUser: [email protected]
Original-Received: from 12.100.89.43 (12.100.89.43)
	by redshift-software.com with [XMail 1.12 (FreeBSD/Ix86) ESMTP Server]
	id <S12863> for <[email protected]> from <[email protected]>;
	Thu, 03 Jul 2003 19:12:28 -0500
Original-To: [email protected]
X-Priority: 3
In-Reply-To: <[email protected]>
X-Mailer: Mailsmith 1.1.8 (Bluto)
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:66
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3656
Lines: 34
X-Gnus-Newsgroup: langbinding-mbox:66   Sat Jul 19 11:05:41 2003

>>I think it's best to have everything in one repository so we can be
>>aggressive about sharing architecture and technology.
>
>I agree.

OK :-)

>> > As for the name of the common code, I think there was one previous
>> > suggestion which I can't remember. But my suggestion is
>> > Boost.Tie. It's on par with Boost.Bind, but tie is one of the terms
>> > used for binding at runtime/dynamically. I would assume Boost.Lua
>> > would be the conterpart to Boost.Python.
>>
>>Tie already has a meaning in the tuples library.  I think we ought to
>>consider something that has more connotations of _dynamic_ _language_
>>binding.  It's a bit unfortunate because we probably don't like some
>>of the connotations, but "Boost.Script" might be the most apporpriate
>>name.
>
>Script it better.. It doesn't feel good though, but it might just take
>some time to get used to. :)

Script has "limiting" connotations in my mind. After all what happens when
we add bindings for other non-scripting languages like: Lisp/CLOS,
Smalltalk, Haskell, etc. And for non-language related bindings like CORBA,
COM, SOAP, XMLRPC, etc.

Boost.Language is a thought, but too broad. Boost.Bind is taken. ;-)
Boost.Interface might work. Boost.Objects perhaps? Or Boost.ObjectBind?


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: Nicodemus <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu, 03 Jul 2003 21:25:34 -0300
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1057278332 564 80.91.224.249 (4 Jul 2003 00:25:32 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 00:25:32 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 02:25:30 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YEOH-00008d-00
	for <[email protected]>; Fri, 04 Jul 2003 02:25:29 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YEOo-00060b-00; Thu, 03 Jul 2003 20:26:02 -0400
Original-Received: from terra.inf.ufsc.br ([150.162.60.10])
	by mail.python.org with esmtp (Exim 4.05)
	id 19YEOM-0005so-00
	for [email protected]; Thu, 03 Jul 2003 20:25:34 -0400
Original-Received: from localhost (localhost [127.0.0.1])
	by terra.inf.ufsc.br (Departamento de Informatica e Estatistica (INE/CTC/UFSC)) with ESMTP id 6BB4316629
	for <[email protected]>; Thu,  3 Jul 2003 21:25:32 -0300 (BRT)
Original-Received: from globalite.com.br (200-180-008-093.fnsce7002.dsl.brasiltelecom.net.br [200.180.8.93])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by terra.inf.ufsc.br (Departamento de Informatica e Estatistica (INE/CTC/UFSC)) with ESMTP id 5694BB
	for <[email protected]>; Thu,  3 Jul 2003 21:25:29 -0300 (BRT)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
Original-To: [email protected]
In-Reply-To: <[email protected]>
X-Virus-Scanned: by AMaViS 0.3.12pre5
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:67
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3658
Lines: 13
X-Gnus-Newsgroup: langbinding-mbox:67   Sat Jul 19 11:05:41 2003

Rene Rivera wrote:

>Script has "limiting" connotations in my mind. After all what happens when
>we add bindings for other non-scripting languages like: Lisp/CLOS,
>Smalltalk, Haskell, etc. And for non-language related bindings like CORBA,
>COM, SOAP, XMLRPC, etc.
>
>Boost.Language is a thought, but too broad. Boost.Bind is taken. ;-)
>Boost.Interface might work. Boost.Objects perhaps? Or Boost.ObjectBind?
>  
>
Perhaps Boost.Export? After all, it is all about exporting C++ code to 
other languages... just a thought. 8)
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: "Joel de Guzman" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Fri, 4 Jul 2003 08:28:17 +0800
Sender: [email protected]
Approved: [email protected]
Message-ID: <00d401c341c3$503b0820$0100a8c0@godzilla>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1057278636 7919 80.91.224.249 (4 Jul 2003 00:30:36 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 00:30:36 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 02:30:31 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YET8-0001do-00
	for <[email protected]>; Fri, 04 Jul 2003 02:30:30 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YETf-0006ls-00; Thu, 03 Jul 2003 20:31:03 -0400
Original-Received: from mail.gmx.net ([213.165.64.20])
	by mail.python.org with smtp (Exim 4.05)
	id 19YESj-0006df-00
	for [email protected]; Thu, 03 Jul 2003 20:30:05 -0400
Original-Received: (qmail 21802 invoked by uid 65534); 4 Jul 2003 00:29:20 -0000
Original-Received: from info12-239.info.com.ph (EHLO godzilla) (202.163.253.239)
  by mail.gmx.net (mp003) with SMTP; 04 Jul 2003 02:29:20 +0200
Original-To: <[email protected]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:68
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3661
Lines: 25
X-Gnus-Newsgroup: langbinding-mbox:68   Sat Jul 19 11:05:41 2003

Nicodemus <[email protected]> wrote:
> Rene Rivera wrote:
> 
>> Script has "limiting" connotations in my mind. After all
>> what happens when we add bindings for other
>> non-scripting languages like: Lisp/CLOS, Smalltalk,
>> Haskell, etc. And for non-language related bindings like
>> CORBA, COM, SOAP, XMLRPC, etc. 
>> 
>> Boost.Language is a thought, but too broad. Boost.Bind
>> is taken. ;-) Boost.Interface might work. Boost.Objects
>> perhaps? Or Boost.ObjectBind? 
>> 
>> 
> Perhaps Boost.Export? After all, it is all about
> exporting C++ code to other languages... just a thought.
> 8) 

Boost.Export is a good name.

-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: Rene Rivera <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu,  3 Jul 2003 20:06:42 -0500
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <00d401c341c3$503b0820$0100a8c0@godzilla>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: main.gmane.org 1057280795 21960 80.91.224.249 (4 Jul 2003 01:06:35 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 01:06:35 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 03:06:31 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YF1z-0005hc-00
	for <[email protected]>; Fri, 04 Jul 2003 03:06:31 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YF2U-0004PC-00; Thu, 03 Jul 2003 21:07:02 -0400
Original-Received: from 42.muja.mlwk.chcgil24.dsl.att.net
	([12.100.89.42] helo=redshift-software.com ident=root)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YF20-000490-00
	for [email protected]; Thu, 03 Jul 2003 21:06:32 -0400
X-AuthUser: [email protected]
Original-Received: from 12.100.89.43 (12.100.89.43)
	by redshift-software.com with [XMail 1.12 (FreeBSD/Ix86) ESMTP Server]
	id <S1286F> for <[email protected]> from <[email protected]>;
	Thu, 03 Jul 2003 20:06:30 -0500
Original-To: [email protected]
X-Priority: 3
In-Reply-To: <00d401c341c3$503b0820$0100a8c0@godzilla>
X-Mailer: Mailsmith 1.1.8 (Bluto)
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:69
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3665
Lines: 28
X-Gnus-Newsgroup: langbinding-mbox:69   Sat Jul 19 11:05:41 2003

[2003-07-04] Joel de Guzman wrote:

>Nicodemus <[email protected]> wrote:
>> Rene Rivera wrote:
>> 
>>> Script has "limiting" connotations in my mind. After all
>>> what happens when we add bindings for other
>>> non-scripting languages like: Lisp/CLOS, Smalltalk,
>>> Haskell, etc. And for non-language related bindings like
>>> CORBA, COM, SOAP, XMLRPC, etc. 
>>> 
>>> Boost.Language is a thought, but too broad. Boost.Bind
>>> is taken. ;-) Boost.Interface might work. Boost.Objects
>>> perhaps? Or Boost.ObjectBind? 
>>> 
>>> 
>> Perhaps Boost.Export? After all, it is all about
>> exporting C++ code to other languages... just a thought.
>> 8) 
>
>Boost.Export is a good name.

Yes, good suggestion indeed :-)


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Thu, 03 Jul 2003 22:55:43 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <00d401c341c3$503b0820$0100a8c0@godzilla> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1057287332 8537 80.91.224.249 (4 Jul 2003 02:55:32 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 02:55:32 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 04:55:30 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YGjS-0002DY-00
	for <[email protected]>; Fri, 04 Jul 2003 04:55:30 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YGjz-0008VE-00; Thu, 03 Jul 2003 22:56:03 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19YGjq-0008V3-00
	for [email protected]; Thu, 03 Jul 2003 22:55:54 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YGjH-0002DH-00
	for <[email protected]>; Fri, 04 Jul 2003 04:55:19 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YGjG-0002D8-00
	for <[email protected]>; Fri, 04 Jul 2003 04:55:18 +0200
Original-Lines: 43
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:wUvRwvYaqH0J+lnctJZq4lc4tdM=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:70
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3670
Lines: 43
X-Gnus-Newsgroup: langbinding-mbox:70   Sat Jul 19 11:05:41 2003

Rene Rivera <[email protected]> writes:

> [2003-07-04] Joel de Guzman wrote:
>
>>Nicodemus <[email protected]> wrote:
>>> Rene Rivera wrote:
>>> 
>>>> Script has "limiting" connotations in my mind. After all
>>>> what happens when we add bindings for other
>>>> non-scripting languages like: Lisp/CLOS, Smalltalk,
>>>> Haskell, etc. And for non-language related bindings like
>>>> CORBA, COM, SOAP, XMLRPC, etc. 
>>>> 
>>>> Boost.Language is a thought, but too broad. Boost.Bind
>>>> is taken. ;-) Boost.Interface might work. Boost.Objects
>>>> perhaps? Or Boost.ObjectBind? 
>>>> 
>>>> 
>>> Perhaps Boost.Export? After all, it is all about
>>> exporting C++ code to other languages... just a thought.
>>> 8) 
>>
>>Boost.Export is a good name.
>
> Yes, good suggestion indeed :-)

Too general, IMO, as are Boost.Interface, Boost.Objects, and
Boost.ObjectBind.  Also almost all of the code will be specific to
dynamic languages, so I don't see how Haskell can figure into this.
Your other points are well taken.  

Another too-general name which I like better than others so far:
Boost.Binding.

OTOH, I think this is a bicycle shed question.  Notice how many
responses we got all of a sudden in this thread? <wink>.  Anyway, this
is just a library for library writers and I'm content to call it "the
common core" until we really need a name.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: "Ralf W. Grosse-Kunstleve" <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu, 3 Jul 2003 21:12:41 -0700 (PDT)
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1057291954 20237 80.91.224.249 (4 Jul 2003 04:12:34 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 04:12:34 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 06:12:32 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YHvz-0005GE-00
	for <[email protected]>; Fri, 04 Jul 2003 06:12:31 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YHwV-00059q-00; Fri, 04 Jul 2003 00:13:03 -0400
Original-Received: from web20201.mail.yahoo.com ([216.136.226.56])
	by mail.python.org with smtp (Exim 4.05)
	id 19YHwB-0004pd-00
	for [email protected]; Fri, 04 Jul 2003 00:12:43 -0400
Original-Received: from [128.3.132.62] by web20201.mail.yahoo.com via HTTP; Thu, 03 Jul 2003 21:12:41 PDT
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:71
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3672
Lines: 20
X-Gnus-Newsgroup: langbinding-mbox:71   Sat Jul 19 11:05:41 2003

--- Rene Rivera <[email protected]> wrote:
> [2003-07-04] Joel de Guzman wrote:
> 
> >Nicodemus <[email protected]> wrote:
> >> Rene Rivera wrote:
> >> 
> >>> Script has "limiting" connotations in my mind. After all
> >>> what happens when we add bindings for other
> >>> non-scripting languages like: Lisp/CLOS, Smalltalk,
> >>> Haskell, etc. And for non-language related bindings like
> >>> CORBA, COM, SOAP, XMLRPC, etc. 

Hm, so many guests... it must be a Boost.Party!
Ralf


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: Daniel Wallin <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Thu, 03 Jul 2003 23:41:00 +0200
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Trace: main.gmane.org 1057268314 28618 80.91.224.249 (3 Jul 2003 21:38:34 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 3 Jul 2003 21:38:34 +0000 (UTC)
Original-X-From: [email protected] Thu Jul 03 23:38:31 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YBmh-0007RL-00
	for <[email protected]>; Thu, 03 Jul 2003 23:38:31 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YBnC-00050D-00; Thu, 03 Jul 2003 17:39:02 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YBmn-0004n0-00
	for [email protected]; Thu, 03 Jul 2003 17:38:37 -0400
Original-Received: from dj.student.umu.se (h81172170009.kund.kommunicera.umea.se [81.172.170.9])
	by mail.umu.se (8.12.4/8.12.4) with ESMTP id h63LcZFM086301
	for <[email protected]>; Thu, 3 Jul 2003 23:38:36 +0200 (MEST)
X-Sender: [email protected]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:72
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3646
Lines: 23
X-Gnus-Newsgroup: langbinding-mbox:72   Sat Jul 19 11:05:41 2003

At 22:04 2003-07-01, you wrote:
>[2003-07-01] Daniel Wallin wrote:
>
> >At 00:34 2003-06-29, you wrote:
> >>It sounds like we're converging quite rapidly.  What other
> >>issues do we need to deal with?
> >
> >I don't know. I'm sure more issues will pop up later on though. :)
> >How do we proceed from here?
><snip>
>
>As for the name of the common code, I think there was one previous
>suggestion which I can't remember. But my suggestion is Boost.Tie. It's on
>par with Boost.Bind, but tie is one of the terms used for binding at
>runtime/dynamically. I would assume Boost.Lua would be the conterpart to
>Boost.Python.

I think 'tie' is a bit vague. I don't have any suggestions at the moment 
though.
Also, we would very much like to keep the name 'luabind'.


Daniel Wallin, [email protected]
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Thu, 03 Jul 2003 19:39:37 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1057275574 24341 80.91.224.249 (3 Jul 2003 23:39:34 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Thu, 3 Jul 2003 23:39:34 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 01:39:32 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YDfn-0006KD-00
	for <[email protected]>; Fri, 04 Jul 2003 01:39:32 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YDgJ-0005qD-00; Thu, 03 Jul 2003 19:40:03 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19YDg3-0005pw-00
	for [email protected]; Thu, 03 Jul 2003 19:39:47 -0400
Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YDfU-0006Ja-00
	for <[email protected]>; Fri, 04 Jul 2003 01:39:12 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YDfT-0006JO-00
	for <[email protected]>; Fri, 04 Jul 2003 01:39:11 +0200
Original-Lines: 56
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:k7B0m/xA7/IX3/6fgHolYf09NPE=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:73
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3650
Lines: 56
X-Gnus-Newsgroup: langbinding-mbox:73   Sat Jul 19 11:05:41 2003

Daniel Wallin <[email protected]> writes:

> At 00:34 2003-06-29, you wrote:
>>"Daniel Wallin" <[email protected]> writes:
>>
> Ok, I have very little knowledge in how Python memory management
> works. In luabind we always allocate dynamically. We also don't
> support multiple inheritance from wrapped classes.

Oh, but that's cheap.  At least in Boost.Python it is.  I assume it
would be the same in luabind if you were using holders.

>>Well, OK, actually I suppose the argument forwarding problem
>>(http://tinyurl.com/fist) causes a lot of additional
>>complexity because references need to be passed through
>>reference_wrapper<T> arguments, and that would go away if
>>there were no value_holders.  I barely even notice that
>>anymore, since it was part of BPLv1... but now that you
>>mention it, value_holder is probably causing more
>>complication in the code than in-place holder allocation.
>>Eliminating both might be a huge simplification.
>>Additionally, it might become possible to convert nearly any
>>object to nearly any kind of smart pointer.  value_holders
>>impose some real limitations on usability.
>
> The actual allocation of the holders could be in a language
> dependent layer though, in which case it would be an implementation
> detail if it's in-place or heap allocated. We don't have any issues
> with allocating the holder memory together with the instance object
> in lua.

But without value_holders it seems silly, and value_holders
themselves seem to lead to a great deal of complication, soo...

Looking at the big picture I'm rather inclined to go with something
much simpler.  I guess that using placement new in value holders
might be a way to gain a whole lot of simplicity, though.

OK, here's my conclusion (hope you agree): there's no need for
value_holders or in-dynamic-object allocation of C++ data in any
initial merged version of the library.  We can always optimize later
if it doesn't incur too much code complexity.

>>It sounds like we're converging quite rapidly.  What other
>>issues do we need to deal with?
>
> I don't know. I'm sure more issues will pop up later on though. :)
> How do we proceed from here?

I think Rene raised that already; let's continue in that branch of
the thread.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: Daniel Wallin <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Re: Interest in luabind
Date: Fri, 04 Jul 2003 08:39:52 +0200
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]>
 <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Trace: main.gmane.org 1057300659 10153 80.91.224.249 (4 Jul 2003 06:37:39 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 06:37:39 +0000 (UTC)
Original-X-From: [email protected] Fri Jul 04 08:37:37 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YKCP-0002dZ-00
	for <[email protected]>; Fri, 04 Jul 2003 08:37:37 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YKCt-0008GS-00; Fri, 04 Jul 2003 02:38:07 -0400
Original-Received: from jazz.umdac.umu.se ([130.239.8.31] helo=mail.umu.se)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YKCF-00082U-00
	for [email protected]; Fri, 04 Jul 2003 02:37:32 -0400
Original-Received: from dj.student.umu.se (h81172170009.kund.kommunicera.umea.se [81.172.170.9])
	by mail.umu.se (8.12.4/8.12.4) with ESMTP id h646bPFM023284
	for <[email protected]>; Fri, 4 Jul 2003 08:37:26 +0200 (MEST)
X-Sender: [email protected]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Original-To: [email protected]
In-Reply-To: <[email protected]>
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:74
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3673
Lines: 61
X-Gnus-Newsgroup: langbinding-mbox:74   Sat Jul 19 11:05:41 2003

At 01:39 2003-07-04, you wrote:
>Daniel Wallin <[email protected]> writes:
>
> > At 00:34 2003-06-29, you wrote:
> >>"Daniel Wallin" <[email protected]> writes:
> >>
> > Ok, I have very little knowledge in how Python memory management
> > works. In luabind we always allocate dynamically. We also don't
> > support multiple inheritance from wrapped classes.
>
>Oh, but that's cheap.  At least in Boost.Python it is.  I assume it
>would be the same in luabind if you were using holders.

Yeah it would. The thing is that lua doesn't have classes, all
it has is the ability to 'hook' on certain events on objects, so
the class system is something luabind introduces. Multiple
inheritance would mean we would need to make some
decisions on how to handle method-dispatching, and how
to handle diamond shapes.

This is isolated behavior of the luabind class-system though, so it
has nothing to do with the shared code. Although, we might introduce
MI if there is sufficient need for it.

> >>Well, OK, actually I suppose the argument forwarding problem
> >>(http://tinyurl.com/fist) causes a lot of additional
> >>complexity because references need to be passed through
> >>reference_wrapper<T> arguments, and that would go away if
> >>there were no value_holders.  I barely even notice that
> >>anymore, since it was part of BPLv1... but now that you
> >>mention it, value_holder is probably causing more
> >>complication in the code than in-place holder allocation.
> >>Eliminating both might be a huge simplification.
> >>Additionally, it might become possible to convert nearly any
> >>object to nearly any kind of smart pointer.  value_holders
> >>impose some real limitations on usability.
> >
> > The actual allocation of the holders could be in a language
> > dependent layer though, in which case it would be an implementation
> > detail if it's in-place or heap allocated. We don't have any issues
> > with allocating the holder memory together with the instance object
> > in lua.
>
>But without value_holders it seems silly, and value_holders
>themselves seem to lead to a great deal of complication, soo...
>
>Looking at the big picture I'm rather inclined to go with something
>much simpler.  I guess that using placement new in value holders
>might be a way to gain a whole lot of simplicity, though.
>
>OK, here's my conclusion (hope you agree): there's no need for
>value_holders or in-dynamic-object allocation of C++ data in any
>initial merged version of the library.  We can always optimize later
>if it doesn't incur too much code complexity.

I agree that value_holders isn't needed in the initial version, but having
functions that allocate the storage for holders in language dependent
code doesn't really add any complexity.


Daniel Wallin, [email protected]
From nobody Sat Jul 19 11:05:41 2003
Path: main.gmane.org!not-for-mail
From: David Abrahams <[email protected]>
Newsgroups: gmane.comp.python.c++
Subject: Re: Interest in luabind
Date: Fri, 04 Jul 2003 19:48:55 -0400
Sender: [email protected]
Approved: [email protected]
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
 <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: main.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: main.gmane.org 1057362632 26911 80.91.224.249 (4 Jul 2003 23:50:32 GMT)
X-Complaints-To: [email protected]
NNTP-Posting-Date: Fri, 4 Jul 2003 23:50:32 +0000 (UTC)
Original-X-From: [email protected] Sat Jul 05 01:50:30 2003
Return-path: <[email protected]>
Original-Received: from mail.python.org ([12.155.117.29])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 19YaJy-0006zm-00
	for <[email protected]>; Sat, 05 Jul 2003 01:50:30 +0200
Original-Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org)
	by mail.python.org with esmtp (Exim 4.05)
	id 19YaKW-0008Vd-00; Fri, 04 Jul 2003 19:51:04 -0400
Original-Received: from main.gmane.org ([80.91.224.249])
	by mail.python.org with esmtp (Exim 4.05)
	id 19YaKB-0008VO-00
	for [email protected]; Fri, 04 Jul 2003 19:50:43 -0400
Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YaJa-0006yn-00
	for <[email protected]>; Sat, 05 Jul 2003 01:50:06 +0200
X-Injected-Via-Gmane: http://gmane.org/
Original-To: [email protected]
Original-Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19YaHz-0006tq-00
	for <[email protected]>; Sat, 05 Jul 2003 01:48:27 +0200
Original-Lines: 57
Original-X-Complaints-To: [email protected]
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)
Cancel-Lock: sha1:8SQHtCQ12KsJ3bRx+ndveMHC2Wo=
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13 (101270)
Precedence: bulk
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=subscribe>
List-Id: Development of Python/C++ integration <c++-sig.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/c++-sig>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/c++-sig/>
Xref: PENGUIN langbinding-mbox:75
X-Report-Spam: http://spam.gmane.org/gmane.comp.python.c++:3689
Lines: 57
X-Gnus-Newsgroup: langbinding-mbox:75   Sat Jul 19 11:05:41 2003

Daniel Wallin <[email protected]> writes:

> At 01:39 2003-07-04, you wrote:
>>Daniel Wallin <[email protected]> writes:
>>
>> > At 00:34 2003-06-29, you wrote:
>> >>"Daniel Wallin" <[email protected]> writes:
>> >>
>> > Ok, I have very little knowledge in how Python memory management
>> > works. In luabind we always allocate dynamically. We also don't
>> > support multiple inheritance from wrapped classes.
>>
>>Oh, but that's cheap.  At least in Boost.Python it is.  I assume it
>>would be the same in luabind if you were using holders.
>
> Yeah it would. The thing is that lua doesn't have classes, all it
> has is the ability to 'hook' on certain events on objects, so the
> class system is something luabind introduces. Multiple inheritance
> would mean we would need to make some decisions on how to handle
> method-dispatching, and how to handle diamond shapes.

I understand.  Sounds like you made a good trade-off.

> This is isolated behavior of the luabind class-system though, so it
> has nothing to do with the shared code. Although, we might introduce
> MI if there is sufficient need for it.

Doesn't sound like it would be worthwhile.

>> > The actual allocation of the holders could be in a language
>> > dependent layer though, in which case it would be an implementation
>> > detail if it's in-place or heap allocated. We don't have any issues
>> > with allocating the holder memory together with the instance object
>> > in lua.
>>
>>But without value_holders it seems silly, and value_holders
>>themselves seem to lead to a great deal of complication, soo...
>>
>>Looking at the big picture I'm rather inclined to go with something
>>much simpler.  I guess that using placement new in value holders
>>might be a way to gain a whole lot of simplicity, though.
>>
>>OK, here's my conclusion (hope you agree): there's no need for
>>value_holders or in-dynamic-object allocation of C++ data in any
>>initial merged version of the library.  We can always optimize later
>>if it doesn't incur too much code complexity.
>
> I agree that value_holders isn't needed in the initial version, but having
> functions that allocate the storage for holders in language dependent
> code doesn't really add any complexity.

Agreed.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
From nobody Sat Jul 19 11:06:11 2003
Return-Path: <[email protected]>
Received: by stlport.com (CommuniGate Pro PIPE 3.5.9)
  with PIPE id 284289; Wed, 16 Jul 2003 14:58:49 -0700
Received: from [66.35.250.206] (HELO sc8-sf-list2.sourceforge.net)
	by stlport.com (CommuniGate Pro SMTP 3.5.9)
	with ESMTP-TLS id 284288 for [email protected];
	Wed, 16 Jul 2003 14:58:38 -0700
Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13]
	helo=sc8-sf-list1.sourceforge.net)(Debian))
	id 19cuIa-0005ue-00; Wed, 16 Jul 2003 14:58:56 -0700
Received: from cci.lbl.gov ([128.3.132.98] helo=boa.lbl.gov)(Debian))
	id 19cuHV-0000lg-00	for <[email protected]>;
	Wed, 16 Jul 2003 14:57:49 -0700
Received: from boa.lbl.gov (localhost [127.0.0.1])
	by boa.lbl.gov (8.12.9/8.12.9) with ESMTP id h6GLvnS1087414;
	Wed, 16 Jul 2003 14:57:49 -0700 (PDT)
Received: (from rwgk@localhost)
	by boa.lbl.gov (8.12.9/8.12.9/Submit) id h6GLvnFl087406;
	Wed, 16 Jul 2003 14:57:49 -0700 (PDT)
From: "Ralf W. Grosse-Kunstleve" <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: [Boost-langbinding] Registries
Cc: [email protected]
Sender: [email protected]
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [email protected]
List-Help: <mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/boost-langbinding>,
	<mailto:[email protected]?subject=subscribe>
List-Id: <boost-langbinding.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/boost-langbinding>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=boost-langbinding>
Date: Wed, 16 Jul 2003 14:57:49 -0700 (PDT)
X-Spambayes-Classification: ham; 0.00
X-Mailer: CommuniGate Pro CLI mailer
Lines: 62
Xref: PENGUIN langbinding-mbox:76
X-Gnus-Newsgroup: langbinding-mbox:76   Sat Jul 19 11:06:11 2003

> Ralf, what was the compelling use case for registry scoping anyway?
> It had something to do with to-python converters and the fact that
> there is only one per type.  Can you lay it out in detail?

A few weeks after the release of Boost.Python V2 someone complained
about conflicting converters:

http://mail.python.org/pipermail/c++-sig/2002-December/002944.html

Selected related messages:

http://mail.python.org/pipermail/c++-sig/2002-December/002961.html
http://mail.python.org/pipermail/c++-sig/2002-December/002974.html
http://mail.python.org/pipermail/c++-sig/2002-December/002989.html

We found a workaround...

http://mail.python.org/pipermail/c++-sig/2002-December/002972.html

and so far there have not been any similar, publically voiced
complaints.

So is it a *real* problem? I am not sure. It could become a little bit
of a nightmare if the number of packages using Boost.Python keeps
growing. People will start using them in unforeseen combinations
and there will likely be conflicting bindings for types such as
std::vector<> or std::map<>.

A bit of potentially silly brainstorming:

>From discussions with David I got the feeling that runtime efficiency
considerations are a major obstacle in finding a viable solution. I.e.
my understanding is that there are various options of implementing
scoped converters, but that it would make the converter lookup
significantly slower. Now I am wondering if we couldn't have a
two-tiered system:

  global registry, unscoped but fast
  scoped registry, scoped but slow

The scoped registry could work with user-defined namespace identifiers
(strings). Each extension module could have a special attribute (e.g.
__converter_scopes__ = ["package1", "package2"]) defining which scopes
are considered in the converter lookup. The scoped registry is
consulted only if there is no match in the global registry.
This would be a perfect solution for people like me who don't
care very much about runtime efficiency at the language boundary
(because most of the runtime is spent in the compiled layer).

Ralf


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0