Re: patch to be applied to default or stable ?

[Ben Abbott]

On Feb 12, 2012, at 9:14 PM, Ben Abbott wrote:

> 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

I made a mistake above. The sources I installed that produced a zero width 
figure (actually 1 pixel wide) had the 34720 patch applied.

Without that being applied, the figures display correctly.  The figure units 
conversion looks to be functioning correctly.

        get (1, 'units')
        ans = normalized
        get (1, 'position')
        ans =

           0.060714   0.059048   0.338095   0.212381

        set (1,'units',  'pixels')
        get (1, 'position')
        ans =

           103    63   568   223

It looks to me as if the 34720 patch should be applied, but that there is 
something else wrong. I'll try to isolate the what the mtex demo does which 
results in the 1 pixel wide plot.

Ben