What soup are you drinking? ah, sorry, I'm confused. These guys live
further west on the coast <http://www.asterix.com/> :-)
> And btw: the F3 does not work on OSX as most other Function keys as they are
> reserved by OSX.
bummer! All car manufacturers put the clutch pedal on the left of the
brake pedal and this feels as if
<name_your_favorite_exotic_expensive_luxurious_sports_car> would put it
on the right of the gas pedal.
keep on testing, useful crash reports posted in the bug-tracker. Not an
easy game, but together we'll all get it to the next level - even if
this means filing a bug report for wxWidgets (which I just did):
<http://trac.wxwidgets.org/ticket/9488>
Yuv
yes, please do. they are *very* responsive. I already got a reply on my
report (see below):
For an extra-bonus round, can any of you OSX users who can trigger the
bug please log in at the URL below and add add a comment with the log?
thanks
Yuv
Ticket URL: <http://trac.wxwidgets.org/ticket/9488#comment:1>
#9488: libwx_macu-2.8.0.4.0.dylib - crash on multiple clicks
---------------------+------------------------------------------------------
Reporter: yuv | Owner:
Type: defect | Status: infoneeded_new
Priority: normal | Milestone:
Component: wxMac | Version: 2.8.x
Resolution: | Keywords:
Blockedby: | Patch: 0
Blocking: |
---------------------+------------------------------------------------------
Changes (by wojdyr):
* status: new => infoneeded_new
Comment:
Please report a bug here rather than giving a link.
Try to reproduce the problem in one of the wx samples, because wx
developers may not have time to debug your program.
You may also have a look at:
http://trac.wxwidgets.org/wiki/HowToSubmitTicket
--
Ticket URL: <http://trac.wxwidgets.org/ticket/9488#comment:1>
well, there is an additional reply there! The wxWidgets developers are
very responsive. Now we need OSX users to give them what they need:
feedback!
I guess the situation is the usual one: not many developers have access
to OSX, so they need help. Give it to them, and it will help us too.
<http://trac.wxwidgets.org/ticket/9488#comment:3>
Yuv
They probably want a small piece of code that reproduces the problem. The
hugin code is not easily understandable to an outsider and as a wxWidgets
developer I would also only look at the bug once I have been provided with a
small piece of example code. I expect that due to some differences, list
events are produced in a different way and the functions that update the
list are called in different order than on the other platforms. The whole
dialog probably needs to be rewritten with another approach to avoid the
weired slowness under OSX.
Harry, can you provide a debug build of hugin compiled with -g and linked
against the debug version of wxWidgets?
ciao
Pablo
Harry, can you provide a debug build of hugin compiled with -g and linked
against the debug version of wxWidgets?
ciao
Pablo
-g is a gcc options. Sorry no idea where this can be set in XCode. Also, the
hugin binary should not be stripped (this saves a lot of space, but removes
all function names, so I don't know in which function hugin crashed in the
crashlogs).
wxWidgets can be compiled in a debug configuration (not sure how this is
done on OSX though, if you use the ./configure approach, it should be one of
the configure options). Then in XCode, you need to link against the debug
version of the wxWidgets libraries. (and probably define some more
preprocessor symbols). On my system wx-config returns the following:
pablo@svalbart:~/src/hugin/trunk/build_gutsy_release$ wx-config --debug=yes
--cxxflags
-I/usr/lib/wx/include/gtk2-unicode-debug-2.8 -I/usr/include/wx-2.8
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ -pthread
pablo@svalbart:~/src/hugin/trunk/build_gutsy_release$ wx-config --debug=yes
--libs
-pthread -lwx_gtk2ud_aui-2.8 -lwx_gtk2ud_xrc-2.8 -lwx_gtk2ud_qa-2.8
-lwx_gtk2ud_html-2.8 -lwx_gtk2ud_adv-2.8 -lwx_gtk2ud_core-2.8
-lwx_baseud_xml-2.8 -lwx_baseud_net-2.8 -lwx_baseud-2.8
Probably there is a similar output on OSX, and the XCode project needs to be
changed accordingly.
ciao
Pablo
I just saw that it is possible to tell wxWidgets to avoid using the OSX
native ListControl, which is causing the extreme slowness of the Control
points list window and maybe the multi selection crash.
SVN 3091 uses a generic list control, which might fix both. Further tests
welcome once a binary of SVN 3091 or later is available.
ciao
Pablo
Michael Galloway schrieb:
> crashed for me. comments submitted to tracker.
>
> On Sun, May 25, 2008 at 2:49 AM, Yuv <goo...@levy.ch> wrote:
>
>
> This requires only a few minutes of your time. The only skill required
> is that of clicking away at a target as fast as you can. And the
> result may help advance hugin toward release.
>
> 1. If you don't have it yet installed on your OSX box, grab the latest
> version of hugin from <http://panorama.dyndns.org/download.php?id=218>
>
> 2. Fire it up, load a stitching project or start one.
>
> 3. Make sure you have plenty of control points between multiple
> images, then...
>
> 4. turn on your loudspeakers to an Ennio Morricone's western
> soundtrack <http://en.wikipedia.org/wiki/
> Ennio_Morricone#Leone_film_scores
> <http://en.wikipedia.org/wiki/Ennio_Morricone#Leone_film_scores>>
> and get ready to shoot'em!
>
> 5. Press F3 to display the control points list. Hold the SHIFT key
> down and try to select / deselect as many CPs as fast as you can,
> possibly from many different images. Shoot'em fast!
>
> 6. Should hugin crash, please add your report to
>
> <https://sourceforge.net/tracker/index.php?
> func=detail&aid=1933391&group_id=77506&atid=550441
> <https://sourceforge.net/tracker/index.php?func=detail&aid=1933391&group_id=77506&atid=550441>>
The wrong #elsif statement is already fixed in SVN 3094.
The build of SVN 3092 failed on Win32 too.
> Statements in PTWXdlg.cpp (twice)
> #elsif wxMAJOR_VERSION == 2
> should be
> #elif wxMAJOR_VERSION == 2
>
Guido
hi Axel, not off topic at all, and welcome to hugin! Thank you very much
for your feedback.
Yuv