Sat 25 May 2013 10:04:13 AM UTC, comment #2:
Hello Philip,
I know there is a java-package in octave forge created by Michael Gouffioul.
He told me that this package is part of octave now.
That is what he mailed me:
> On Fri, May 24, 2013 at 11:59 AM, ernst <rei3ner@arcor.de> wrote:
>
> Hi Michael,
> outch! so, i cannot activate assertions at all.
> Well. What do you think about allowing, e.g. all standard java switches?
>
>
> I suppose constraints could be relaxed a bit. As the code is now part of octave, please make a bug report about it.
>
> Michael.
>
That makes the impression as if the package is no longer supported, right?
So i decided to follow Michaels advice and file to octave directly.
Whether Matlab supports further options, i cannot say and also not prove because i have no license.
I can point you only to
http://www.mathworks.de/support/solutions/en/data/1-18I2C/?solution=1-18I2C
which makes the impression that -mx256m is also a valid option.
Possibly, matlab does not check validity at all.
If this turns out true, i would say, octave must not check either.
As you say: Octave is often a kind of extension of matlab.
E.g. not equals can be written != and ~= in octave,
to be conform either with C or with Matlab.
Octave is a clone of Matlab insofar as each matlab source should run on octave but not the other way round, except backward compatibility is wanted.
Also Michaels package has some functions
working with octave (java_new) only and other working for both,
matlab and octave (javaObject).
This means that octave shall support a superset of what matlab supports.
To your third item, yes, it is a valuable aim to allow options only valid for "all" JVMs.
As said in
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.htmlhttp://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
-X option is non-standard already,
except if used alone (the standard is that it displays the nonstandard options). -XX is even unstable.
Here is a list of standard options:
http://javaeesupportpatterns.blogspot.de/2011/08/jvm-options-hotspot-vm-standard-options.html
Those should i think be supported. Maybe no more no less.
At least Michael himself, who most probably introduced the restriction seems to see no good reason for sticking to that the restriction (see above). But maybe one should enter in discussion with him.
Next item: rebuild octave and look for crashes.
I did not do that yet, but the internal of a JVM process
invoking methods and so has, besides data transport
only the influence that exceptions and errors are thrown.
Of course, -ea can cause such an exception (thats the reason for enabling assertions;-) ) but octave handles exceptins and errors from java smoothly.
At least for standard options i see no negative impact.
But maybe this must be tried with a greater community.
Last point: If i pass options to the jvm in a standalone application, then it is because i need them.
If i pass options to the jvm in octave it is the same.
Thats why just ignoring options is bad thing.
In my case, -ea it is important for bugfixing.
It is even more important, to see whether the java kernel does not work or the integration in octave makes the problems.
Ignoring -ea obscures this distinction.
You are right, it is conceivable that different options are needed for some reason. But then, still passing all options would be fine, because i can place one set of options standalone and another set for running within octave.
I think the point is to have good control.
Hope that convinces you. ;)
Greetings,
Ernst
|