Issue with hggroup and zlim

[David Bateman]

I'm trying to implement line series objects, and with the current hg
repository I see that

z = [0:0.05:5]; h =  plot3 (z, exp(2i*pi*z));

works fine, but

z = [0:0.05:5]; hold on; hg = hggroup(); h =  plot3 (z,
exp(2i*pi*z),'parent',hg);


doesn't. Note that the "hold on" is need to avoid the hggroup being
cleared. The result is that the zlim is [-0.6,0.6] when it should be
[-1,1]. I took a quick look at graphics.cc and I can't see the reason
for this issue. Perhaps Michael or Shai can. For now I'm just going to
ignore it and go on with the line, etc series implementation.

regards
David


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On 28-Aug-2008, David Bateman wrote:

| I'm trying to implement line series objects, and with the current hg
| repository I see that
|
| z = [0:0.05:5]; h =  plot3 (z, exp(2i*pi*z));
|
| works fine, but
|
| z = [0:0.05:5]; hold on; hg = hggroup(); h =  plot3 (z,
| exp(2i*pi*z),'parent',hg);
|
|
| doesn't. Note that the "hold on" is need to avoid the hggroup being
| cleared. The result is that the zlim is [-0.6,0.6] when it should be
| [-1,1]. I took a quick look at graphics.cc and I can't see the reason
| for this issue. Perhaps Michael or Shai can. For now I'm just going to
| ignore it and go on with the line, etc series implementation.


I'm seeing this odd behavior after starting a fresh Octave session:

  octave:1> z = [0:0.05:5]; hold on; hg = hggroup();
  octave:2> get (hg)
  ans =
  {
    beingdeleted = off
    busyaction = queue
    buttondownfcn = [](0x0)
    children = [](0x0)
    clipping = on
    createfcn = [](0x0)
    deletefcn = [](0x0)
    handlevisibility = on
    hittest = on
    interruptible = on
    parent = -1.2009
    selected = off
    selectionhighlight = on
    tag =
    type = hggroup
    userdata = [](0x0)
    visible = on
    __modified__ = on
    uicontextmenu = [](0x0)
  }

  octave:3> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  error: __go_line__: invalid parent
  error: called from:
  error:   /home/jwe/src/octave/scripts/plot/__line__.m at line 67, column 5
  error:   /home/jwe/src/octave/scripts/plot/line.m at line 41, column 5
  error:   /home/jwe/src/octave/scripts/plot/plot3.m at line 295, column 16
  octave:3> get (hg)
  ans =
  {
    beingdeleted = off
    busyaction = queue
    buttondownfcn = [](0x0)
    children = [](0x0)
    clipping = on
    createfcn = [](0x0)
    deletefcn = [](0x0)
    handlevisibility = on
    hittest = on
    interruptible = on
    parent = -1.2009
    selected = off
    selectionhighlight = on
    tag =
    type = text
    userdata = [](0x0)
    visible = on
    __modified__ = on
    uicontextmenu = [](0x0)
    string =
    units = data
    position =

       0   0   0

    rotation = 0
    horizontalalignment = left
    color =

       0   0   0

    fontname = Helvetica
    fontsize =  10
    fontangle = normal
    fontweight = normal
    interpreter = tex
    backgroundcolor = none
    displayname =
    edgecolor = none
    erasemode = normal
    editing = off
    fontunits = points
    linestyle = -
    linewidth =  0.50000
    margin =  1
    verticalalignment = middle
  }


I don't understand how HG has magically been converted from an hggroup
object to a text object.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

John W. Eaton wrote:
> I'm seeing this odd behavior after starting a fresh Octave session:
>
>  
<snip>
> I don't understand how HG has magically been converted from an hggroup
> object to a text object.
>
>  

Errr, no ideas though I don't think I changed anything that might do
this. Perhaps run octave through valgrind and test again and see if
there are any writes over the end an an array.

D.

--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On 28-Aug-2008, David Bateman wrote:

| John W. Eaton wrote:
| > I'm seeing this odd behavior after starting a fresh Octave session:
| >
| >  
| <snip>
| > I don't understand how HG has magically been converted from an hggroup
| > object to a text object.
| >
| >  
|
| Errr, no ideas though I don't think I changed anything that might do
| this. Perhaps run octave through valgrind and test again and see if
| there are any writes over the end an an array.

OK, I rebuilt from scratch and now I hit this problem:

  octave:2> h =  plot3 (z, exp(2i*pi*z),'parent',hg);

  Invalid call to print_usage.  Correct usage is:

   -- Loadable Function:  print_usage ()


  Additional help for built-in functions and operators is
  available in the on-line version of the manual.  Use the command
  `doc <topic>' to search the manual index.

  Help and information about Octave is also available on the WWW
  at http://www.octave.org and via the help@...
  mailing list.

  error: called from:
  error:   /home/jwe/src/octave/scripts/plot/__line__.m at line 51, column 5
  error:   /home/jwe/src/octave/scripts/plot/line.m at line 41, column 5
  error:   /home/jwe/src/octave/scripts/plot/plot3.m at line 305, column 11

This error happens at this point in __line__.m:

  if (rem (nvargs - num_data_args, 2) == 0)
  else
    print_usage ("line");
  endif

First, there's clearly a problem since we expect to be able to call
print_usage with a function name and that no longer works.  I'm not
sure of the best fix here, but since this is an internal function, I
don't think it matters much as we should probably never call it
incorrectly.  So I'd probably say we should change the above to

  if (rem (nvargs - num_data_args, 2) != 0)
    print_usage ();
  endif

But, why don't we have an even number of arguments?

The last elements of varargin at this point are:

  [1,12] = parent
  [1,13] = -2.6959
  [1,14] = parent

so somehow the parent property tag is being added twice, and the
second time without the corresponding value.  Looking at the way
line is called at line 305 of plot3.m, I see

      properties = __add_datasource__ ("plot3", hg, {"x", "y", "z"}, properties{:});

      hline = line (x(:), y(:), z(:),  "keylabel", key, "color", color,
                    "linestyle", options.linestyle,
                    "marker", options.marker, "parent", hg, properties{:});

      __add_line_series__ (h, hg);

Before the call to __add_datasource__, properties has the value:

  properties =

  {
    [1,1] = parent
    [1,2] = -2.6959
  }

After the call, it is:

  properties =

  {
    [1,1] = parent
  }

Looking at __add_datasource__.m, I see

  i = 1;
  newargs = {};
  while (i < numel (varargin))
    arg = varargin{i++};
    if (ischar (arg) && length (arg > 1) && strcmpi (arg(2:end), "datasource"))
      arg = tolower (arg);
      val = varargin{i++};
      if (ischar (val))
        set (h, arg, val);
      else
        error ("%s: expecting data source to be a string", fcn);
      endif
    else
      newargs{end + 1} = arg;
    endif
  endwhile

Should the test in this loop be <= instead of < ?  If so, then newargs
will contain the parent argument and the calls to __line__ in plot3
will need to be modified.  For example, I would propose this change:

diff --git a/scripts/plot/__add_datasource__.m b/scripts/plot/__add_datasource__.m
--- a/scripts/plot/__add_datasource__.m
+++ b/scripts/plot/__add_datasource__.m
@@ -34,7 +34,7 @@
 
   i = 1;
   newargs = {};
-  while (i < numel (varargin))
+  while (i <= numel (varargin))
     arg = varargin{i++};
     if (ischar (arg) && length (arg > 1) && strcmpi (arg(2:end), "datasource"))
       arg = tolower (arg);
diff --git a/scripts/plot/plot3.m b/scripts/plot/plot3.m
--- a/scripts/plot/plot3.m
+++ b/scripts/plot/plot3.m
@@ -231,7 +231,7 @@
 
       hline = line (x(:), y(:), z(:),  "keylabel", key, "color", color,
     "linestyle", options.linestyle,
-    "marker", options.marker, "parent", hg, properties{:});
+    "marker", options.marker, properties{:});
 
       __add_line_series__ (h, hg);
 
@@ -301,7 +301,7 @@
 
     hline = line (x(:), y(:), z(:),  "keylabel", key, "color", color,
   "linestyle", options.linestyle,
-  "marker", options.marker, "parent", hg, properties{:});
+  "marker", options.marker, properties{:});
 
     __add_line_series__ (h, hg);
   endif

Or is there some other fix that is better?

Finally, if I make this change, I see the following error:

  octave:1> z = [0:0.05:5]; hold on; hg = hggroup();
  octave:2> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  error: `h' undefined near line 309 column 26
  error: evaluating argument list element number 1
  error: called from:
  error:   /home/jwe/src/octave/scripts/plot/plot3.m at line 309, column 5

This is happening at the line

    __add_line_series__ (h, hg);

Should that be hline instead of h?  There are two cases like this in
plot3.  I'm not sure of the intent here.

If I make that change, then I see

  octave:1> z = [0:0.05:5]; hold on; hg = hggroup();
  octave:2> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  octave:3> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  error: __go_line__: invalid parent
  error: called from:
  error:   /home/jwe/src/octave/scripts/plot/__line__.m at line 67, column 5
  error:   /home/jwe/src/octave/scripts/plot/line.m at line 41, column 5
  error:   /home/jwe/src/octave/scripts/plot/plot3.m at line 305, column 11

so the first call works, but the second fails.  I'm lost at this point.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[dbateman]

John W. Eaton wrote:

Looking at __add_datasource__.m, I see

  i = 1;
  newargs = {};
  while (i < numel (varargin))
    arg = varargin{i++};
    if (ischar (arg) && length (arg > 1) && strcmpi (arg(2:end), "datasource"))
      arg = tolower (arg);
      val = varargin{i++};
      if (ischar (val))
        set (h, arg, val);
      else
        error ("%s: expecting data source to be a string", fcn);
      endif
    else
      newargs{end + 1} = arg;
    endif
  endwhile

Should the test in this loop be <= instead of < ?  If so, then newargs
will contain the parent argument and the calls to __line__ in plot3
will need to be modified.  For example, I would propose this change:

No as property/value occur in pairs. However varargin{i++} should read varargin{++i} or i should be initialized to 0. As for the change in plot3.m this is incorrect as the explicit reparenting to the hggroup is needed. Your second reparenting will just override that.

D.

[John W. Eaton]

On 28-Aug-2008, dbateman wrote:

| John W. Eaton wrote:
| >
| > Looking at __add_datasource__.m, I see
| >
| >   i = 1;
| >   newargs = {};
| >   while (i < numel (varargin))
| >     arg = varargin{i++};
| >     if (ischar (arg) && length (arg > 1) && strcmpi (arg(2:end),
| > "datasource"))
| >       arg = tolower (arg);
| >       val = varargin{i++};
| >       if (ischar (val))
| > set (h, arg, val);
| >       else
| > error ("%s: expecting data source to be a string", fcn);
| >       endif
| >     else
| >       newargs{end + 1} = arg;
| >     endif
| >   endwhile
| >
| > Should the test in this loop be <= instead of < ?  If so, then newargs
| > will contain the parent argument and the calls to __line__ in plot3
| > will need to be modified.  For example, I would propose this change:
| >
|
| No as property/value occur in pairs.

I'm confused.  Does __add_datasource__ require that varargin is a list
of property value pairs?  If yes, then why not write the loop as

  for i = 1:2:numel (varargin)
    key = varargin{i};
    val = varargin{i+1}
    if (length (key > 1) && strcmpi (key(2:end), "datasource"))
      if (ischar (val))
        set (h, key, val);
      else
        error ("%s: expecting data source to be a string", fcn);
      endif
    else
      newargs(end+1:end+2) = {key, val};
    endif
  endwhile
   
?

| However varargin{i++} should read
| varargin{++i} or i should be initialized to 0.

I don't see how that can be "or".  Do you mean "and", and that i++
should be switched to ++i in both cases?

| As for the change in plot3.m
| this is incorrect as the explicit reparenting to the hggroup is needed. Your
| second reparenting will just override that.

OK.

What about the call to __add_line_series__?  Should the first argument
be hline instead of h?

If I make the attached changes, I see this:

  octave:1> z = [0:0.05:5]; hold on; hg = hggroup();
  octave:2> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  octave:3> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  Segmentation fault

so the first call works, but the second fails.  It appears to be an
infinite recursion:

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0x7ff7097956f0 (LWP 6479)]
  0x00007ff7089ef780 in std::_Rb_tree<graphics_handle, std::pair<graphics_handle const, graphics_object>, std::_Select1st<std::pair<graphics_handle const, graphics_object> >, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::_M_lower_bound (this=Cannot access memory at address 0x7fff1115fff8
  )
      at /usr/include/c++/4.3/bits/stl_tree.h:954
  954   const _Key& __k)
  Current language:  auto; currently c++
  (gdb) where
  #0  0x00007ff7089ef780 in std::_Rb_tree<graphics_handle, std::pair<graphics_handle const, graphics_object>, std::_Select1st<std::pair<graphics_handle const, graphics_object> >, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::_M_lower_bound (this=Cannot access memory at address 0x7fff1115fff8
  )
      at /usr/include/c++/4.3/bits/stl_tree.h:954
  #1  0x00007ff7089ef829 in std::_Rb_tree<graphics_handle, std::pair<graphics_handle const, graphics_object>, std::_Select1st<std::pair<graphics_handle const, graphics_object> >, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::find (this=0x11361a0, __k=@0x7fff11160150)
      at /usr/include/c++/4.3/bits/stl_tree.h:1392
  #2  0x00007ff7089ef8a7 in std::map<graphics_handle, graphics_object, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::find (this=0x11361a0, __x=@0x7fff11160150)
      at /usr/include/c++/4.3/bits/stl_map.h:615
  #3  0x00007ff7089f0474 in gh_manager::do_get_object (this=0x11361a0,
      h=@0x7fff11160150) at ./graphics.h:8751
  #4  0x00007ff7089f0510 in gh_manager::get_object (h=@0x7fff11160150)
      at ./graphics.h:8575
  #5  0x00007ff708a6b78b in base_properties::get_backend (this=0x1aad7c0)
      at /home/jwe/src/octave/src/graphics.cc:1712
  #6  0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
      at ./graphics.h:2138
  #7  0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff111601f0)
      at ./graphics.h:2303
  #8  0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
      at /home/jwe/src/octave/src/graphics.cc:1715
  #9  0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
      at ./graphics.h:2138
  #10 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff111602a0)
      at ./graphics.h:2303
  #11 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
      at /home/jwe/src/octave/src/graphics.cc:1715
  #12 0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
      at ./graphics.h:2138
  #13 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff11160350)
      at ./graphics.h:2303
  #14 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
      at /home/jwe/src/octave/src/graphics.cc:1715
  #15 0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
      at ./graphics.h:2138
  #16 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff11160400)
      at ./graphics.h:2303
  #17 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
      at /home/jwe/src/octave/src/graphics.cc:1715
  #18 0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
      at ./graphics.h:2138
  #19 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff111604b0)
      at ./graphics.h:2303
  #20 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
      at /home/jwe/src/octave/src/graphics.cc:1715
  #21 0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
      at ./graphics.h:2138
  #22 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff11160560)
      at ./graphics.h:2303
  #23 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
      at /home/jwe/src/octave/src/graphics.cc:1715

I have no clues at this point.

jwe


diff --git a/scripts/plot/__add_datasource__.m b/scripts/plot/__add_datasource__.m
--- a/scripts/plot/__add_datasource__.m
+++ b/scripts/plot/__add_datasource__.m
@@ -32,20 +32,20 @@
     addproperty (strcat (data{i}, "datasource"), h, "string", "");
   endfor
 
-  i = 1;
   newargs = {};
-  while (i < numel (varargin))
-    arg = varargin{i++};
-    if (ischar (arg) && length (arg > 1) && strcmpi (arg(2:end), "datasource"))
-      arg = tolower (arg);
-      val = varargin{i++};
+
+  for i = 1:2:numel (varargin)
+    key = varargin{i};
+    val = varargin{i+1};
+    if (length (key > 1) && strcmpi (key(2:end), "datasource"))
       if (ischar (val))
- set (h, arg, val);
+        set (h, key, val);
       else
- error ("%s: expecting data source to be a string", fcn);
+        error ("%s: expecting data source to be a string", fcn);
       endif
     else
-      newargs{end + 1} = arg;
+      newargs(end+1:end+2) = {key, val};
     endif
-  endwhile
+  endfor
+
 endfunction
diff --git a/scripts/plot/plot3.m b/scripts/plot/plot3.m
--- a/scripts/plot/plot3.m
+++ b/scripts/plot/plot3.m
@@ -233,7 +233,7 @@
     "linestyle", options.linestyle,
     "marker", options.marker, "parent", hg, properties{:});
 
-      __add_line_series__ (h, hg);
+      __add_line_series__ (hline, hg);
 
       x = new;
       y_set = 0;
@@ -303,7 +303,7 @@
   "linestyle", options.linestyle,
   "marker", options.marker, "parent", hg, properties{:});
 
-    __add_line_series__ (h, hg);
+    __add_line_series__ (hline, hg);
   endif
 
   set (gca (), "view", [-37.5, 30]);

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

The only I see for this infinite recursion to occur is that an object
has himself as parent. The method base_properties::get_backend
should probably be made robust against such simple problem.

Michael.


On Thu, Aug 28, 2008 at 8:58 PM, John W. Eaton <jwe@...> wrote:

> so the first call works, but the second fails.  It appears to be an
> infinite recursion:
>
>  Program received signal SIGSEGV, Segmentation fault.
>  [Switching to Thread 0x7ff7097956f0 (LWP 6479)]
>  0x00007ff7089ef780 in std::_Rb_tree<graphics_handle, std::pair<graphics_handle const, graphics_object>, std::_Select1st<std::pair<graphics_handle const, graphics_object> >, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::_M_lower_bound (this=Cannot access memory at address 0x7fff1115fff8
>  )
>      at /usr/include/c++/4.3/bits/stl_tree.h:954
>  954                      const _Key& __k)
>  Current language:  auto; currently c++
>  (gdb) where
>  #0  0x00007ff7089ef780 in std::_Rb_tree<graphics_handle, std::pair<graphics_handle const, graphics_object>, std::_Select1st<std::pair<graphics_handle const, graphics_object> >, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::_M_lower_bound (this=Cannot access memory at address 0x7fff1115fff8
>  )
>      at /usr/include/c++/4.3/bits/stl_tree.h:954
>  #1  0x00007ff7089ef829 in std::_Rb_tree<graphics_handle, std::pair<graphics_handle const, graphics_object>, std::_Select1st<std::pair<graphics_handle const, graphics_object> >, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::find (this=0x11361a0, __k=@0x7fff11160150)
>      at /usr/include/c++/4.3/bits/stl_tree.h:1392
>  #2  0x00007ff7089ef8a7 in std::map<graphics_handle, graphics_object, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::find (this=0x11361a0, __x=@0x7fff11160150)
>      at /usr/include/c++/4.3/bits/stl_map.h:615
>  #3  0x00007ff7089f0474 in gh_manager::do_get_object (this=0x11361a0,
>      h=@0x7fff11160150) at ./graphics.h:8751
>  #4  0x00007ff7089f0510 in gh_manager::get_object (h=@0x7fff11160150)
>      at ./graphics.h:8575
>  #5  0x00007ff708a6b78b in base_properties::get_backend (this=0x1aad7c0)
>      at /home/jwe/src/octave/src/graphics.cc:1712
>  #6  0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
>      at ./graphics.h:2138
>  #7  0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff111601f0)
>      at ./graphics.h:2303
>  #8  0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
>      at /home/jwe/src/octave/src/graphics.cc:1715
>  #9  0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
>      at ./graphics.h:2138
>  #10 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff111602a0)
>      at ./graphics.h:2303
>  #11 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
>      at /home/jwe/src/octave/src/graphics.cc:1715
>  #12 0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
>      at ./graphics.h:2138
>  #13 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff11160350)
>      at ./graphics.h:2303
>  #14 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
>      at /home/jwe/src/octave/src/graphics.cc:1715
>  #15 0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
>      at ./graphics.h:2138
>  #16 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff11160400)
>      at ./graphics.h:2303
>  #17 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
>      at /home/jwe/src/octave/src/graphics.cc:1715
>  #18 0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
>      at ./graphics.h:2138
>  #19 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff111604b0)
>      at ./graphics.h:2303
>  #20 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
>      at /home/jwe/src/octave/src/graphics.cc:1715
>  #21 0x00007ff708b25329 in base_graphics_object::get_backend (this=0x1aad7b0)
>      at ./graphics.h:2138
>  #22 0x00007ff708b02509 in graphics_object::get_backend (this=0x7fff11160560)
>      at ./graphics.h:2303
>  #23 0x00007ff708a6b7d9 in base_properties::get_backend (this=0x1aad7c0)
>      at /home/jwe/src/octave/src/graphics.cc:1715
>
> I have no clues at this point.
>
> jwe
>
>
> diff --git a/scripts/plot/__add_datasource__.m b/scripts/plot/__add_datasource__.m
> --- a/scripts/plot/__add_datasource__.m
> +++ b/scripts/plot/__add_datasource__.m
> @@ -32,20 +32,20 @@
>     addproperty (strcat (data{i}, "datasource"), h, "string", "");
>   endfor
>
> -  i = 1;
>   newargs = {};
> -  while (i < numel (varargin))
> -    arg = varargin{i++};
> -    if (ischar (arg) && length (arg > 1) && strcmpi (arg(2:end), "datasource"))
> -      arg = tolower (arg);
> -      val = varargin{i++};
> +
> +  for i = 1:2:numel (varargin)
> +    key = varargin{i};
> +    val = varargin{i+1};
> +    if (length (key > 1) && strcmpi (key(2:end), "datasource"))
>       if (ischar (val))
> -       set (h, arg, val);
> +        set (h, key, val);
>       else
> -       error ("%s: expecting data source to be a string", fcn);
> +        error ("%s: expecting data source to be a string", fcn);
>       endif
>     else
> -      newargs{end + 1} = arg;
> +      newargs(end+1:end+2) = {key, val};
>     endif
> -  endwhile
> +  endfor
> +
>  endfunction
> diff --git a/scripts/plot/plot3.m b/scripts/plot/plot3.m
> --- a/scripts/plot/plot3.m
> +++ b/scripts/plot/plot3.m
> @@ -233,7 +233,7 @@
>                    "linestyle", options.linestyle,
>                    "marker", options.marker, "parent", hg, properties{:});
>
> -      __add_line_series__ (h, hg);
> +      __add_line_series__ (hline, hg);
>
>       x = new;
>       y_set = 0;
> @@ -303,7 +303,7 @@
>                  "linestyle", options.linestyle,
>                  "marker", options.marker, "parent", hg, properties{:});
>
> -    __add_line_series__ (h, hg);
> +    __add_line_series__ (hline, hg);
>   endif
>
>   set (gca (), "view", [-37.5, 30]);
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave@...
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>
>

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[dbateman]

John W. Eaton wrote:

I'm confused.  Does __add_datasource__ require that varargin is a list
of property value pairs?  If yes, then why not write the loop as

  for i = 1:2:numel (varargin)
    key = varargin{i};
    val = varargin{i+1}
    if (length (key > 1) && strcmpi (key(2:end), "datasource"))
      if (ischar (val))
        set (h, key, val);
      else
        error ("%s: expecting data source to be a string", fcn);
      endif
    else
      newargs(end+1:end+2) = {key, val};
    endif
  endwhile
   
?

It extracts prop/val pairs with the prop ending in "datasource". However, the args that are returned don't have to be prop/val pairs.

| However varargin{i++} should read
| varargin{++i} or i should be initialized to 0.

I don't see how that can be "or".  Do you mean "and", and that i++
should be switched to ++i in both cases?

If i=0 initially then varargin {i++} and > will work. Otherwise i=1 initially and varargin{++i} with the loop test changed to by -1 will work.

| As for the change in plot3.m
| this is incorrect as the explicit reparenting to the hggroup is needed. Your
| second reparenting will just override that.

OK.

What about the call to __add_line_series__?  Should the first argument
be hline instead of h?

If I make the attached changes, I see this:

  octave:1> z = [0:0.05:5]; hold on; hg = hggroup();
  octave:2> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  octave:3> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  Segmentation fault

so the first call works, but the second fails.  It appears to be an
infinite recursion:

Can't test now, as I'm not on my development. I'll look tomorrow and propose something.

D.

[David Bateman]

John W. Eaton wrote:

> On 28-Aug-2008, dbateman wrote:
>
> | John W. Eaton wrote:
> | >
> | > Looking at __add_datasource__.m, I see
> | >
> | >   i = 1;
> | >   newargs = {};
> | >   while (i < numel (varargin))
> | >     arg = varargin{i++};
> | >     if (ischar (arg) && length (arg > 1) && strcmpi (arg(2:end),
> | > "datasource"))
> | >       arg = tolower (arg);
> | >       val = varargin{i++};
> | >       if (ischar (val))
> | > set (h, arg, val);
> | >       else
> | > error ("%s: expecting data source to be a string", fcn);
> | >       endif
> | >     else
> | >       newargs{end + 1} = arg;
> | >     endif
> | >   endwhile
> | >
> | > Should the test in this loop be <= instead of < ?  If so, then newargs
> | > will contain the parent argument and the calls to __line__ in plot3
> | > will need to be modified.  For example, I would propose this change:
> | >
> |
> | No as property/value occur in pairs.
>
> I'm confused.  Does __add_datasource__ require that varargin is a list
> of property value pairs?  If yes, then why not write the loop as
>
>   for i = 1:2:numel (varargin)
>     key = varargin{i};
>     val = varargin{i+1}
>     if (length (key > 1) && strcmpi (key(2:end), "datasource"))
>       if (ischar (val))
>         set (h, key, val);
>       else
>         error ("%s: expecting data source to be a string", fcn);
>       endif
>     else
>       newargs(end+1:end+2) = {key, val};
>     endif
>   endwhile
>    
> ?
>
> | However varargin{i++} should read
> | varargin{++i} or i should be initialized to 0.
>
> I don't see how that can be "or".  Do you mean "and", and that i++
> should be switched to ++i in both cases?
>
> | As for the change in plot3.m
> | this is incorrect as the explicit reparenting to the hggroup is needed. Your
> | second reparenting will just override that.
>
> OK.
>
> What about the call to __add_line_series__?  Should the first argument
> be hline instead of h?
>
>  

I'd suggest the attached changeset instead.. And yes it should be hline

and not h in plot3.

D.

--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


# HG changeset patch
# User David Bateman <dbateman@...>
# Date 1220006139 -7200
# Node ID bc6ec8356a900e3c23d3e237d3ab1059138add53
# Parent  5b66c24bd777029cf242b0d54fa32feefbbd8fc6
Small fix to plot3 and data sources code

diff --git a/scripts/plot/__add_datasource__.m b/scripts/plot/__add_datasource__.m
--- a/scripts/plot/__add_datasource__.m
+++ b/scripts/plot/__add_datasource__.m
@@ -32,13 +32,14 @@ function newargs = __add_datasource__ (f
     addproperty (strcat (data{i}, "datasource"), h, "string", "");
   endfor
 
-  i = 1;
+  i = 0;
   newargs = {};
   while (i < numel (varargin))
-    arg = varargin{i++};
-    if (ischar (arg) && length (arg > 1) && strcmpi (arg(2:end), "datasource"))
+    arg = varargin{++i};
+    if (i != numel(varargin) && ischar (arg) &&
+ length (arg > 1) && strcmpi (arg(2:end), "datasource"))
       arg = tolower (arg);
-      val = varargin{i++};
+      val = varargin{++i};
       if (ischar (val))
  set (h, arg, val);
       else
diff --git a/scripts/plot/plot3.m b/scripts/plot/plot3.m
--- a/scripts/plot/plot3.m
+++ b/scripts/plot/plot3.m
@@ -303,7 +303,7 @@ function retval = plot3 (varargin)
   "linestyle", options.linestyle,
   "marker", options.marker, "parent", hg, properties{:});
 
-    __add_line_series__ (h, hg);
+    __add_line_series__ (hline, hg);
   endif
 
   set (gca (), "view", [-37.5, 30]);

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On 29-Aug-2008, David Bateman wrote:

| I'd suggest the attached changeset instead.. And yes it should be hline
| and not h in plot3.

OK, after applying this patch, I'm still seeing

  octave:1> z = [0:0.05:5]; hold on; hg = hggroup();
  octave:2> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  octave:3> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
  Segmentation fault

The first call makes the correct plot, but then it fails.  The gdb
output is the same as I posted before, indicating infinite recursion
in base_properties::get_backend and base_graphics_object::get_backend:

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0x7f3e1d2966f0 (LWP 19465)]
  0x00007f3e1c4ef0fe in operator< (a=@0x108ff40, b=@0x7fff24c611d0)
      at ./graphics.h:165
  165  return a.value () < b.value ();
  Current language:  auto; currently c++
  (gdb) where
  #0  0x00007f3e1c4ef0fe in operator< (a=@0x108ff40, b=@0x7fff24c611d0)
      at ./graphics.h:165
  #1  0x00007f3e1c4f0401 in std::less<graphics_handle>::operator() (
      this=0xe1d070, __x=@0x108ff40, __y=@0x7fff24c611d0)
      at /usr/include/c++/4.3/bits/stl_function.h:230
  #2  0x00007f3e1c4f07ab in std::_Rb_tree<graphics_handle, std::pair<graphics_handle const, graphics_object>, std::_Select1st<std::pair<graphics_handle const, graphics_object> >, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::_M_lower_bound (this=0xe1d070,
      __x=0x108ff20, __y=0xe1d078, __k=@0x7fff24c611d0)
      at /usr/include/c++/4.3/bits/stl_tree.h:957
  #3  0x00007f3e1c4f0829 in std::_Rb_tree<graphics_handle, std::pair<graphics_handle const, graphics_object>, std::_Select1st<std::pair<graphics_handle const, graphics_object> >, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::find (this=0xe1d070, __k=@0x7fff24c611d0)
      at /usr/include/c++/4.3/bits/stl_tree.h:1392
  #4  0x00007f3e1c4f08a7 in std::map<graphics_handle, graphics_object, std::less<graphics_handle>, std::allocator<std::pair<graphics_handle const, graphics_object> > >::find (this=0xe1d070, __x=@0x7fff24c611d0)
      at /usr/include/c++/4.3/bits/stl_map.h:615
  #5  0x00007f3e1c4f1474 in gh_manager::do_get_object (this=0xe1d070,
      h=@0x7fff24c611d0) at ./graphics.h:8751
  #6  0x00007f3e1c4f1510 in gh_manager::get_object (h=@0x7fff24c611d0)
      at ./graphics.h:8575
  #7  0x00007f3e1c56c78b in base_properties::get_backend (this=0x13a11e0)
      at /home/jwe/src/octave/src/graphics.cc:1712
  #8  0x00007f3e1c626329 in base_graphics_object::get_backend (this=0x13a11d0)
      at ./graphics.h:2138
  #9  0x00007f3e1c603509 in graphics_object::get_backend (this=0x7fff24c61270)
      at ./graphics.h:2303
  #10 0x00007f3e1c56c7d9 in base_properties::get_backend (this=0x13a11e0)
      at /home/jwe/src/octave/src/graphics.cc:1715
  #11 0x00007f3e1c626329 in base_graphics_object::get_backend (this=0x13a11d0)
      at ./graphics.h:2138
  #12 0x00007f3e1c603509 in graphics_object::get_backend (this=0x7fff24c61320)
      at ./graphics.h:2303
  #13 0x00007f3e1c56c7d9 in base_properties::get_backend (this=0x13a11e0)
      at /home/jwe/src/octave/src/graphics.cc:1715
  #14 0x00007f3e1c626329 in base_graphics_object::get_backend (this=0x13a11d0)
      at ./graphics.h:2138
  #15 0x00007f3e1c603509 in graphics_object::get_backend (this=0x7fff24c613d0)
      at ./graphics.h:2303
  #16 0x00007f3e1c56c7d9 in base_properties::get_backend (this=0x13a11e0)
      at /home/jwe/src/octave/src/graphics.cc:1715
  #17 0x00007f3e1c626329 in base_graphics_object::get_backend (this=0x13a11d0)
      at ./graphics.h:2138
  ...

I'm guessing it works for you?

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

John W. Eaton wrote:

> On 29-Aug-2008, David Bateman wrote:
>
> | I'd suggest the attached changeset instead.. And yes it should be hline
> | and not h in plot3.
>
> OK, after applying this patch, I'm still seeing
>
>   octave:1> z = [0:0.05:5]; hold on; hg = hggroup();
>   octave:2> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
>   octave:3> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
>   Segmentation fault
>
> The first call makes the correct plot, but then it fails.  The gdb
> output is the same as I posted before, indicating infinite recursion
> in base_properties::get_backend and base_graphics_object::get_backend:
>
>
>  

<snip>
> I'm guessing it works for you?
>
>  
No its not, but I'm working on a patch. MMichael's assumption is right
that the object is the paren of itself.

D.


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

John W. Eaton wrote:

> On 29-Aug-2008, David Bateman wrote:
>
> | I'd suggest the attached changeset instead.. And yes it should be hline
> | and not h in plot3.
>
> OK, after applying this patch, I'm still seeing
>
>   octave:1> z = [0:0.05:5]; hold on; hg = hggroup();
>   octave:2> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
>   octave:3> h =  plot3 (z, exp(2i*pi*z),'parent',hg);
>   Segmentation fault
>  

The reason for the object being its own parent can be seen with the example


octave:1> hold on; hg1 = hggroup(), newplot (); hg2 = hggroup ()
hg1 = -2.3944
hg2 = -2.3944

Clearly hg1 and hg2 should be different as the hold is on and the
newplot should add objects to the current axes.

octave:1> hold on
octave:2> get(gcf(),"nextplot")
ans = add
octave:3> get(gca(),"nextplot")
ans = replace
octave:4> hold off
octave:5> get(gcf(),"nextplot")
ans = replace
octave:6> get(gca(),"nextplot")
ans = replace

The problem is that "hold on" with no figures existing should create the
currentaxes for the new figure. I have a few other problems I'd like to
fix, so I'll sent changeset soon with all my fixes.

D.



--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

Here is the promised patch

D.


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


# HG changeset patch
# User David Bateman <dbateman@...>
# Date 1220023682 -7200
# Node ID 72001c164be743e0ad344bc4583243ca0bcd7f3c
# Parent  bc6ec8356a900e3c23d3e237d3ab1059138add53
Fix for hold with no figures/axes. Set prop/val pairs to hggroups rather than underlying objects. Fix for equality test in array_property

diff --git a/scripts/ChangeLog b/scripts/ChangeLog
--- a/scripts/ChangeLog
+++ b/scripts/ChangeLog
@@ -1,3 +1,18 @@ 2008-08-28  David Bateman  <dbateman@fre
[phone]  David Bateman  <dbateman@...>
+
+ * plot/__plt2mm__.m, plot/__plt2mv__.m, plot/__plt2ss__.m,
+ plot/__plt2sv__.m, plot/__plt2vm__.m, plot/__plt2vs__.m,
+ plot/__plt2vv__.m, plot/plot3.m, plot/__area__.m, plot/__bars__.m,
+ plot/__quiver__.m, plot/__stem__.m, plot/stairs.m :
+ Pass additional prop/val pairs to hggroup rather than underlying
+ objects. If a baseline existings specifically associate it with
+ the parent of the created hggroup to allow things like "stem(...,
+ 'parent', hg)" to work correctly.
+ * plot/hold.m: If currentaxes if figure doesn't exist, create it.
+
+ * plot/plot3.m: Pass hline to __add_line_series__.
+ * plot/__add_datasource__.m: Fix off by one error.
+
 2008-08-28  David Bateman  <dbateman@...>
 
  * plot/__add_line_series__.m, plot/ishghandle.m, plot/linkprop.m,
diff --git a/scripts/plot/__area__.m b/scripts/plot/__area__.m
--- a/scripts/plot/__area__.m
+++ b/scripts/plot/__area__.m
@@ -38,11 +38,11 @@ function retval = __area__ (ax, x, y, bv
 
     if (i == 1)
       h = patch (ax, [x1(1), x1, fliplr(x1)], [bv, y1, bv*ones(1, length(y1))],
- __next_line_color__ (), "parent", hg, args{:});
+ __next_line_color__ (), "parent", hg);
     else
       y1 = y0 + y1;
       h = patch (ax, [x1(1), x1, fliplr(x1)], [y0(1), y1, fliplr(y0)],
- __next_line_color__ (), "parent", hg, args{:});
+ __next_line_color__ (), "parent", hg);
     endif
 
     y0 = y1;
@@ -62,6 +62,8 @@ function retval = __area__ (ax, x, y, bv
 
     addproperty ("areagroup", hg, "data");
     set (retval, "areagroup", retval);
+
+    set (hg, args{:});
   endfor
 
 endfunction
diff --git a/scripts/plot/__bars__.m b/scripts/plot/__bars__.m
--- a/scripts/plot/__bars__.m
+++ b/scripts/plot/__bars__.m
@@ -39,9 +39,9 @@ function tmp = __bars__ (ax, vertical, x
   lev = (i - 1) * (clim(2) - clim(1)) / (ycols - 1) - clim(1);
  endif
  h = patch(xb(:,:,i), yb(:,:,i), "FaceColor", "flat",
-  "cdata", lev, "parent", hg, args{:});
+  "cdata", lev, "parent", hg);
       else
- h = patch(xb(:,:,i), yb(:,:,i), "parent", hg, args{:});
+ h = patch(xb(:,:,i), yb(:,:,i), "parent", hg);
       endif
     else
       if (! have_color_spec)
@@ -51,9 +51,9 @@ function tmp = __bars__ (ax, vertical, x
   lev = (i - 1) * (clim(2) - clim(1)) / (ycols - 1) - clim(1);
  endif
  h = patch(yb(:,:,i), xb(:,:,i), "FaceColor", "flat",
-  "cdata", lev, "parent", hg, args{:});
+  "cdata", lev, "parent", hg);
       else
- h = patch(yb(:,:,i), xb(:,:,i), "parent", hg, args{:});
+ h = patch(yb(:,:,i), xb(:,:,i), "parent", hg);
       endif
     endif
 
@@ -113,6 +113,10 @@ function tmp = __bars__ (ax, vertical, x
 
     addproperty ("bargroup", hg, "data");
     set (tmp, "bargroup", tmp);
+    set (hg, args{:});
+    if (i == 1)
+      set (h_baseline, "parent", get (hg, "parent"));
+    endif
   endfor
 
   update_xlim (ax, []);
diff --git a/scripts/plot/__plt2mm__.m b/scripts/plot/__plt2mm__.m
--- a/scripts/plot/__plt2mm__.m
+++ b/scripts/plot/__plt2mm__.m
@@ -62,9 +62,10 @@ function retval = __plt2mm__ (h, x, y, o
 
  h = line (x(:,i), y(:,i), "keylabel", tkey, "color", color,
   "linestyle", options(i).linestyle,
-  "marker", options(i).marker, "parent", hg, args{:});
+  "marker", options(i).marker, "parent", hg);
 
  __add_line_series__ (h, hg);
+ set (hg, args {:});
       endfor
     else
       error ("__plt2mm__: arguments must be a matrices");
diff --git a/scripts/plot/__plt2mv__.m b/scripts/plot/__plt2mv__.m
--- a/scripts/plot/__plt2mv__.m
+++ b/scripts/plot/__plt2mv__.m
@@ -78,9 +78,10 @@ function retval = __plt2mv__ (h, x, y, o
 
       h = line (x(:,i), y, "keylabel", tkey, "color", color,
  "linestyle", options(i).linestyle,
- "marker", options(i).marker, "parent", hg, args{:});
+ "marker", options(i).marker, "parent", hg);
   
       __add_line_series__ (h, hg);
+      set (hg, args{:});
     endfor
   else
     error ("__plt2mv__: arguments must be a matrices");
diff --git a/scripts/plot/__plt2ss__.m b/scripts/plot/__plt2ss__.m
--- a/scripts/plot/__plt2ss__.m
+++ b/scripts/plot/__plt2ss__.m
@@ -59,9 +59,10 @@ function retval = __plt2ss__ (h, x, y, o
 
     h = line (x, y, "keylabel", key, "color", color,
       "linestyle", options.linestyle,
-      "marker", options.marker, "parent", hg, properties{:});
+      "marker", options.marker, "parent", hg);
 
     __add_line_series__ (h, hg);
+    set (hg, properties{:});
   else
     error ("__plt2ss__: arguments must be scalars");
   endif
diff --git a/scripts/plot/__plt2sv__.m b/scripts/plot/__plt2sv__.m
--- a/scripts/plot/__plt2sv__.m
+++ b/scripts/plot/__plt2sv__.m
@@ -58,9 +58,10 @@ function retval = __plt2sv__ (h, x, y, o
 
       h = line (x, y(i), "keylabel", tkey, "color", color,
  "linestyle", options(i).linestyle,
- "marker", options(i).marker, "parent", hg, args{:});
+ "marker", options(i).marker, "parent", hg);
 
       __add_line_series__ (h, hg);
+      set (hg, args{:});
     endfor
   else
     error ("__plt2sv__: first arg must be scalar, second arg must be vector");
diff --git a/scripts/plot/__plt2vm__.m b/scripts/plot/__plt2vm__.m
--- a/scripts/plot/__plt2vm__.m
+++ b/scripts/plot/__plt2vm__.m
@@ -78,10 +78,10 @@ function retval = __plt2vm__ (h, x, y, o
 
       h = line (x, y(:,i), "keylabel", tkey, "color", color,
  "linestyle", options(i).linestyle,
- "marker", options(i).marker, "parent", hg, args{:});
+ "marker", options(i).marker, "parent", hg);
 
       __add_line_series__ (h, hg);
-
+      set (hg, args{:});
     endfor
   else
     error ("__plt2vm__: arguments must be a matrices");
diff --git a/scripts/plot/__plt2vs__.m b/scripts/plot/__plt2vs__.m
--- a/scripts/plot/__plt2vs__.m
+++ b/scripts/plot/__plt2vs__.m
@@ -58,9 +58,10 @@ function retval = __plt2vs__ (h, x, y, o
 
       h = line (x(i), y, "keylabel", tkey, "color", color,
  "linestyle", options(i).linestyle,
- "marker", options(i).marker, "parent", hg, args{:});
+ "marker", options(i).marker, "parent", hg);
 
       __add_line_series__ (h, hg);
+      set (hg, args{:});
     endfor
   else
     error ("__plt2vs__: first arg must be vector, second arg must be scalar");
diff --git a/scripts/plot/__plt2vv__.m b/scripts/plot/__plt2vv__.m
--- a/scripts/plot/__plt2vv__.m
+++ b/scripts/plot/__plt2vv__.m
@@ -73,9 +73,10 @@ function retval = __plt2vv__ (h, x, y, o
 
     h = line (x, y, "keylabel", key, "color", color,
       "linestyle", options.linestyle,
-      "marker", options.marker, "parent", hg, properties{:});
+      "marker", options.marker, "parent", hg);
 
     __add_line_series__ (h, hg);
+    set (hg, properties{:});
   else
     error ("__plt2vv__: vector lengths must match");
   endif
diff --git a/scripts/plot/__quiver__.m b/scripts/plot/__quiver__.m
--- a/scripts/plot/__quiver__.m
+++ b/scripts/plot/__quiver__.m
@@ -171,23 +171,23 @@ function hg = __quiver__ (varargin)
     [y.'; yend.'; NaN(1, length (y))](:),
     [z.'; zend.'; NaN(1, length (z))](:),
     "linestyle", linespec.linestyle,
-    "color", linespec.color, "parent", hg, args{:});
+    "color", linespec.color, "parent", hg);
       else
  h1 = plot ([x.'; xend.'; NaN(1, length (x))](:),
    [y.'; yend.'; NaN(1, length (y))](:),
    "linestyle", linespec.linestyle,
-    "color", linespec.color, "parent", hg, args{:});
+    "color", linespec.color, "parent", hg);
       endif
     else
       if (is3d)
  h1 = plot3 ([x.'; xend.'; NaN(1, length (x))](:),
     [y.'; yend.'; NaN(1, length (y))](:),
     [z.'; zend.'; NaN(1, length (z))](:),
-    "parent", hg, args{:});
+    "parent", hg);
       else
  h1 = plot ([x.'; xend.'; NaN(1, length (x))](:),
    [y.'; yend.'; NaN(1, length (y))](:),
-   "parent", hg, args{:});
+   "parent", hg);
       endif
     endif
 
@@ -295,6 +295,7 @@ function hg = __quiver__ (varargin)
     addlistener (hg, "markerfacecolor", @update_props);
     addlistener (hg, "markersize", @update_props);
 
+    set (hg, args{:});
   unwind_protect_cleanup
     set (h, "nextplot", hstate);
   end_unwind_protect
diff --git a/scripts/plot/__stem__.m b/scripts/plot/__stem__.m
--- a/scripts/plot/__stem__.m
+++ b/scripts/plot/__stem__.m
@@ -59,7 +59,7 @@ function h = __stem__ (have_z, varargin)
 
       hg  = hggroup ();
       h = [h; hg];
-      __add_datasource__ (caller, hg, {"x", "y", "z"}, varargin{:});
+      args = __add_datasource__ (caller, hg, {"x", "y", "z"}, varargin{:});
       
       if (i == 1)
  set (ax, "nextplot", "add");
@@ -142,6 +142,11 @@ function h = __stem__ (have_z, varargin)
       addlistener (hg, "xdata", @update_data);
       addlistener (hg, "ydata", @update_data);
       addlistener (hg, "zdata", @update_data);
+
+      set (hg, args{:});
+      if (i == 1 && !isempty(h_baseline))
+ set (h_baseline, "parent", get (hg, "parent"));
+      endif
     endfor
 
   unwind_protect_cleanup
diff --git a/scripts/plot/hold.m b/scripts/plot/hold.m
--- a/scripts/plot/hold.m
+++ b/scripts/plot/hold.m
@@ -75,6 +75,9 @@ function hold (varargin)
   endif
 
   if (isfigure (h))
+    if (isempty (get (h, "currentaxes")))
+      set (h, "currentaxes", __go_axes__ (h))
+    endif
     axes_objs = findobj (h, "type", "axes");
     h = [h; axes_objs];
   endif
diff --git a/scripts/plot/plot3.m b/scripts/plot/plot3.m
--- a/scripts/plot/plot3.m
+++ b/scripts/plot/plot3.m
@@ -180,9 +180,17 @@ function retval = plot3 (varargin)
  color = __next_line_color__ ();
       endif
 
-      tmp(++idx) = line (x(:), y(:), z(:),  "keylabel", key, "color", color,
- "linestyle", options.linestyle,
- "marker", options.marker, properties{:});
+      hg = hggroup ();
+      tmp(++idx) = hg;
+      properties = __add_datasource__ ("plot3", hg, {"x", "y", "z"}, properties{:});
+
+      hline = line (x(:), y(:), z(:),  "keylabel", key, "color", color,
+    "linestyle", options.linestyle,
+    "marker", options.marker, "parent", hg);
+
+      __add_line_series__ (hline, hg);
+
+      set (hg, properties{:});
 
       x_set = 0;
       y_set = 0;
@@ -231,9 +239,11 @@ function retval = plot3 (varargin)
 
       hline = line (x(:), y(:), z(:),  "keylabel", key, "color", color,
     "linestyle", options.linestyle,
-    "marker", options.marker, "parent", hg, properties{:});
-
-      __add_line_series__ (h, hg);
+    "marker", options.marker, "parent", hg);
+
+      __add_line_series__ (hline, hg);
+
+      set (hg, properties{:});
 
       x = new;
       y_set = 0;
@@ -301,9 +311,11 @@ function retval = plot3 (varargin)
 
     hline = line (x(:), y(:), z(:),  "keylabel", key, "color", color,
   "linestyle", options.linestyle,
-  "marker", options.marker, "parent", hg, properties{:});
+  "marker", options.marker, "parent", hg);
 
     __add_line_series__ (hline, hg);
+
+    set (hg, properties{:});
   endif
 
   set (gca (), "view", [-37.5, 30]);
diff --git a/scripts/plot/stairs.m b/scripts/plot/stairs.m
--- a/scripts/plot/stairs.m
+++ b/scripts/plot/stairs.m
@@ -146,10 +146,6 @@ function [h, xs, ys] = __stairs__ (doplo
  h = [h; hg];
  args = __add_datasource__ ("stairs", hg, {"x", "y"}, varargin{:});
 
- if (i == 1)
-  set (gca (), "nextplot", "add");
- endif
-
  addproperty ("xdata", hg, "data", x(:,i).');
  addproperty ("ydata", hg, "data", y(:,i).');
 
@@ -157,8 +153,8 @@ function [h, xs, ys] = __stairs__ (doplo
  addlistener (hg, "ydata", @update_data);
 
  tmp = line (xs(:,i).', ys(:,i).', "color", __next_line_color__ (),
-    "parent", hg, args{:});
-
+    "parent", hg);
+
         addproperty ("color", hg, "linecolor", get (tmp, "color"));
  addproperty ("linewidth", hg, "linelinewidth", get (tmp, "linewidth"));
  addproperty ("linestyle", hg, "linelinestyle", get (tmp, "linestyle"));
@@ -178,6 +174,8 @@ function [h, xs, ys] = __stairs__ (doplo
  addlistener (hg, "markerfacecolor", @update_props);
  addlistener (hg, "markeredgecolor", @update_props);
  addlistener (hg, "markersize", @update_props);
+
+ set (hg, args{:});
       endfor
     unwind_protect_cleanup
       set (gca (), "nextplot", hold_state);
diff --git a/src/ChangeLog b/src/ChangeLog
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,11 @@ 2008-08-28  David Bateman  <dbateman@fre
[phone]  David Bateman  <dbateman@...>
+
+ * src/graphics.cc: Replace int by octave_idx_type in multiple
+ places.
+ (array_property::is_equal): In macro CHECK_ARRAY_EQUAL, special
+ case scalar case and keep copy of array value to avoid early
+ destruction of converted array values.
+
 2008-08-28  David Bateman  <dbateman@...>
 
  * graphics.h.in (root_figure::properties::showhiddenhandles):
diff --git a/src/graphics.cc b/src/graphics.cc
--- a/src/graphics.cc
+++ b/src/graphics.cc
@@ -319,8 +319,8 @@ convert_cdata (const base_properties& pr
 
   NDArray a (dv);
 
-  int lda = static_cast<int> (a.numel () / 3);
-  int nc = cmap.rows ();
+  octave_idx_type lda = a.numel () / static_cast<octave_idx_type> (3);
+  octave_idx_type nc = cmap.rows ();
 
   double *av = a.fortran_vec ();
   const double *cmapv = cmap.data ();
@@ -332,7 +332,7 @@ convert_cdata (const base_properties& pr
   else
     cv = cdata.array_value ().data ();
 
-  for (int i = 0; i < lda; i++)
+  for (octave_idx_type i = 0; i < lda; i++)
     {
       double x = (cv ? cv[i] : double (icv[i]));
 
@@ -346,7 +346,7 @@ convert_cdata (const base_properties& pr
       else if (x >= nc)
  x = (nc - 1);
 
-      int idx = static_cast<int> (x);
+      octave_idx_type idx = static_cast<octave_idx_type> (x);
 
       av[i]       = cmapv[idx];
       av[i+lda]   = cmapv[idx+nc];
@@ -362,9 +362,9 @@ get_array_limits (const Array<T>& m, dou
   double& eminp)
 {
   const T *data = m.data ();
-  int n = m.numel ();
-
-  for (int i = 0; i < n; i++)
+  octave_idx_type n = m.numel ();
+
+  for (octave_idx_type i = 0; i < n; i++)
     {
       double e = double (data[i]);
 
@@ -736,40 +736,51 @@ array_property::is_equal (const octave_v
     {
       if (data.dims () == v.dims ())
  {
-#define CHECK_ARRAY_EQUAL(T,F) \
+
+#define CHECK_ARRAY_EQUAL(T,F,A) \
     { \
-      const T* d1 = data.F ().data (); \
-      const T* d2 = v.F ().data (); \
-      \
-      bool flag = true; \
-      \
-      for (int i = 0; flag && i < data.numel (); i++) \
- if (d1[i] != d2[i]) \
-  flag = false; \
-      \
-      return flag; \
-    }
-
-  if (data.is_double_type())
-    CHECK_ARRAY_EQUAL (double, array_value)
+      if (data.numel () == 1) \
+ return data.F ## scalar_value () == \
+  v.F ## scalar_value (); \
+      else  \
+ { \
+                  /* Keep copy of array_value to allow sparse/bool arrays */ \
+  /* that are converted, to not be deallocated early */ \
+  const A m1 = data.F ## array_value (); \
+  const T* d1 = m1.data (); \
+  const A m2 = v.F ## array_value (); \
+  const T* d2 = m2.data ();\
+  \
+  bool flag = true; \
+  \
+  for (int i = 0; flag && i < data.numel (); i++) \
+    if (d1[i] != d2[i]) \
+      flag = false; \
+  \
+  return flag; \
+ } \
+    }
+
+  if (data.is_double_type() || data.is_bool_type ())
+    CHECK_ARRAY_EQUAL (double, , NDArray)
   else if (data.is_single_type ())
-    CHECK_ARRAY_EQUAL (float, float_array_value)
+    CHECK_ARRAY_EQUAL (float, float_, FloatNDArray)
   else if (data.is_int8_type ())
-    CHECK_ARRAY_EQUAL (octave_int8, int8_array_value)
+    CHECK_ARRAY_EQUAL (octave_int8, int8_, int8NDArray)
   else if (data.is_int16_type ())
-    CHECK_ARRAY_EQUAL (octave_int16, int16_array_value)
+    CHECK_ARRAY_EQUAL (octave_int16, int16_, int16NDArray)
   else if (data.is_int32_type ())
-    CHECK_ARRAY_EQUAL (octave_int32, int32_array_value)
+    CHECK_ARRAY_EQUAL (octave_int32, int32_, int32NDArray)
   else if (data.is_int64_type ())
-    CHECK_ARRAY_EQUAL (octave_int64, int64_array_value)
+    CHECK_ARRAY_EQUAL (octave_int64, int64_, int64NDArray)
   else if (data.is_uint8_type ())
-    CHECK_ARRAY_EQUAL (octave_uint8, uint8_array_value)
+    CHECK_ARRAY_EQUAL (octave_uint8, uint8_, uint8NDArray)
   else if (data.is_uint16_type ())
-    CHECK_ARRAY_EQUAL (octave_uint16, uint16_array_value)
+    CHECK_ARRAY_EQUAL (octave_uint16, uint16_, uint16NDArray)
   else if (data.is_uint32_type ())
-    CHECK_ARRAY_EQUAL (octave_uint32, uint32_array_value)
+    CHECK_ARRAY_EQUAL (octave_uint32, uint32_, uint32NDArray)
   else if (data.is_uint64_type ())
-    CHECK_ARRAY_EQUAL (octave_uint64, uint64_array_value)
+    CHECK_ARRAY_EQUAL (octave_uint64, uint64_, uint64NDArray)
  }
     }
 

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On 29-Aug-2008, David Bateman wrote:

| Here is the promised patch

Thanks.

This eliminates the crash and now I see the same axis limit problem
that you originally commented on.

I see that Matlab does not handle the case of

  plot3 (x, complex_vector);

I thought this was supposed to be equivalent to

  plot3 (x, real (complex_vector), imag (complex_vector));

and it seems to be in Octave, but in Matlab, I just get a sine wave in
a 2D plot.  Does that make any sense?  I have to set "view (3)" (or
similar) to get a 3D representation.  The code I'm trying is

  t = (0:0.05:5)';
  tc = exp (2i*pi*t);
  tr = real (tc);
  ti = imag (tc);
  hold on; hg = hggroup ();
  h = plot3 (t, tr, ti, 'parent', hg);

It looks like zlim for the axes object is being set to [-0.6, 0.6] in
the call to __go_line__ in __line__.m, but I don't understand
precisely where that is happening or why.  The zdata in the hggroup
object clearly has min and max values of -1 and 1.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Ben Abbott]

On Friday, August 29, 2008, at 03:47PM, "John W. Eaton" <jwe@...> wrote:

>On 29-Aug-2008, David Bateman wrote:
>
>| Here is the promised patch
>
>Thanks.
>
>This eliminates the crash and now I see the same axis limit problem
>that you originally commented on.
>
>I see that Matlab does not handle the case of
>
>  plot3 (x, complex_vector);
>
>I thought this was supposed to be equivalent to
>
>  plot3 (x, real (complex_vector), imag (complex_vector));

In Matlab 2008a I get an error for "plot3(x, complex_vector)". I recall this being discussed on a prior thread ... link below.

http://www.nabble.com/Re%3A-Plotting-problem-again-p17637417.html

It was a "short" short discussion, between me, myself and I ;-)

Ben
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

Ben Abbott wrote:

> On Friday, August 29, 2008, at 03:47PM, "John W. Eaton" <jwe@...> wrote:
>  
>> On 29-Aug-2008, David Bateman wrote:
>>
>> | Here is the promised patch
>>
>> Thanks.
>>
>> This eliminates the crash and now I see the same axis limit problem
>> that you originally commented on.
>>
>> I see that Matlab does not handle the case of
>>
>>  plot3 (x, complex_vector);
>>
>> I thought this was supposed to be equivalent to
>>
>>  plot3 (x, real (complex_vector), imag (complex_vector));
>>    
>
> In Matlab 2008a I get an error for "plot3(x, complex_vector)". I recall this being discussed on a prior thread ... link below.
>
> http://www.nabble.com/Re%3A-Plotting-problem-again-p17637417.html
>
> It was a "short" short discussion, between me, myself and I ;-)
>
> Ben
>
>  

yes this is a feature of Octave that matlab didn't implement.. Should we
disable the Octave feature?

D.


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

John W. Eaton wrote:
> It looks like zlim for the axes object is being set to [-0.6, 0.6] in
> the call to __go_line__ in __line__.m, but I don't understand
> precisely where that is happening or why.  The zdata in the hggroup
> object clearly has min and max values of -1 and 1.
>
>  
Yes that is what I see. Manually setting zlim shows the rest of the
plot.. I also don't see the reason yet, but was hoping Michael or Shai
would know.. If they don't look at this, I'll try to later this week.

D.




--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On Mon, Sep 1, 2008 at 11:46 AM, David Bateman
<David.Bateman@...> wrote:

> John W. Eaton wrote:
>> It looks like zlim for the axes object is being set to [-0.6, 0.6] in
>> the call to __go_line__ in __line__.m, but I don't understand
>> precisely where that is happening or why.  The zdata in the hggroup
>> object clearly has min and max values of -1 and 1.
>>
>>
> Yes that is what I see. Manually setting zlim shows the rest of the
> plot.. I also don't see the reason yet, but was hoping Michael or Shai
> would know.. If they don't look at this, I'll try to later this week.

Is it possible that the child of hggroup is reparented (as a child of
the hggroup) after settings its zdata? That is:
1) create the child as child of axes
2) set zdata
3) reparent as child of hggroup

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

Michael Goffioul wrote:

> On Mon, Sep 1, 2008 at 11:46 AM, David Bateman
> <David.Bateman@...> wrote:
>  
>> John W. Eaton wrote:
>>    
>>> It looks like zlim for the axes object is being set to [-0.6, 0.6] in
>>> the call to __go_line__ in __line__.m, but I don't understand
>>> precisely where that is happening or why.  The zdata in the hggroup
>>> object clearly has min and max values of -1 and 1.
>>>
>>>
>>>      
>> Yes that is what I see. Manually setting zlim shows the rest of the
>> plot.. I also don't see the reason yet, but was hoping Michael or Shai
>> would know.. If they don't look at this, I'll try to later this week.
>>    
>
> Is it possible that the child of hggroup is reparented (as a child of
> the hggroup) after settings its zdata? That is:
> 1) create the child as child of axes
> 2) set zdata
> 3) reparent as child of hggroup
>
> Michael.
>
>  

It depends how "__go_line__"  is implemented internally. The parent
hggroup is passed to the call to line and passed to __go_line__. If the
__go_line__ function parents to the axes and then changes the parent
internally, then yes the above is possible.

However, how does this cause the issue?

D.


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On Mon, Sep 1, 2008 at 12:39 PM, David Bateman
<David.Bateman@...> wrote:
> It depends how "__go_line__"  is implemented internally. The parent hggroup
> is passed to the call to line and passed to __go_line__. If the __go_line__
> function parents to the axes and then changes the parent internally, then
> yes the above is possible.
>
> However, how does this cause the issue?

It might be an issue as the internal limits of an hggroup is updated
when the x/y/zdata of one of its children is modified, but not when
one child is added or removed. However, I'm not sure this is the
cause of the problem here, because the X/Y limits are OK. I'll check
this later today.

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave