Fri 23 Jun 2017 06:29:43 PM UTC, comment #19:
That's happened to me before, savannah is what it is, no big deal.
|
Fri 23 Jun 2017 06:43:06 AM UTC, comment #18:
Looking in the bug tracker archive I see that you and I probably had this bug report open simultaneously.
I suppose what happened is that you saved first with changed status; a few minutes later I did but of course with the old status still set in my browser window, unaware of the changes you just had saved.
So it looks like we need some sort of mutexes or semaphores in the bug tracker ....
|
Fri 23 Jun 2017 06:34:34 AM UTC, comment #17:
Reopening wasn't on purpose, sorry.
Thanks for pushing.
Closing as fixed (now finally :-)
|
Fri 23 Jun 2017 02:44:43 AM UTC, comment #16:
As promised, the other set of tests is added, pushed under your name:
https://hg.savannah.gnu.org/hgweb/octave/rev/8b5bc5e5f74b
Did you reopen this on purpose or accidentally? This bug is still fixed right? Fixed for me.
|
Thu 22 Jun 2017 08:35:03 PM UTC, comment #15:
Works on Windows as well (as expected).
In comment #13 I've uploaded tests for most java basic types with and w/o arguments. Interesting or not, they should work and may catch a regression we cannot think up now.
I also added an java.awt test - but I don't know if it'll work w/o a display (TTBOMK it is invisible by default anyway).
|
Thu 22 Jun 2017 08:16:29 PM UTC, comment #14:
I pushed the fix onto default along with some tests combined with your string tests.
https://hg.savannah.gnu.org/hgweb/octave/rev/d197f62cde8a
Like I said, I don't think there's much value with respect to this particular bug in testing every numeric type with similar method calls. The parser and interpreter have been exercised enough here.
I think your proposed tests do still have value as tests on their own, so I'll work those into another changeset, but not related to this bug number.
|
Wed 21 Jun 2017 09:17:05 PM UTC, comment #13:
The proposed solution works at least on Linux.
I'll also try on Windows but I can test a cross-build only tomorrow evening at the earliest.
In the mean time I attach a file with some basis tests, invoking methods with and w/o arguments.
Some editing is needed, e.g. adding %%test lines, but I don't know if you want them separate for each Java type or all together.
(file #41020)
|
Wed 21 Jun 2017 07:51:13 PM UTC, comment #12:
All of my tests are on String, because there aren't really any interesting methods that take arguments for the other primitive type class wrappers (Double, Integer, Long, etc).
IMO, if we're already testing that Octave can call several methods on a String and pass arguments to those methods, I don't think it adds much value to test calling Integer.toString, or Integer.equals(another_integer).
I didn't look outside of java.lang, so please do suggest other tests based on awt, swing, or maybe java.util, container types? I don't remember much Java standard library myself. As long as it doesn't require a graphical display for the awt or swing classes.
|
Wed 21 Jun 2017 07:45:33 PM UTC, comment #11:
Sure.
I think that some tests for basic Java types (double, string, float, ..) + some compound types (awt, swing, ...) would be nice.
First I'll try your proposed fix.
Status => in progress
|
Wed 21 Jun 2017 04:57:06 PM UTC, comment #10:
Philip - if you don't mind, please post your test cases here, I already have a changeset with this fix and some test cases I've assembled based on the discussion here, but happy to incorporate some more.
|
Wed 21 Jun 2017 04:17:23 PM UTC, comment #9:
Thank you gentlemen for looking into this. The XML functions in the io package were affected as well, so I'm glad this is tackled now.
I'll create a cset with some unit tests for ov-java.cc along the lines of comment #4 and comment #5 as soon as I had a chance to test & check Mike's fix.
|
Wed 21 Jun 2017 04:02:31 PM UTC, comment #8:
Yeah I will push this.
I also just noticed that functions in namespaces are broken with these indexing changes also:
but that's a separate issue, I'll post a separate report and investigate that next.
|
Wed 21 Jun 2017 12:38:59 PM UTC, comment #7:
Mike, your change seems fine. Could you please apply it?
But you are also right that there might be a better way. This indexing code is all a bit rough...
|
Wed 21 Jun 2017 05:05:17 AM UTC, comment #6:
Philip - thanks for identifying the change that introduced this, that helped me figure out what needed to change.
The attached diff fixes this issue for me. We should add unit tests for these kinds of method calls as well to make sure this is caught in the future.
jwe, if you're browsing - this change is a little sloppy, maybe we need to add a new method to octave_value for a type that is either a class or a classdef or a java object, for behaviors like this that all 3 have in common?
(file #40960)
|
Mon 12 Jun 2017 06:50:26 PM UTC, comment #5:
Confirmed here, any Java method that takes one or more arguments seems to hit this. Any method that takes no arguments works.
|
Fri 09 Jun 2017 06:37:10 PM UTC, comment #4:
A simpler test case that can be included in Octave's test suite:
|
Fri 09 Jun 2017 06:29:39 PM UTC, comment #3:
Maybe a clue:
I found that the
"object.method ()"
syntax doesn't work anymore, but
javaMethod ("method", object, <args>)
still works fine.
|
Thu 01 Jun 2017 05:56:03 PM UTC, comment #2:
A download-link for jopendocument:
http://jopendocument.org/download/jOpenDocument-1.3.jar
|
Thu 01 Jun 2017 09:20:43 AM UTC, comment #1:
Further bisecting reveals that cset 551fa3879615 ("improve compatibility and simplify evaluation of index expressions") is the culprit.
A little easier way to reproduce (still needs an external Java jar):
For jopendocument (.ods):
....while.....
|
Thu 01 Jun 2017 06:30:23 AM UTC, original submission:
With current dev version, the Java-based spreadsheet I/O functions in the io package don't work anymore.
As I don't run the io package test scripts regularly (while I do "make check" on every core Octave build) it took me a little while before I noticed.
Tracking down it turns out that some Java functions in external Java class libraries no longer work, while others still function fine.
After some "bisecting" I found that this has happened between csets 9f925aed7d1b and d2748870db4e.
To reproduce one or more of the Java class libs for spreadsheet I/O are needed; e.g., jExcelApi (for .xls files) or jOpendocument (for .ods files) (btw, these libraries are GPL; can they be attached to a bug report?)
or
After going back to before the mentioned csets (hg update 4fe410bd918d) the above commands work fine.
I've added JWE as he's the one who made the relevant changes.
|