Physics: grab objects crashes the activity

[manuq]

Seems something with the PyGame:

AttributeError: 'b2MouseJoint' object has no attribute 'getAsType'

Complete log attached.

[manuq]

Test Case:

1. create an object, ie a circle
2. change to the grab tool (hand icon)
3. grab the circle (click + drag)

Circle should be grabbed, activity should not crash :P

[manuq]

Tested in olpc build os5 with XO1.5 and XO1.75, both crash with the same AttributeError.

[manuq]

This does not happen in my dev machine with F16 and it has the same pygame version as the XOs:

pygame.version.ver == '1.9.1release'

[manuq]

Seems that the included Elements egg is old.

In physics.py we have:

sys.path.append("lib/Elements-0.13-py2.5.egg")
sys.path.append("lib/Box2D-2.0.2b1-py2.5-linux-i686.egg")

and below:

import elements

If I debug elements.file, in my dev machine I have:

'/usr/lib/python2.7/site-packages/elements/init.pyc'

Instead in the XOs I have:

"lib/Elements-0.13-py2.5.egg"

That seems for python 2.5.

[manuq]

Tried replacing Elements egg with the module in my site_packages for Python 2.7 and the crash is still there.

A quick grep shows that the attribute that is not found, "b2MouseJoint", is from Box2D. So I should replace that one.

[manuq]

Tried replacing Box2D egg with the module in my site_packages for Python 2.7 and still crashes. It has a binary, it may need to be recompiled.

[manuq]

Still happens in os7.

[manuq]

Still happens in os8.

[garycmartin]

Still happening in os9

[humitos]

I tested this in jhbuild with Debian Testing and git version of physics and it do NOT crash. Grab the element works properly.

[humitos]

OK, I found a solution. I have no idea why it works :) , I didn't research too much about the Elements and Box2D libraries but this patch could be tested and understood by others.

I just remove .getAsType() in the line that fails from the Elements library.

These are the steps to apply this patch:

1. unzip Elements-0.13-py2.5.egg

   cd physics/lib
   unzip Elements-0.13-py2.5.egg
   

2. download the patch from this ticket
3. apply the patch

   patch -p0  < Elements-0.13-py2.5.egg.patch
   

That's all. Run the activity again and try this new patch.

I tested this in XO 1.5 and 1.75 both with os9 and it works properly.

[humitos]

I tried to compile Elements and Box2D by myself and I could. I tested it on my Debian machine first but there were some errors (seems like the versions of these libraries are strongly related, I mean, you can't mix them). I tried to fix those errors but there were a lot and I got frustrated and I change the approach.

I updated the elements library from its subversion repository and used the .egg for Box2D. I can make it works in my Debian but when I copy this installation to my 1.5 XO the same issue of this ticket happened.

[humitos]

Just for documentation. I compiled Box2D in XO 1.5 in this way:

sudo yum install python-devel gcc gcc-c++ swig
svn checkout http://pybox2d.googlecode.com/svn/trunk/ pybox2d-read-only
cd pybox2d-read-only
python setup.py build

It worked, but I have the same issue...

[humitos]

I have the grab option working on my XO 1.5 os9. I will make a summary about what I did so we can discuss how continue.

I'm chatting with manuq about this in the #sugar channel.

[humitos]

I will write down here some of my thoughts so Gary can read them and maybe take a decision.

• why are the .eggs in the lib/ directory of physics? are they used by the activity or the activity uses the system ones? how can I do to use those eggs instead the system ones?
• we should write down, in some place, the repository url and the revision used to make those .eggs
• we (manuq and I) found that compiling the latest version from the svn repository and installing it in the XO we can grab the objects with any problem.
• we should make a new fedora package for XO 1.5 and 1.75
• I'm using Debian Testing and I don't have anything related to Box2D installed on my system and the activity works properly. So, Am I using the .egg version? If that is true, the .egg version has no problem at all.

Well, here are some interesting things to start thinking about the final solution of this bug. I think that almost fixed but we need to "give the final step".

[humitos]

Replying to humitos:

python setup.py build

and...

sudo python setup.py install

[dsd]

The Box2D egg in lib/ is not used, since recent OLPC builds include the pybox2d package in /usr/lib/python2.7/site-packages.

The Box2D egg was built using SWIG 1.x, whereas the one in site-packages was built with SWIG 2.x.

Elements calls into Box2D and is sensitive to the API generated by SWIG. The Elements egg in Physics seems to depend on the SWIG 1.x API, but since we're using the box2d from SWIG 2.x, we get this crash.

Elements upstream seems to be dead (​http://elements.linuxuser.at/ doesn't load).

The above patch (removing .getAsType() call) is correct here.

This will break compatibility with older Box2D versions. I suggest removing the one in lib/.

[garycmartin]

Replying to dsd:

The Box2D egg in lib/ is not used, since recent OLPC builds include the pybox2d package in /usr/lib/python2.7/site-packages.

The Box2D egg was built using SWIG 1.x, whereas the one in site-packages was built with SWIG 2.x.

Elements calls into Box2D and is sensitive to the API generated by SWIG. The Elements egg in Physics seems to depend on the SWIG 1.x API, but since we're using the box2d from SWIG 2.x, we get this crash.

Elements upstream seems to be dead (​http://elements.linuxuser.at/ doesn't load).

Thanks Daniel, I've found the svn at least at ​http://www.assembla.com/wiki/show/elements but yes the project appears dead now. We had plans to see if we could drop Elements as a dependency and deal directly with box2d, but now is probably not the time to try that... I need to have a tinker and see what is practical for a soon to be release, thanks for the comment/effort, will definitely be of help.

The above patch (removing .getAsType() call) is correct here.

This will break compatibility with older Box2D versions. I suggest removing the one in lib/.

[manuq]

version 1, remove pybox2d egg, fix elements egg

[manuq]

version 2 (alternative), remove both eggs, fix elements in the unzipped code

[manuq]

Attached two potential patches. They are big because the eggs are being removed.

In the first, pybox2d egg is removed, and Elements is fixed as per humitos patch, inside the egg binary. In the second, I removed both eggs and unzipped Elements so this fix (and the potential new fixes to come) is not being done in a binary. As Gary, humitos and I spotted, Elements is abandoned, this will not be fixed upstream. And Physics may turn to use pybox2d directly.

[humitos]

OK. I tested both patches (v1 and v2) in XO 1.5 and 1.75 with os12 and it worked properly. No problem at all. I can drag and drop any element in Physics.

[garycmartin]

The whole point of the box3d and elements eggs are that earlier (still deployed builds) do not include these dependancies, Physics still works with all shipped OLPC builds, dropping them will just break Physics in existing deployments. BTW I am trying to patch this still myself...

[dsd]

In other cases we are choosing to break compatibility with old versions, or at least pre-2011, because of the overhead involved. Anyway, it is a matter personal preference.

To keep compatibility you could do something like:

self.parent.mouseJoint = self.parent.world.CreateJoint(mj)
if hasattr(self.parent.mouseJoint, 'getAsType'):
    self.parent.mouseJoint = self.parent.mouseJoint.getAsType()

[garycmartin]

Fixed with commit f054ae9, available in Physics-10 release. Landed changes to the Elements egg modifying elements/add_objects.py. As the zip blop is a little opaque in git, at about line 515:

if 'getAsType' in dir(box2d.b2Joint):
    self.parent.mouseJoint = self.parent.world.CreateJoint(mj).getAsType()
else:
    self.parent.mouseJoint = self.parent.world.CreateJoint(mj)

Tested on XO-1 build 802; 12.1.0 build 9. XO-1.75 11.3.1 build 885; 12.1.0 build 11. Please test Physics-10 on XO-1.5 if you have hardware available.

[garycmartin]

Replying to dsd:

In other cases we are choosing to break compatibility with old versions, or at least pre-2011, because of the overhead involved. Anyway, it is a matter personal preference.

To keep compatibility you could do something like:

self.parent.mouseJoint = self.parent.world.CreateJoint(mj)
if hasattr(self.parent.mouseJoint, 'getAsType'):
    self.parent.mouseJoint = self.parent.mouseJoint.getAsType()

Thanks Daniel, only just spotted your comment (swamped with ~400 inbox emails). Just landed something very similar in Physics-10, tested on XO-1 and XO-1.75 on several old, current, and new builds (no XO-1.5 here to test).

[manuq]

I have tested Physics 10, it fixes the bug. Daniel can you add to build, then close this ticket?

[FGrose]

Sugar logs

[FGrose]

test version from Walter

[FGrose]

See ​http://lists.sugarlabs.org/archive/soas/2013-December/002610.html

Tested in Fedora 20 TC5 with
sudo yum install @sugar-desktop sugar-runner xorg-x11-server-Xephyr

Launched Physics-11.xo from the Documents folder,
Dropped several triangles into the model,
Switched to the grab tool,
Tried to grab one of the triangles,
Physics disappeared.

Logs attached.

[FGrose]

Launching from the Documents folder was ineffective in extracting all the .xo contents.
Copying to and launching from the Journal after renaming /usr/lib/python2.7/site-packages/elements to hide it was effective in addressing the failure I reported in comment27.