bugGNU Octave - Bugs: bug #32261, another problem with object...


bug #32261: another problem with object subscript references - maybe related to #32182

Submitted by:  Volkmar Glauche <glauche>
Submitted on:  Thu 27 Jan 2011 12:55:11 PM UTC  
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Invalid Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

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


Sun 30 Jan 2011 09:02:46 PM UTC, comment #5:

It seems that for this cj.mat, you would need the entire SPM. I have tried to reproduce this issue using a smaller subset of commands. During these trials, I came across various unexpected results, which I would like to report separately. Therefore, please mark this bug invalid.

Volkmar Glauche <glauche>
Sun 30 Jan 2011 05:29:22 PM UTC, comment #4:

I checked out a copy of matlabbatch and downloaded the file cj.mat. I ran octave in the top-level directory of the matlabbatch source tree. When I try loading cj.mat, I see:

What else do I need?

John W. Eaton <jwe>
Project Administrator
Thu 27 Jan 2011 10:39:08 PM UTC, comment #3:

Hi John,

I'll try to strip the problem down to its core, but in the meantime I'd like to clarify what problem I observe with this dataset:

cj is a collection of cfg_* objects. Looking at the .mat file outside octave, it seems to be correct. The following code should point to a cfg_choice object (and its children)

However, octave returns

On the other hand, if I run

I get the cfg_choice object displayed correctly:

Thus, I assume it is stored correctly, but somehow I can't access it with

I hope this explanation helps a little.



Volkmar Glauche <glauche>
Thu 27 Jan 2011 10:15:08 PM UTC, comment #2:

You say

Obviously, cj.val{1}.val{1} and tmp.val{1} should return the same data

but it is not at all obvious to me what should happen with these large structures in which all the complexity of the structure appears to be exposed.

It may be obvious to you, because you are quite familiar with the data structures and understand what is supposed to be happening.

To help us debug these problems, it would help a lot if you were very explicit in stating exactly what things are not as you expect, and also showing us precisely what you do expect.

For example, instead of just saying that the structure is not a proper cfg_* object, tell us precisely which fields are not initialized, and perhaps how that can happen. As far as I know, a class structure can only be initialized by a call to the constructor for the class. So if there are elements that should be class objects but are not, then point that out specifically. If there are elements that are not initialized as you expect, but they are class objects, then I guess that happens because the constructor is called in some way that you are not expecting. If so, perhaps you can identify which path through the constructor must have occurred in order to generate the given structure. I can maybe figure this out for simple examples, but I do not have the time to understand all of matlabbatch in order to debug a problem.

John W. Eaton <jwe>
Project Administrator
Thu 27 Jan 2011 02:44:10 PM UTC, comment #1:

I've uploaded the data to


Please forgive the huge amount of data and code involved. I do hope the steps
to reproduce the problem are a hint as to what is going wrong.

Volkmar Glauche <glauche>
Thu 27 Jan 2011 12:55:11 PM UTC, original submission:

I've found another problem that looks similar to bug #32182. Unfortunately, the example code below needs the whole matlabbatch (but not SPM). You can get the code via subversion from

The sourceforge source code browser at

doesn't seem to work right now, but you could also get the branches/mlb_1 .tgz from there.

In addition, I'd need to upload/send a .mat file of ~11MB. Do you have a place to put it, as our hospital public server doesn't seem to respond?

After loading the cj.mat, try exploring the .val fields of the object hierarchy in cj. All of them should contain cell arrays with either cfg_* objects or data values.

Obviously, cj.val{1}.val{1} and tmp.val{1} should return the same data - tmp.val{1} is correct in this case. Also, tmp.val{1}.val{1} should be resolved to a cfg_choice object.

Volkmar Glauche <glauche>


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by glauche (Submitted the item)

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

    Only project members can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-01-30 jwe StatusNone => Invalid
        Open/ClosedOpen => Closed

    Back to the top

    Powered by Savane 3.4