hugin-2015.0.0_beta1 has no 'Actions' menu

[tduell]

hugin-2015.0.0_beta1 builds here OK, but has no 'Actions' menu.
I have built using rpmbuild on Fedora 21, using the same .spec file as for recent builds of the default branch and those builds provide the 'Actions' menu, although attempting to use WOA in a recent build of 2014.1.0 did return an error.

[tduell (tduell-iinet)]

It is possible that this is a result of some change in my Fedora system, but not sure what, at this stage.
A build of the current default (hugin-2015.1.0 6899:b30cc246eedc) shows the same behaviour and there are no changes in the default source, since a build of 6887:a8201bc48fa7, which shows the Actions menu, that would appear to affect this.

[Stefan Peter (s-peter-deactivatedaccount)]

Hi tduell

No, this seems to be because the version number has changed from 2014 to 2015. If you start hugin from the command line, you will notice:
/usr/share/hugin/data/plugins/crop_cp.py
   CAT:Control Points
   NAM:Crop Control Points
   fails @api-max
/usr/share/hugin/data/plugins/top_five.py
   CAT:Control Points
   NAM:keep 5 CPs per image pair
   fails @api-max
/usr/share/hugin/data/plugins/woa.py
   CAT:Control Points
   NAM:Warped Overlap Analysis
   fails @api-max
/usr/share/hugin/data/plugins/shooting_pattern.py
   CAT:initial distribution
   NAM:6-1-1 Shooting Pattern
   fails @api-max

The .py modules mentioned shold be changed to have
# @api-max 2015.0
instead of
# @api-max 2014.1

Regards

Stefan Peter

[tmodes (tmodes)]

>The .py modules mentioned shold be changed to have
># @api-max 2015.0
>instead of
># @api-max 2014.1

I know. But it would be nice if someone could test the scripts and report back if there are still running. (I never used them so I can not judge if they are still okay.)

Currently it seems that woa is currently not running, so for woa we can not update the api-max. Only when the issue is fixed we need to update api-min *and* api-max for woa then.

[Stefan Peter (s-peter-deactivatedaccount)]

On 27.04.2015 17:16, tmodes wrote:
>> The .py modules mentioned shold be changed to have
>> # @api-max 2015.0
>> instead of
>> # @api-max 2014.1
>
> I know. But it would be nice if someone could test the scripts and
> report back if there are still running. (I never used them so I can not
> judge if they are still okay.)

I can not judge, either. But api-max was set to 2014.1, so I assume that
these scripts were activated in the development version. I'd expect that
a breakage would have been noticed there.

>
> Currently it seems that woa is currently not running, so for woa we can
> not update the api-max. Only when the issue is fixed we need to update
> api-min *and* api-max for woa then.
>

If this is true, it seems that no one cared during the development cycle
then. Wouldn't it be more honest to axe woa if nobody gives a damn?

Regards

Stefan Peter

--
Any technology that does not appear magical is insufficiently advanced."
~ Gregory Benford

[tduell (tduell-iinet)]

Stefan, thanks for pointing out the problem at comment #2. I had been thinking that the Actions menu would still be added but the python scripts would return errors.

Cheers,
Terry

[Stefan Peter (s-peter-deactivatedaccount)]

Hi Terry

For the records, I have attached the patch I intend to use for the ubuntu packages of 2015.0-beta1. Please note that this patch only enables python scripting for 2015.0.

With kind regards

Stefan Peter

[KFJ (kfj)]

I'd look into the matter but in fact I am getting bored by this problem reappearing every year. Yuv did at the time introduce the 'API check', and ever since it hasn't produced anything useful, but one set of errors every year. When once the API actually did change, the woa plugin simply broke, and the 'API test' did nothing to prevent it. Apart from this one time, any changes to the API that happened never broke the plugins because they only use a small subset of the 'API', which is really just the content of the headers the swig file processes to generate the python interface. So I propose simply throwing out the API test. I suppose I can live with a broken plugin every once in a while, and noone apart from me has ever written another plugin anyway. If noone objects, I'd be glad if someone else could throw out the relevant bit of code, since I don't know where it is and I'd have to search from scratch - alternatively a hint as where to find the code would be appreciated.

Kay

[Stefan Peter (s-peter-deactivatedaccount)]

Hi Kay

I share your frustration regarding the handling of the python scripting interface, However, I feel that you take a too dire look at it: We have released a beta1 and the one of the very _first_ official bug reports brought this issue to the front. So, I conclude that here are people in the hugin community who would dearly miss your python scripts.

 > I suppose I can live with a broken plugin every once in a while, and noone apart from me has ever written another plugin anyway.

Yeah, I would have submitted a script myself if i had found a missing functionality.

Regards

Stefan Peter

[KFJ (kfj)]

Okay, looks like the current state of affairs actually does break the plugins, all of them. Look at this:

run python script: /usr/local/share/hugin/data/plugins/shooting_pattern.py
HPI ERROR: can't find SWIG type for HuginBase::HuginBase::Panorama*
Python interface returned -21

This looks odd: the interface receives a HuginBase::HuginBase::Panorama*, when all it should get is a plain old
HuginBase::Panorama*, which is the type used for class Panorama:

>>> import hsi
>>> p=hsi.Panorama()
>>> p
<hsi.Panorama; proxy of <Swig Object of type 'HuginBase::Panorama *' at 0x7f9ced08ac00> >
>>>

Any ideas anyone? Lookslike some namespace mixup, like the namespace HuginBase accidentally got nested into another namespace of the same name. Hints welcome.

Kay

[Stefan Peter (s-peter-deactivatedaccount)]

Hi Kay

With what binary do you see this? How can I reproduce this?

With kind regards

Stefan Peter

[KFJ (kfj)]

Sorry, I should have been more precise.

The first step is to get the plugins to run again, find attached a patch (done with hg diff) to set the api max to 2015.1.
My next comment will explain how I got the error messages.

[KFJ (kfj)]

So this is my system and hugin:

Betriebssystem: Linux 3.19.2-031902-generic x86_64
Architektur: 64 bit
Free memory: 81608115196 kiB

Hugin
Version: Pre-Release 2015.1.0.6ee10a0fd1cb
Ressourcen-Pfad: /usr/local/share/hugin/xrc/
Datenpfad: /usr/local/share/hugin/data/
Hugins camera and lens database: /home/kfj/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Bibliotheken
wxWidgets: 2.8.12.1
libpano13: 2.9.19
Boost: 1.54.0
Exiv2: 0.23
SQLite3: 3.8.2
Vigra: 1.10.0

To get the first set of error messages I run hugin from the console. If you do so, you can see the error messages as they happen. If you open any PTO and try and run nay plugin on it (the actions menu should be present after having applied the patch or manually updated api max), you should see the errors above (HPI ERROR: can't find SWIG type...)

The stuff with the >>> prompt is from using the python interface from a python command line. Start a python interpreter by entering 'python' on the command line and then enter the commands I quoted above. As you can see the import statement functions without error, so the python interface should be fine. The next command creates a hsi.Panorama object, just using the object's name on the python command line prints it out with some information. Here you see that the interface knows the Panorama type, but it associates it with the C++ type of HuginBase::Panorama *, and not with HuginBase::HuginBase::Panorama*, which it seems to obtain when the plugin is called and fails. I suspect something has gone wrong with the code to invoke the plugin, but so far this is only a guess. I'll try and make time to investigate, but maybe someone has bells ringing when they read this and know straight away what might be wrong. So much for now

Kay

[tmodes (tmodes)]

Very strange. All complain about the script, but nobody than the author is capable to test, if the scripts are running.

Tried to fix in repository. But now I expect that somebody else tests the *4* scripts and reports back, if there are working:
crop_cp.py working|not working
shooting_pattern.py: working|not working
top_five.py: working|not working
woa.py: working|not working
If nobody can test them, then they can removed. Or is this too much expected?

[KFJ (kfj)]

As stated above. All plugins are broken. Lifting api max to 2015 at least makes them run again, but the run results in an error message (error 21), and I described the console output associated with the error on my system in my postings above to find help in analyzing the problem. Since it is a systematic error, there are at least two possibilities: something is wrong on my system (this is why I sent in a description of my build and system) or something is wrong in the software. Testing is easy, once the api min patch is applied (which I provided): Go to the actions menu and click on any of the menu entries. Do you also get the error message 'script returned 21'? OR does it run on your system.

You say: If nobody can test them, then they can removed. Or is this too much expected?

I did test. I described my results. I sent in a patch. I asked for help figuring out the problem. What else would you like me to do?

Kay

[tmodes (tmodes)]

I repeat: "Tried to fix in repository. "

[Stefan Peter (s-peter-deactivatedaccount)]

Hi

As a side not, I am in the progress to revive the nightly builds in
https://launchpad.net/~hugin/+archive/ubuntu/nightly

I hope that this will give a wider exposure of the bleeding edge code to users not being able or not willing to compile from source. I really expect that this will enable us to catch such issues in an earlier stage by opening the development version to a wider audience.

Kay,

I let you know when you can download an ubuntu version of the latest (and greatest) hugin version.

Cheers

Stefan Peter

[KFJ (kfj)]

Okay, I did something else. I hg pulled and upped, rebuilt, and all seems fine now with the latest modifications applied. I can't reproduce the error any more, so I suppose the problem is solved with the api max updates. I noticed the two example plugins are still unmodified; I recommend setting their api max as well, as by my patch. I still propose removing the api min and max check code to prevent this problem from reoccuriung every year. Does anyone feel the api check is really needed?

[KFJ (kfj)]

I should be more precise about the 'example plugins' - I am referring to

src/hugin_script_interface/plugins-dev/dual_use.py

and

src/hugin_script_interface/plugins-dev/plugin_skeleton.py

To T. Modes ' "I repeat: "Tried to fix in repository. ""

I think you fixed it. Yet again. Thanks!

Kay

[Stefan Peter (s-peter-deactivatedaccount)]

Hi Kay
On 29.04.2015 22:08, KFJ wrote:
> Okay, I did something else. I hg pulled and upped, rebuilt, and all
> seems fine now with the latest modifications applied. I can't reproduce
> the error any more, so I suppose the problem is solved with the api max
> updates. I noticed the two example plugins are still unmodified; I
> recommend setting their api max as well, as by my patch.

+1

> I still propose
> removing the api min and max check code to prevent this problem from
> reoccuriung every year. Does anyone feel the api check is really needed?
>

Yes, I do. In the future, the developers may want to be able to change
the API/exposed functionality/whatever of the script interface. Unless
we have a way to determine if a script should be runnable under a
certain hugin version, there is no way to retire a script and replace it
with an adapted heir. This is the stuff support nightmares are made of!

Regards

Stefan Peter

--
Any technology that does not appear magical is insufficiently advanced."
~ Gregory Benford

[tduell (tduell-iinet)]

I have run very minimal tests on crop_cp.py, top_five.py and woa.py on a Fedora 21 build of the current 2015.1.0 source (6907:b87b66fe6645).
These scripts all run, no errors produced here.
I have not tested shooting_pattern.py.

Cheers,
Terry