bugGNU Octave - Bugs: bug #39371, addproperty fails for...

 
 

bug #39371: addproperty fails for "axesunits" type

Submitted by:  Pantxo Diribarne <pantxo>
Submitted on:  Sun 30 Jun 2013 10:24:10 AM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Pantxo Diribarne Open/Closed: Closed
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 08 Oct 2013 10:59:16 PM UTC, comment #10:

The committed patch works for me against the examples in this bug report. Marking it as fixed and closing report.

Rik <rik5>
Project Administrator
Tue 08 Oct 2013 10:42:00 PM UTC, comment #9:

Thanks for following up. I did some simple tests, which all worked.

I made a trivial change to the log and pushed it.

http://hg.savannah.gnu.org/hgweb/octave/rev/07a4597fcbac

Ben Abbott <bpabbott>
Project Member
Tue 08 Oct 2013 10:10:37 PM UTC, comment #8:

First of all this bug happens for any kind of axes property (not only "axesunits")

To clone a particular property <TYPE><PROP> (such as axesunits here), an orphan dummy object of type TYPE is created and stored for further use (see dprop_map).

The first time you call addproperty a new axes is created to clone its "units" property: one of the initialization stages (get_boundingbox) requires retrieving parent figure bounding box, but the axes has no valid parent figure.

The second time, the dummy axes already exists and the error does not occur.

Attached is a patch that "fixes" this issue: if the axes parent is invalid, default_figure_position () is used to compute the axes bounding box.

It happens that only axes objects seams to require informations about their parent but it could be the case for other objects. A more robust way of fixing this maybe to build a proper figure tree (in dprop_map) instead of individual objects.

(file #29332)

Pantxo Diribarne <pantxo>
Project Member
Tue 02 Jul 2013 07:33:00 AM UTC, comment #7:

Ok. That is a different problem. Please file a separate bug report. Be sure to include the example.

Ben Abbott <bpabbott>
Project Member
Tue 02 Jul 2013 06:55:40 AM UTC, comment #6:

Ok, the bug with gnuplot is raised when trying to manipulate the new property. Can you confirm that the following code (ran with gnuplot toolkit) :

... always raises an error, either in dev version or in release (I am on 3.6.3, not 3.6.4)?

Pantxo Diribarne <pantxo>
Project Member
Tue 02 Jul 2013 01:26:21 AM UTC, comment #5:

Pantxo,

I've confirmed the error occurs on my first attempt (with both fltk and gnuplot)

If I use "units" in place of "myunits" with fltk, I also see the same error, but on the second attempt it works.

I see the same behavior with gnuplot.

Ben Abbott <bpabbott>
Project Member
Mon 01 Jul 2013 03:18:24 PM UTC, comment #4:

For me, the first call unconditionally returns an error (by "first" I mean in an octave session). After that, the addproperty behaves as expected (provided you don't use "units" as property name + gnuplot) so that I am not surprised that parsing/argument checking is correct.

Your example also work for me but it's not an option as I am currently implementing Matlab's annotation, which involves a property called units and not myunits :-)

Should I also report the fact that "units" instead of "myunits" leads to an error with gnuplot in a separate bug?

Pantxo Diribarne <pantxo>
Project Member
Mon 01 Jul 2013 12:59:34 PM UTC, comment #3:

hmmm ... I think the problem is that a full update must happen before addproperty(). The following works for me when typed at the command line.

Regarding the second erroneous command, what struck me was that the command was parsed correctly, and a valid error was given.

Ben Abbott <bpabbott>
Project Member
Mon 01 Jul 2013 11:17:01 AM UTC, comment #2:

About the second erroneous command you provided, AFAICS it works as expected: the 4th argument is supposed to be the default value (not the list of allowed values as for radio type), so that the provided string is not supposed to be an allowed value for axesunits property type.

I digged into graphics.in.h to try to find the origin of the error message and found that it may come from a virual member (base_graphics_objct::get_properties (void), line 2843) that inconditionnally returns this error. However there is no reason why this function should be called only once in a session.

Pantxo Diribarne <pantxo>
Project Member
Mon 01 Jul 2013 07:46:28 AM UTC, comment #1:

I can confirm this bug with the developers sources.

As a work around try,

Due to the erroneous command below, I suspect the fix to the sources is trivial.

Ben Abbott <bpabbott>
Project Member
Sun 30 Jun 2013 10:24:10 AM UTC, original submission:

Calling addproperty as followes:

gives inconsistent result.
The first call raises an error, while a second call won't raise any visible error and the new property works fine with set and get.

Additionnal info:
- tested on linux mint 14 (stable 3.6.3 and recent devel version) and on mac os x (fink-3.6.3).
- does not depend on the graphics_toolkit.
- also tried with a line instead of the hggroup and it gave me the same result.
- things are worst if I use "units" as the property name (but this is probably another bug): with gnuplot toolkit trying to manipulate the new property results in errors

Pantxo Diribarne <pantxo>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by pantxo (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 08 Oct 2013 10:59:16 PM UTCrik5StatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Tue 08 Oct 2013 10:42:00 PM UTCbpabbottStatusConfirmed=>Ready For Test
    Tue 08 Oct 2013 10:10:37 PM UTCpantxoAttached File-=>Added fix_invalid_object_39371.diff, #29332
    Mon 01 Jul 2013 07:46:28 AM UTCbpabbottStatusNone=>Confirmed
      Originator Name=>Pantxo Diribarne
      Release3.6.3=>dev

    Back to the top


    Powered by Savane 3.1-cleanup