<[OtcDev] ML added too (I shouldn't have added help-octave)>
Please don't top post. Answer below the mail
Swift, Ted J. wrote:
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Thursday, September 13, 2012 1:41 AM
> To: Swift, Ted J.
> Subject: FWD: Re: [OctDev] xlread in 3.6.1
> <resent, reply to your personal e-mail bounced as that was shielded by Nabble>
> TedSwift [via Octave] wrote:
>>> I've followed this thread, but am still not able to get
>>> chk_spreadsheet_support to check out right. After putting Java in
>>> what I thought was the right place, these are the results of my last
>>> octave:5> chk_spreadsheet_support ('', 3)
>>> Checking Excel/ActiveX/COM... not working.
>>> Checking Java support...
>>> 1. Checking Java JRE presence.... OK, found one.
>>> 2. Checking Octave Java support... error: No Java support found:
>>> `java_invoke' undefined near line 49 column 16.
> => no or improperly installed Java package.
>>> error: called from:
>>> at line 176, column 3
>>> Something fundamental is still missing, or I don't have the setenv
>>> path set right. Are there any other diagnostic tools that will help
>>> me figure out where the breakdown is? Thanks, all.
> Try to run the newest Java package preinstall.m before your next attempt to install the Java package (any version).
> This file is in the svn repo here:
> http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/java/pre_install.m?sortby=rev&view=log > (watch for line wrap, take revision 10760, "download" or "as text", be sure to save it as a .m-file, and run it in Octave)
> I've only recently committed it in an attempt to avoid half-baked Java package installations.
> It'll check where Octave should look for the jvm lib and the executables and will complain if any of them is not found.
> I think the fact that the Java package installer not being able to find the Java executables (java, jar, javac) in the place it expects them to be was the creepy showstopper in many frustrating cases.
> You might make symlinks to them in your $PATH (in my Mageia 2 linux installation they seem to be silently created in /usr/bin by urpmi).
> Please copy preinstall.m's error msg (if any) in a reply mail. For me that's handy to have, because I might decide to implement (parts of) preinstall.m's functionality in chk_spreadsheet_support as well.
> BTW I've also recently updated the Octave wiki on exactly this subject:
> http://wiki.octave.org/Java_package#Make_sure_that_the_build_environment_is_configured_properly > (line wrap!)
> Thank you very much for the advice and pointers. And sorry for the
> delay in replying; I was busy last week being part of the
> organizing team for a scientific conference.
> Thanks for writing pre_install.m. I downloaded it and tried it,
> but it didn't provide any new insight: It did not return any errors.
> However, after I ran pre_install, I immediately ran
> chk_spreadsheet_support, and received the same error I've received
> before. Here's the transcript:
>> GNU Octave, version 3.6.1
>> octave:1> pwd
>> ans = C:\Users\tswift
>> octave:2> run pre_install.m %<--------- NOTE: No
>> error returned
You should have just typed:
and watch the output. No "run", no ".m" suffix. Just:
Note: scripts and function files seem to run better if invoked with just
their file name w/o suffix.