[C++-sig] Boost Python loss of values

[Jay Riley]

I'm having a really weird issue in boost python. I'm focusing on a particular 
property/method to simplify the example. Here's the situation:

In my program, I have a class called Attack. With the following layout 
(simplified for example)

class Attack : public Action
{
public:
virtual int CalculateDamage(const std::vector& users, 
BattleCharacter* target, const std::vector& targets, 
BattleField *field);
protected:
bool Hit;
}

I exposed Attack to python, making it overridable, as follows:

struct AttackWrapper : Game::Battles::Actions::Attack
{
int AttackWrapper::CalculateDamage(const 
std::vector& users, 
Game::Battles::BattleCharacter* target, const 
std::vector& targets, Game::Battles::BattleField *field)
{
   return call_method(self, "CalculateDamage", users, 
ptr(target), targets, ptr(field));
}
int AttackWrapper::CalculateDamageDefault(const 
std::vector& users, 
Game::Battles::BattleCharacter* target, const 
std::vector& targets, Game::Battles::BattleField *field)
{
return this->Attack::CalculateDamage(users, target, Targets, field);
}
}

And the python exposing is done as follows:

class_, bases 
>("Attack")
.def("CalculateDamage", &AttackWrapper::CalculateDamageDefault);


I initially thought everything was working fine, as I can override the 
`CalculateDamage` method within python and have it work correctly. However, 
When I want to use the normal `Attack->CalculateDamage`, the following happens:

I only call `CalculateDamage` when Hit is true, and I can confirm via break 
point when I hit this line, Hit is true:

return call_method(self, "CalculateDamage", users, ptr(target), 
targets, ptr(field));

Now, because I haven't overriden `CalculateDamage` in Python for this attack 
instance, it ends up resolving to `AttackWrapper::CalculateDamageDefault`. But 
by the time I enter AttackWrapper::CalculateDamageDefault, Hit is no longer 
true. That is, when I break on this line:

return this->Attack::CalculateDamage(users, target, Targets, field);

Hit is false. So somewhere between 

return call_method(self, "CalculateDamage", users, ptr(target), 
targets, ptr(field));

resolving to 

return this->Attack::CalculateDamage(users, target, Targets, field);

my property's value is lost. I have no idea what could be causing this. Has 
anyone encountered something like this before?

The attacks I'm using for testing are defined as follows:

class ScriptedAttack(Attack):
def __init__(self, Type, ID, Name, Flags, Targs = ActionTargets.Any, 
AllowTargettingOverride = False, Power = 0, MPCost = 0, SPCost = 0, Accuracy = 
0.9, CritChance = 0.1, DefineOwnUse = False, EleWeights = None, 
StatusEffectChances = None):
if (EleWeights == None and StatusEffectChances == None):
Attack.__init__(self, Type, ID, Name, Flags, Targs, 
AllowTargettingOVerride, Power, MPCost, SPCost, Accuracy, CritChance, 
DefineOwnUse)
else:
Elemap = ElementMap()
if (EleWeights != None):
for Element, Weight in EleWeights.iteritems():
Elemap[Element] = Weight
SEChances = SEChanceMap()
if (StatusEffectChances != None):
for StatusEffect, Chance in StatusEffectChances.iteritems():
SEChances[StatusEffect] = Chance
Attack.__init__(self, Type, ID, Name, Flags, Elemap, Targs, 
AllowTargettingOverride, Power, MPCost, SPCost, Accuracy, CritChance, 
DefineOwnUse, SEChances)
def Clone(self):
return copy.deepcopy(self)

Fire = ScriptedAttack(ActionType.MagicAction, PrimaryEngine.GetUID(), "Fire", 
AttackFlags.Projectile | AttackFlags.Elemental, ActionTargets.Any, True, 32, 
14, 0, 1.0, 0.1, False, {Elements.Fire: 1.0})
Fira = ScriptedAttack(ActionType.MagicAction, PrimaryEngine.GetUID(), "Fira", 
AttackFlags.Projectile | AttackFlags.Elemental, ActionTargets.Any, True, 63, 
35, 0, 1.0, 0.1, False, {Elements.Fire: 1.0})

ActLibrary.AddAttack(Fire)
ActLibrary.AddAttack(Fira)

ActLibrary.AddAttack takes in a boost::shared_ptr and stores it into a 
hash table. I lookup the attack and use the instance stored there to do 
CalculateDamage.

It almost seems like the object is being copied, but I have no idea why that'd 
be so.

Any help would be appreciated.

Thanks
  ___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] getting a list of strings from a static method

[Jim Bosch]

On 08/24/2011 10:07 PM, Josh Stratton wrote:

I'm very new to boost python and trying to figure out how to properly
get a list of strings from a static method in my main namespace.  I'm
not sure if I need to extract the list from the object or if it's
already a list.

boost::python::object list = exec("Foo.extensions()",
_pyMainNamespace); // where Foo.extensions() is a static method
returning a list of strings



Something like this:

namespace bp = boost::python;
bp::object pyList = bp::exec("Foo.extensions()", _pyMainNamespace);
std::vector vec(bp::len(pyList));
for (std::size_t i = 0; i < vec.size(); ++i) {
   vec[i] = bp::extract(pyList[i]);
}


My end goal is to have a QList of QStrings, but if I can somehow get
them to a boost list of std::strings I can take it from there.


I'll leave converting to Qt stuff up to you.  Note that you can also do 
extract(), which may be more efficient if you have really 
large strings and don't want to copy them.


Good Luck!

Jim Bosch

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] Boost Python loss of values

[Jim Bosch]

On 08/25/2011 04:17 AM, Jay Riley wrote:



And the python exposing is done as follows:

class_, bases
 >("Attack")
.def("CalculateDamage", &AttackWrapper::CalculateDamageDefault);



This bit looks a little suspect, and I'm surprised that it compiles - 
class_ should only take 4 arguments if one of them is boost::noncopyable.


I think you mean:

class_< Attack, boost::shared_ptr, bases >
(...)

See

http://www.boost.org/doc/libs/1_47_0/libs/python/doc/v2/class.html

for details of the arguments to class_.

I don't have a good idea as to why this would cause the problem you're 
seeing (maybe you're slicing your AttackWrapper instances into Attack 
instances?) but I'd recommend fixing it first.


Good Luck!

Jim Bosch
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

[C++-sig] New Major-Release Boost.Python Development

[Jim Bosch]

I'd like to start work on a new major release of Boost.Python.  While 
the library is currently well-maintained in terms of bugfixes, I get the 
sense that neither the original developers nor the current maintainer 
have the time or inclination to work on new features.  I'd also like to 
propose some changes that are slightly backwards-incompatible, as well 
as some that mess with the internals to an extent that I'd feel better 
about doing it outside Boost itself, to make it easier for adventurous 
users to play with the new version without affecting people who depend 
on having an extremely stable library in Boost.


To that end, I'm inclined to copy the library to somewhere else 
(possibly the boost sandbox, but more likely a separate site), work on 
it, produce some minor releases, and re-submit it to Boost for review. 
Perhaps the external site would continue on as the home of more 
fine-grained releases, or maybe we would fully reintegrate with Boost at 
that point (especially if Boost addresses some of its own project 
management and release control issues by that point, which I know is 
being discussed but to my knowledge doesn't really have a timeline yet).


I am willing to take the lead on this project; I have a number of 
features that exist as extensions in the boost sandbox already that 
would work better if they could be more fully integrated into the 
Boost.Python core, and I think I have the necessary understanding of the 
full code base to coordinate things.  I'd like to save a full discussion 
of what features a new version would include for another thread, but I 
am hoping other people on the list might volunteer some time to work on 
aspects they have coded up elsewhere - I know many such extensions exist.


So I have a few questions for anyone who's paying attention:

- For the original Boost.Python developers and current maintainers, and 
other people familiar with developing Boost libraries: do you have any 
preference on how to approach this?  I don't want to step on any toes, 
especially toes attached to people who are responsible for the excellent 
library we already have.


- For other Boost.Python experts on this list: do you have existing code 
or development time you'd like to contribute?



Thanks!

Jim Bosch

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] New Major-Release Boost.Python Development

[Stefan Seefeld]

On 08/25/2011 04:59 PM, Jim Bosch wrote:
>
> To that end, I'm inclined to copy the library to somewhere else
> (possibly the boost sandbox, but more likely a separate site), work on
> it, produce some minor releases, and re-submit it to Boost for review.
> Perhaps the external site would continue on as the home of more
> fine-grained releases, or maybe we would fully reintegrate with Boost
> at that point (especially if Boost addresses some of its own project
> management and release control issues by that point, which I know is
> being discussed but to my knowledge doesn't really have a timeline yet).

Jim,

this is an interesting idea. There has been lots of general (dare I say
generic ?) discussion concerning process improvements (which
unfortunately most of the time diverted into tool discussions). Among
the fundamental issues is a modularization of boost.
I think it would be great if boost.python could follow through on its
own, by becoming a separate entity. Thus, I'm fully supportive of such a
move.

> - For the original Boost.Python developers and current maintainers,
> and other people familiar with developing Boost libraries: do you have
> any preference on how to approach this?  I don't want to step on any
> toes, especially toes attached to people who are responsible for the
> excellent library we already have.

I think branching off and moving to a separate site seems a fair choice.
It would be great to "come back" under the "Boost.org" umbrella once
that will be possible, i.e. once the Boost.org structure allows for
that. (In the sake of progress I'm refraining from voicing my personal
preferences for tools or hosting sites. I'm sure I can learn and adapt
to whatever gets agreed on.)

>
> - For other Boost.Python experts on this list: do you have existing
> code or development time you'd like to contribute?

I'd definitely like to help. I have a wishlist of my own for
improvements that I'd like to see, and which I'd be happy to share and
work on.

Thanks,
Stefan

-- 

  ...ich hab' noch einen Koffer in Berlin...

___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] New Major-Release Boost.Python Development

[Ralf Grosse-Kunstleve]

Hi Jim,

CC to Dave.

This is great news.
My main interests have been stability and not increasing the memory
footprint of boost.python extensions. I'm not in a position to further
develop boost.python.
Troy and Ravi have done a significant amount of work. I hope they will
comment for themselves.
I'd prefer if developments stayed under the boost umbrella, e.g. as
boost/python/v3, but I don't feel very strongly about this.

Ralf

On Thu, Aug 25, 2011 at 1:59 PM, Jim Bosch  wrote:

> I'd like to start work on a new major release of Boost.Python.  While the
> library is currently well-maintained in terms of bugfixes, I get the sense
> that neither the original developers nor the current maintainer have the
> time or inclination to work on new features.  I'd also like to propose some
> changes that are slightly backwards-incompatible, as well as some that mess
> with the internals to an extent that I'd feel better about doing it outside
> Boost itself, to make it easier for adventurous users to play with the new
> version without affecting people who depend on having an extremely stable
> library in Boost.
>
> To that end, I'm inclined to copy the library to somewhere else (possibly
> the boost sandbox, but more likely a separate site), work on it, produce
> some minor releases, and re-submit it to Boost for review. Perhaps the
> external site would continue on as the home of more fine-grained releases,
> or maybe we would fully reintegrate with Boost at that point (especially if
> Boost addresses some of its own project management and release control
> issues by that point, which I know is being discussed but to my knowledge
> doesn't really have a timeline yet).
>
> I am willing to take the lead on this project; I have a number of features
> that exist as extensions in the boost sandbox already that would work better
> if they could be more fully integrated into the Boost.Python core, and I
> think I have the necessary understanding of the full code base to coordinate
> things.  I'd like to save a full discussion of what features a new version
> would include for another thread, but I am hoping other people on the list
> might volunteer some time to work on aspects they have coded up elsewhere -
> I know many such extensions exist.
>
> So I have a few questions for anyone who's paying attention:
>
> - For the original Boost.Python developers and current maintainers, and
> other people familiar with developing Boost libraries: do you have any
> preference on how to approach this?  I don't want to step on any toes,
> especially toes attached to people who are responsible for the excellent
> library we already have.
>
> - For other Boost.Python experts on this list: do you have existing code or
> development time you'd like to contribute?
>
>
> Thanks!
>
> Jim Bosch
>
> __**_
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> http://mail.python.org/**mailman/listinfo/cplusplus-sig
>
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig