Re: patch to be applied to default or stable ?

[Ben Abbott]

On Jan 28, 2012, at 11:19 PM, John W. Eaton wrote:

> On 28-Jan-2012, Ben Abbott wrote:
> 
> | I'm able to fix the problem. I've been reverting your reversion below and 
> thought it was a MacOS X only thing.
> | 
> |     
> http://hg.savannah.gnu.org/hgweb/octave/diff/1367f2db49a2/src/graphics.cc
> | 
> | With the sources up to date and reverting this specific changeset, the fltk 
> output works correctly for me.
> | 
> | If you apply the simple change below, does the fltk toolkit work as 
> expected ?
> 
> Unfortunately, no.  It fails for a pair of figures that are generated
> in some horribly complicated way by an example from the MTEX package
> (http://code.google.com/p/mtex).
> 
> If you are really interested, you can try to see the problem by doing
> the following:
> 
> * Download mtex 3.2.2
> 
> * Unpack it and cd to the mtex-3.2.2 directory
> 
> * Edit the file mtex_settings.m and uncomment the line
> 
>     %set_mtex_option('GrainSelector','off')
> 
> * Create symbolic link in c/bin for your architecture.  This
>   directory has some binaries (ick, I know) for systems that run
>   Matlab.  For my system, I needed to do
> 
>     ln -s glnxa64 -> gnu-linux-x86_64
> 
>   in the c/bin directory
> 
> * In the top-level directory, run Octave and type
> 
>     startup_mtex
> 
>     (answer no to the question about installing mtex globally)
> 
>     warning off Octave:missing-glyph
>     more off
>     graphics_toolkit fltk
>     grain_demo
> 
> You should get two plots that look something like the first pair of
> screenshots attached below.  With the current stable sources, this is
> what I see.  With your small patch applied, I get the second set of
> badly sized and blank plots.
> 
> But these plot is generated by so much code spread around in many places
> that I think it will be very hard to debug.
> 
> jwe

Sorry it took me so long to get back to this.

I've installed 3..7.0+ with tip, and *without* the 34720 patch applied.

hangeset:   14358:e7c74f56cd03
tag:         tip
user:        Ben Abbott  <address@hidden>
date:        Sat Feb 11 21:09:03 2012 -0500
summary:     fltk toolkit requires figure units to be "pixels". Bug # 35430.

For the symbolic link I used 

        ln -s maci64 darwin11.3.0-x86_64 

Unfortunately, the mex files do not build for me.

For example.

In file included from /Users/bpabbott/octave/mtex-3.2.2/c/mex/S1Grid.c:1:0,
                 from /Users/bpabbott/octave/mtex-3.2.2/c/mex/S1Grid_find.c:19:
/Users/bpabbott/octave/mtex-3.2.2/c/mex/buffer.c:34:13: error: redefinition of 
typedef 'mwSize'
/opt/local/include/octave-3.7.0+/octave/mxarray.h:88:13: note: previous 
declaration of 'mwSize' was here
/Users/bpabbott/octave/mtex-3.2.2/c/mex/buffer.c:35:13: error: redefinition of 
typedef 'mwIndex'
/opt/local/include/octave-3.7.0+/octave/mxarray.h:89:13: note: previous 
declaration of 'mwIndex' was here

Did you see this ? 

I'm not sure it is a proper fix, but I commented out the offending lines imn 
buffer.c

#if !defined(MWSIZE_MAX)
//typedef       int mwSize;
//typedef       int mwIndex;
//typedef       int mwSignedIndex;
#endif

With those lines commented out 

        startup_mtex
        initializewarning: fopen: file found in load path
        sh: free: command not found
         MTEX 3.2.2  ... done!

The "free" problem is in

        .../mtex-3.2.2/tools/misc_tools/getmem.m

The line is ...

        [r,s] = system('free');

Looks like this shouldn't be a problem, but I thought I'd mention in (just in 
case).

The resulting figure(1) had zero width, but figure(2) looks ok. I checked 
figure(1) for units.  

        get (1, 'units')
        ans = normalized

The fltk backend was only been working correctly for units == pixels. I pushed 
two changesets over the weekend to fix that.

I'm able to grab the edge of figure (1) and lengthen it. The result is the same 
as with your 1st pair.

I have to verity, but the 34720 changeset looks necessary to me. If the (true) 
is not included then neither execute_resizefcn () or update_boundingbox () are 
called. My impression is that this worked for you because the fltk backend 
wasn't updating the figure size when the units changed.

If you run this example with the same tip I used, I expect you'll now see a 
zero width figure (1) as well.

I'll apply the 34720 patch, reinstall, run the example again, and report back 
tomorrow.

Ben