bugGNU Octave - Bugs: bug #48013, Java integration: conversion to...

 
 

bug #48013: Java integration: conversion to double

Submitter:  Ernst Reissner <ernstreissner>
Submitted:  Wed 25 May 2016 01:55:48 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  ErnstReissner Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 22 Aug 2016 10:03:48 AM UTC, comment #29: 

Hi Philip,
I suspect, that matlab shows special behavior
in conjunction with function disp, invoking .toString(), right?
I filed this as bug 48854.
So your problem disappears not before having implemented 48854.
Also I think conversion BigDecimal to double
shall be done via function double,
which does not work before bug #48591 is fixed.

As you wrote, conversion BigDecimal to double is slow,
but it is equally slow, whether it is converted
automatically or manually.

I also want to point out,
that without fix of 48013,
it is not possible, to use objects implementing an improved arithmetics, like BigDecimal do,
because passing intermediate results to octave
would cause destruction of the objects.



I posted several bug reports, some for some time in state 'need info'.
Could you help me filling in the gaps??

So, I think,  bug #48591 is fixed.

Ernst Reissner <ernstreissner>
Sun 21 Aug 2016 08:39:29 AM UTC, comment #28: 

Ernst,
Yes I have Matlab (r2016b prerelease), at work I have several more versions, the oldest (retired but still present) r2007a, then 2012a, 2014a and 2016b.

After a bit more delving into it w Matlab (r2016b) it shows that you are right.

The reason I was a bit misled is that Matlab acts deceptively: in the command terminal it does show the converted value (doubles) of java.math.BigDecimal objects, i.e. suggesting autoconversion, but it does not really convert them to doubles behind the scenes.
So in way it converts them but at the same time not.

To show what I mean:

>> cl = sh.getCellAt (0, 0)
cl =
<table:table-cell xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" office:value-type="float" office:value="1" xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0" calcext:value-type="float"><text:p xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0">1</text:p></table:table-cell>
>> cl.getValueType
ans =
FLOAT
>> cl.getValue
ans =
1
>>


...where I would expect "cl.getValue" to return something like <java.math.BigDecimal> rather than a number, like Octave does:

debug> scell.getValue ()
ans =
<Java object: java.math.BigDecimal>



OK, I'll close this report again.
Sorry for the noise, thanks for your attention.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 20 Aug 2016 10:08:49 PM UTC, comment #27: 

Dear Philip,
could you tell me where the failure in my thoughts is located?
I was sure to have found out,
that matlab does automatic conversion on primitive number types
and their wrappers,
but not on general java.lang.Number's.
So in particular not on java.math.BigDecimal.
If you want so see double here,
you definitely have to apply BigDecimal.doubleValue()
which is right what function double(.) does.
You can do it directly or via double(.).

I doubt the 'very fact... that Matlab does not need manual conversion here. '

Do you have a Matlab at hand? I tried to find out from the documentation.

I would like to point you to:
 http://uk.mathworks.com/help/matlab/matlab_external/handling-data-returned-from-a-java-method.html

Ernst Reissner <ernstreissner>
Sat 20 Aug 2016 09:50:35 PM UTC, comment #26: 

Ernst,

This bug is about Matlab compatible Java-to-Octave conversion and the very fact is that Matlab does not need manual conversion here.

So neither should the io package (i.e., the jOpenDocument reading function) need to apply double() explicitly.

BTW that would be some performance hit, as double() should be applied to every individual FLOAT cell reading (remember, spreadsheets can return very heterogeneous cell arrays).

That said, I am a little puzzled why this only happens with jOpenDocument but not for all the other Java-based .ods interfaces.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 20 Aug 2016 08:20:32 PM UTC, comment #25: 

@philip:
What I suggest really works only after bug #48591 is fixed.

Ernst Reissner <ernstreissner>
Sat 20 Aug 2016 08:18:53 PM UTC, comment #24: 

Ok, I reproduced the result.
I also obtain

octave:22> rawarr = ods2oct (ods, 1)
rawarr =
{
  [1,1] =
<Java object: java.math.BigDecimal>
  [2,1] =
<Java object: java.math.BigDecimal>
  [1,2] =
<Java object: java.math.BigDecimal>
  [2,2] =
<Java object: java.math.BigDecimal>
}

but then

octave:32> cellfun(@double,rawarr)
ans =
   1.0000   2.0000
   1.5000   2.5000


Ok, I cannot figure out why cellfun turns the cellarray into a matrix, but application of function double does the work.
This is what the io-package should do when creating rawarr
and which was not necessary until now.


Ernst Reissner <ernstreissner>
Sat 20 Aug 2016 07:45:52 PM UTC, comment #23: 

Hm,... could be also related with bug #48591;
maybe it works if that patch is applied in addition.

This bug is on automatic conversion to double.
There is another kind of conversion,
related with java.lang.Number, which is so to speak manually,
applying function double(.)...
I'll try to reproduce your bug. ..

Ernst Reissner <ernstreissner>
Sat 20 Aug 2016 07:02:10 PM UTC, comment #22: 

iomltest.ods attached :-)

(file #38291)

Philip Nienhuis <philipnienhuis>
Group Member
Sat 20 Aug 2016 07:00:29 PM UTC, comment #21: 

Reopening this bug report.

Since applying the cset in comment #17 I get errors when reading .ods spreadsheets with the JOD (jOpenDocument) interface.
Backing out f094186125d3 restores proper operation.

With that cset applied, Octave reads (jOpenDocument) cell types "FLOAT" as java.math.BigDecimal instead of converting them to Octave double.

I have manually executed the relevant statements from the respective (private) jOpenDocument functions in the io package (v.2.4.2) in Matlab r2016a, and there, in Matlab, the cells are converted to double as I expected.

A simple .ods spreadsheet file is attached to this bug report. Reading it with LibreOffice, Excel 2013, Octave+io package with OCT / OTK / UNO interfaces works fine.
Reading it with JOD gets erroneous results; to reproduce:

>> pkg load io
>> javaaddpath ('jOpenDocument-1.4r2.jar')
>> format compact
>> ods = odsopen ('iomltest.ods', 0, 'jod')
ods =
  scalar structure containing the fields:
    xtype = JOD
    app = file
    filename = iomltest.ods
    workbook =
<Java object: org.jopendocument.dom.spreadsheet.SpreadSheet>
    changed = 0
    limits = [](0x0)
    odfvsn =  4
>> rawarr = ods2oct (ods, 1)
rawarr =
{
  [1,1] =
<Java object: java.math.BigDecimal>
  [2,1] =
<Java object: java.math.BigDecimal>
  [1,2] =
<Java object: java.math.BigDecimal>
  [2,2] =
<Java object: java.math.BigDecimal>
}
>> ods = odsclose (ods)
ods = [](0x0)


The proper results (e.g., with the otk interface = ODF Toolkit / odfdom) should look like:

>> ods = odsopen ('/mnt/win7/tmp/iomltest.ods', 0, 'otk')
Checking requested interface(s):
OTK*; (* = default interface)
ods =
  scalar structure containing the fields:
    xtype = OTK
    app =
<Java object: org.odftoolkit.odfdom.doc.OdfSpreadsheetDocument>
    filename = /mnt/win7/tmp/iomltest.ods
    workbook =
<Java object: org.odftoolkit.odfdom.dom.OdfContentDom>
    changed = 0
    limits = [](0x0)
    odfvsn = 0.8.8
>> raw = ods2oct (ods)
raw =
{
  [1,1] =  1
  [2,1] =  1.5000
  [1,2] =  2
  [2,2] =  2.5000
}


jOpendDocument-1.4-rc2.jar can be obtained from www.jopendocument.og (it is GPL, BTW).

Given that this occurs only with jOpenDocument, one can argue about whether this is jopendocument's fault.
But again, Matlab does return doubles with the jOpenDocument classlib loaded. So I tend to point to the fix in comment #7.

It can be worked around in the io package, but at the cost of a significant amount of complexity, duplicate code and if-endif blocks to select code paths depending on the Octave version at hand.
Obviously I'd rather see Octave mimic Matlab :-)

(BTW  jOpenDocument is IMO the best of all Java-based spreadsheet I/O classes for .ods; by far the fastest and it also supports the old OpenOffice.org .sxc format.)

Philip Nienhuis <philipnienhuis>
Group Member
Thu 11 Aug 2016 06:47:39 PM UTC, comment #20: 

Yes, please open a new bug or patch tracker to submit changes to the user manual about Java type handling.

Mike Miller <mtmiller>
Group Member
Thu 11 Aug 2016 02:36:37 PM UTC, comment #19: 

Hi Mike,
boxing and unboxing is a complicated issue.
Thus I would like to reopen that bug
and as i said write a separate section on conversion of data types between Java and Octave.

Or do you think it is better to open a new patch??

Ernst Reissner <ernstreissner>
Wed 03 Aug 2016 08:36:17 PM UTC, comment #18: 

Hi Mike,
I would like to add a separate section
in the manual on boxing and unboxing.
If you have a look at the corresponding documentation for Matlab,
you will understand that this is really highly necessary.

Ernst Reissner <ernstreissner>
Wed 03 Aug 2016 05:40:18 PM UTC, comment #17: 

Pushed the fix on the default branch

http://hg.savannah.gnu.org/hgweb/octave/rev/f094186125d3

followed by a cset containing tests for numeric class conversion

http://hg.savannah.gnu.org/hgweb/octave/rev/2f301a30aeed

Please note the commit message formatting and the commit message guidelines that I pointed you to earlier.

Thank you for your contribution to Octave.

Mike Miller <mtmiller>
Group Member
Tue 02 Aug 2016 06:23:52 PM UTC, comment #16: 

you are right...
I mixed up: also javaObject performs boxing
but only in the parameters,
no unboxing in return values of course.
(my brain is aging???? :O/ )

and you are right, the methods you provide are the best way to test.

I think we later have to add a separate class for tests only,
but for this bug this is not needed.

So now, you provide the tests and we can close the bug?

(except documentation and the minor patch I pointed to below)?
If so, I would like to add a separate section
in the manual on boxing and unboxing.

Ernst Reissner <ernstreissner>
Tue 02 Aug 2016 03:38:01 PM UTC, comment #15: 

Keeping the check in for java.lang.Number makes sense, thanks for pointing that out.

Ernst, I don't think your description of this is correct. Without the patch applied, I get the following:


>> x = javaObject ("java.lang.Integer", 12)
x =

<Java object: java.lang.Integer>

>> y = javaObject ("java.math.BigDecimal", 12)
y =

<Java object: java.math.BigDecimal>


Simply instantiating a class is not enough to trigger this bug, I think it has to be a javaMethod call that returns an object of a numeric wrapper type for this to be triggered.

What I would like are some standard library calls that return objects of each of the types that this patch handles so we can verify that they are converted to the appropriate Octave types.

I'm thinking the "valueOf" static methods might be a good way to test this interface:


javaMethod ("valueOf", "java.lang.Short", 0)
javaMethod ("valueOf", "java.lang.Double", 0)
...
javaMethod ("valueOf", "java.math.BigDecimal", 0)
javaMethod ("valueOf", "java.math.BigInteger", 0)


I would rather not add a class just for testing the Java interface if we can use examples from the standard library to do so just as well.

Mike Miller <mtmiller>
Group Member
Tue 02 Aug 2016 12:41:08 PM UTC, comment #14: 

Hi Mike,

Update:
Although you are right, saying:
'The test for whether jobj is a java.lang.Number is redundant now with the new helper function, so I deleted it. '
I would prefer not to do so for performance reasons.
Instead I would like to add a comment like:


     // 1st condition logically redundant, added for performance
     if (jni_env->IsInstanceOf (jobj, cls)
          && is_auto_convertible_number (jni_env, jobj))


The problem is namely, that without this condition,
for non-numbers the whole cascade of tests in is_auto_convertible_number is done.
The interface is really awfully slow at the moment.
Have a look at scripts/java/org/octave/ClassHelper,
at many places the author has redundant checks of that kind also.
And this is ok and good, I think.

Secondly,
at the moment, you do not need a java class for test.
Just try the following with and without patch.
octave:3> bd=javaObject('java.math.BigDecimal',3)

The correct result is
bd =

<Java object: java.math.BigDecimal>

bad is just bd=3.

Still I think  you are right, we need a testclass.
You did not answer my last post and so I just add my local file.
Please adapt as I suggested in my last post.

best regards,
Ernst


(file #38076)

Ernst Reissner <ernstreissner>
Thu 28 Jul 2016 06:58:22 PM UTC, comment #13: 

ok I agree with all you did.
I fixed the problem in .hgrc.
Concerning the testcases I would like to make an unconventional suggestion:
I have such a java-file and I would like to contribute it.
My idea is to add it to the java-files in
scripts/java/org/octave/ together with e.g. ClassHelper.java.

The advantage of doing so would be
that it is added to octave.jar
which controls java integration into octave.
That way it would be available to the user also
and could be used as an example in the tutorial.

Also when step by step boxing and unboxing is refactored
it can be extended to provide testcases by and by.

What do you think about that?
Also I would like to repeat my offer,
to write another chapter of the documentation
of the Java interface concerning boxing and unboxing.

Ernst Reissner <ernstreissner>
Thu 28 Jul 2016 05:53:25 PM UTC, comment #12: 

I forgot to mention that the commit message also needs to be reformatted as well to our commit message guidelines.

The commit message of the combined patch I attached is just the concatenated messages of previous patches.

http://wiki.octave.org/Commit_message_guidelines

Mike Miller <mtmiller>
Group Member
Thu 28 Jul 2016 05:46:12 PM UTC, comment #11: 

Thank you. I have made some more formatting fixes and small simplifications. Please find attached a patch that combines your two patches and my changes.

This change still needs unit tests to verify the cases when numeric conversion is done and not done. As it is right now the code looks fine but I have no examples to run against to verify whether it is working as expected. Can you help write those?

For your future reference, the changes I made are:

  • Removed trailing spaces on almost every line changed. Your editor leaves trailing white space on each line, please try to fix the editor or search and delete all trailing white space before finalizing patches.


  • The test for whether jobj is a java.lang.Number is redundant now with the new helper function, so I deleted it.


  • I reworded and reformatted the doxygen docs you added for the new function and for the box function.


  • Your surname is spelled "Reissnere" in your submitted patches, but "Reissner" is correct, right? Please fix your ~/.hgrc for future submissions if that is right.


(file #38043)

Mike Miller <mtmiller>
Group Member
Wed 27 Jul 2016 09:01:46 AM UTC, comment #10: 

Hi Mike,
i now endowed the methods under consideration
with a doxygen comment.

I think there is a need to add some documentation in the manual.
If I have a look at the according pages of Matlab, e.g.
http://de.mathworks.com/help/matlab/matlab_external/passing-data-to-a-java-method.html#bqgs38j

then I feel, that adding a whole section would be appropriate.
Should be in Appendix A 'External Code Interface(s)' (s is missing?), section 'Java Interface' top level. I would place it
as a sibling after 'Creating an instance of a Java class'.

I think also, we should add docs as we proceed with the conversion problematic.





(file #38035)

Ernst Reissner <ernstreissner>
Tue 26 Jul 2016 03:50:54 PM UTC, comment #9: 

Thanks for updating the patch. The name of the function is still not appropriate, we use snake_case not camelCase. The name of the function sounds like it is doing the conversion, I would call it something like "is_auto_convertible_number". The braces and indenting are good now. There should also be a space before the opening parenthesis of the argument list, and the return value should be on a separate line. I can fix these small issues or you can if you want to submit another updated patch.

As to doxygen, there are several files in Octave's code base now that are using the //! style, and consistency is the most important thing.

Do not use <p> HTML tags to separate paragraphs, just use an empty //! comment line.

Do not use <code> HTML tags to wrap a single word, use the @c doxygen command.

Mike Miller <mtmiller>
Group Member
Tue 26 Jul 2016 09:49:26 AM UTC, comment #8: 

Hi Mike,
yes you are right: one patch per bugfix and not all at once.
I had a look at the sources and the //! comment exists only ONCE in cc-files.

The /** style is used more frequently but in general doxygen comments seem to be sparse.
May I make a suggestion?
Since there are also java sources, let us use java style working also with javadoc.

What is wrong with <code></code> markup in doxygen comments?
I think even it is analogous to how octave comments m-files.

So at the moment I did not include any docs.
Could you decide on how to start doxygen comments
and whether to use html-markup in doxygen comments
and put a note into the manual?





(file #38029)

Ernst Reissner <ernstreissner>
Sat 23 Jul 2016 12:51:11 AM UTC, comment #7: 

Hi Ernst, thank you for providing a patch to fix this bug.

We really appreciate your contribution, but can you please try to submit small patches that address one specific change or class of changes? For example each bullet point that you listed in the commit message of your patch is very different from the others, implying that they should really be separate patches. The patch for this bug should consist only of the changes needed to support the right numeric conversion of Java types. As a reviewer, I spent a few minutes reading your patch, but got lost in the reformatting changes and it was not easy to see what parts are needed to fix the bug at hand.

Your new function autoBoxNumber does not follow our coding style conventions, please try to adhere to those when modifying or submitting new code. See https://www.gnu.org/software/octave/doc/interpreter/C_002b_002b-Sources.html and https://www.gnu.org/prep/standards/standards.html#Formatting).

As far as the other changes, you can separate those out and submit additional patches for things like reorganizing and documenting code, but please try to stick to our existing coding style conventions. We are unlikely to apply patches that make some of the whitespace changes that you propose here for example. And for doxygen markup, I believe we are using the "//!" convention already in our code base, and please try to avoid embedded HTML markup in the doxygen markup.

We hope to see continuing contributions from you, as the Java interface code does not get a lot of attention and does need some work. Please try to rework this patch into the minimal change needed to address the numeric conversion bug.

Mike Miller <mtmiller>
Group Member
Thu 21 Jul 2016 03:12:24 PM UTC, comment #6: 

Hi, i tried to provide a patch.
It is much more than fixing this bug:
it is documentation, a little reformatting
and also simplifications.

(file #37974)

Ernst Reissner <ernstreissner>
Mon 18 Jul 2016 05:17:33 PM UTC, comment #5: 

Hi Ernst, if you have made a local commit on your hg working copy, you need to run "hg export" to save that commit to a patch file and attach it to this bug report below.

Mike Miller <mtmiller>
Group Member
Sun 17 Jul 2016 10:46:47 AM UTC, comment #4: 

I found that matlab as described in
http://de.mathworks.com/help/matlab/matlab_external/passing-data-to-a-java-method.html
and
orks.com/help/matlab/matlab_external/handling-data-returned-from-a-java-method.html

converts only those java.lang.Number objects
which wrap the primitive types.
Not e.g. those in the java.math-package.

This behavior is vital for those implementing an alternative arithmetics in java.

I provided a fix in ...commit 432585a659ad

Ernst Reissner <ernstreissner>
Thu 26 May 2016 08:12:26 PM UTC, comment #3: 

Well, if I have a look at
http://hg.savannah.gnu.org/hgweb/octave/file/6cf6bc451eeb/libinterp/octave-value/ov-java.cc#l1156,
then I can see that octave converts a java object of type extending java/lang/Number
automatically to a double invoking method doubleValue().

According to the Matlab documentation,
only very few types extending java/lang/Number
are converted this way, namely those autoboxing the builtin types,
i.e. Double behaves like double Float like float and so on.

In contrast to this, java/math/BigDecimal,
also extending java/lang/Number is not converted that way.
This seems a detail only but is vital:
BigDecimal avoids errors by conversion of 10adic to binary format.
It allows to represent 0.2 without a failure.
Autoconversion would not even allow to add 0.2+0.2=0.4 without a failure because 0.2 would be converted back prior to addition.
Things like those are important whenever one tries to implement some kind of arithmetics, be it intervals, rational arithmetics or something else (which i do).

For objects extending java/lang/Number
THE USER may convert the type using EXPLICITLY
the matlab function double.
The documentation is quite implicit, but I suppose,
that the double function does nothing but invoking the java method doubleValue().

I hope that the few lines above contribute to clarification.

I think, the octave documentation should be extended
including the conversion process from octave to java
and vice versa as the matlab-documentation does.
By the way, the old java-package from michael goffioul did include some of this stuff which was not transported into the octave documentation when including the package.


Ernst Reissner <ernstreissner>
Wed 25 May 2016 10:34:00 PM UTC, comment #2: 

I'm pretty sure Matlab also added that note recently.  So, is Octave already Matlab Compatible?

There are a few BIST tests checking conversion at the end of ov-java.cc.  This should probably be expanded and put into an entire Java test suite in the test/ directory?

Rik <rik5>
Group administrator
Wed 25 May 2016 06:13:12 PM UTC, comment #1: 


> Seemingly, a java-object is converted to double iff a method double doubleValue() is defined, [...]


This is a bit more complex and supposedly Matlab compatible. See http://hg.savannah.gnu.org/hgweb/octave/file/6cf6bc451eeb/libinterp/octave-value/ov-java.cc#l1156

But basically, java Numbers of any type are converted to double, while arrays of java primitives are converted to octave arrays of matching types. We previously had the bug that Octave did not make that conversion automatically https://savannah.gnu.org/bugs/index.php?44882

See the Matlab documentation http://uk.mathworks.com/help/matlab/matlab_external/handling-data-returned-from-a-java-method.html which states:

> When a Java method is declared to return data of type java.lang.Object, MATLAB converts its value, depending on its actual type, according to the following table.


The table maps several (all?) java.lang.Number to class double. However, we implemented this following the Matlab docs and then found that the reality is a bit different. There is this extra note on the docs:

> There is no conversion if the method declaration specifies any subclass of Object or array of Object. For example, if the method is declared to return java.lang.String, then the return value remains a java.lang.String object and is not automatically converted to char as is shown in the table.


Which I think clears the mistake we (actually I) made while reading the Matlab docs. I'm pretty sure that note was not there 1 year ago.

Carnë Draug <carandraug>
Group Member
Wed 25 May 2016 01:55:48 PM UTC, original submission:  

Seemingly, a java-object is converted to double
iff a method double doubleValue() is defined,
as is for Double.doubleValue()
just by invoking this method.

This is not appropriate.
E.g. i provide a bunch of arithmetic types for octave
and now i cannot even add two numbers of java type
because they are converted implicitly to double
because they all have a method doubleValue().

My suggestion is, to just convert java-double to octave-double
and if the user wants conversion he/she can explicitly invoke method doubleValue().

Maybe conversion of Double is still appropriate, but I think no.

As you can see, this kind of treatment as suggested by me
is vital for several applications
and has no drawback.
In addition, it is easy to realize.

Thank you for considering.
I would like to keep in touch.

Greetings,

Ernst


Ernst Reissner <ernstreissner>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #38291:  iomltest.ods added by philipnienhuis (8KiB - application/vnd.oasis.opendocument.spreadsheet)
file #38076:  OctaveInterfaceTester.java added by ernstreissner (2KiB - application/x-java)
file #38043:  bug-48013-mtm.patch added by mtmiller (4KiB - text/x-diff)
file #38035:  fix48103Doc.patch added by ernstreissner (4KiB - text/x-patch)
file #38029:  fix48013.patch added by ernstreissner (2KiB - text/x-patch)
file #37974:  out.patch added by ernstreissner (73KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-21 rik5 Carbon-CopyRemoved 72865 -
    2016-08-21 philipnienhuis StatusNone Fixed
        Open/ClosedOpen Closed
    2016-08-20 philipnienhuis Attached File- Added iomltest.ods, #38291
    2016-08-20 philipnienhuis StatusFixed None
        Open/ClosedClosed Open
    2016-08-03 mtmiller StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2016-08-02 ernstreissner Attached File- Added OctaveInterfaceTester.java, #38076
    2016-07-28 mtmiller Attached File- Added bug-48013-mtm.patch, #38043
    2016-07-27 ernstreissner Attached File- Added fix48103Doc.patch, #38035
    2016-07-26 mtmiller StatusNone Patch Submitted
    2016-07-26 ernstreissner Attached File- Added fix48013.patch, #38029
    2016-07-23 mtmiller Release4.0.0 dev
    2016-07-21 ernstreissner Attached File- Added out.patch, #37974

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code