jim-easterbrook / python-gphoto2

Python interface to libgphoto2
GNU Lesser General Public License v3.0
374 stars 59 forks source link

Most recent branch #5

Closed mdifonzo closed 10 years ago

mdifonzo commented 10 years ago

I'm not sure exactly when this happened, but my examples no longer work with the latest build - here is the issue that I ran into:

This is what I have in my branch: def gp_camera_capture(*args): """ gp_camera_capture(camera, type, path, context) -> int

Parameters:
    camera: Camera *
    type: enum CameraCaptureType
    path: CameraFilePath *
    context: GPContext *

"""

return _gphoto2_camera.gp_camera_capture(*args)

The "path: CameraFilePath *" no longer exists when I run in your latest version, so I can't make use of the capture / trigger_capture functions anymore.

Thanks, Matt

jim-easterbrook commented 10 years ago

This is one of the API changes I made. gp_camera_capture now creates and returns the path. So your gp_camera_capture(camera, type, path, context) -> int becomes gp_camera_capture(camera, type, context) -> int, CameraFilePath

Or have I misunderstood the GPhoto2 documentation and path is a parameter, not an output?

mdifonzo commented 10 years ago

Gotcha. I'll update accordingly. Thanks!

On Sep 7, 2014, at 2:38 AM, Jim Easterbrook notifications@github.com wrote:

This is one of the API changes I made. gp_camera_capture now creates and returns the path. So your gp_camera_capture(camera, type, path, context) -> int becomes gp_camera_capture(camera, type, context) -> int, CameraFilePath

Or have I misunderstood the GPhoto2 documentation and path is a parameter, not an output?

— Reply to this email directly or view it on GitHub.

mdifonzo commented 10 years ago

Hmm, I still can't get that to work. It seems like the return value is not the same as what I was getting from gp.CameraFilePath() so I can't get the folder / file name attributes when I try to call gp_camera_file_get()? I'll take another look.

jim-easterbrook commented 10 years ago

Hmm, maybe this isn't working as I expected. Can you see what type the returned value actually has? (print type(path))

mdifonzo commented 10 years ago

I’m getting type = list on the path. This makes sense since it should be returning [int, CameraFilePath *]. When I check the type for path[1], I am getting type = ‘SwigPyObject’.

On Sep 7, 2014, at 10:08 AM, Jim Easterbrook notifications@github.com wrote:

Hmm, maybe this isn't working as I expected. Can you see what type the returned value actually has? (print type(path))

— Reply to this email directly or view it on GitHub.

jim-easterbrook commented 10 years ago

Ah, that's less than helpful. I guess your other GPhoto2 objects also have ‘SwigPyObject’ type as well. For now you should delete lines 54 to 62 of src/gphoto2/lib/gphoto2_camera.i, recompile and install and go back to passing path in to gp_camera_capture. I'll try to work out what's going on later this week.

mdifonzo commented 10 years ago

Thanks. I’ll try that. Here is what I get from the following (which is what I was using before): campath = gp.CameraFilePath() print (type(campath)) <class 'gphoto2.lib.gphoto2_camera.CameraFilePath’>

On Sep 7, 2014, at 10:19 AM, Jim Easterbrook notifications@github.com wrote:

Ah, that's less than helpful. I guess your other GPhoto2 objects also have ‘SwigPyObject’ type as well. For now you should delete lines 54 to 62 of src/gphoto2/lib/gphoto2_camera.i, recompile and install and go back to passing path in to gp_camera_capture. I'll try to work out what's going on later this week.

— Reply to this email directly or view it on GitHub.

jim-easterbrook commented 10 years ago

Curiouser and curiouser. Before removing those lines, can you send me (or attach) the gphoto2_camera_wrap.c file it produced.

mdifonzo commented 10 years ago

Sure thing. Here you go:

On Sep 7, 2014, at 10:25 AM, Jim Easterbrook notifications@github.com wrote:

Curiouser and curiouser. Before removing those lines, can you send me (or attach) the gphoto2_camera_wrap.c file it produced.

— Reply to this email directly or view it on GitHub.

jim-easterbrook commented 10 years ago

OK. I didn't spot anything untoward in the generated wrapper, but I've managed to reproduce a similar error (AttributeError: 'SwigPyObject' object has no attribute 'text') with another returned value by dropping the -builtin SWIG option. You'd better drop back to commit 5f3ca75 until I sort out what's going on.

mdifonzo commented 10 years ago

Will do. Thanks.

On Sep 7, 2014, at 10:43 AM, Jim Easterbrook notifications@github.com wrote:

OK. I didn't spot anything untoward in the generated wrapper, but I've managed to reproduce a similar error (AttributeError: 'SwigPyObject' object has no attribute 'text') with another returned value by dropping the -builtin SWIG option. You'd better drop back to commit 5f3ca75 until I sort out what's going on.

— Reply to this email directly or view it on GitHub.

jim-easterbrook commented 10 years ago

I hope I've sorted this out now. Will test more thoroughly in future!