Re: Testers needed for an Octave-3.6.1 app (X86_64 only) bundle for MacOS

[Thomas Yengst]

>> 
>> Ben,
>> 
>> Sorry - I misinterpreted your original question. Here is 'path' from the 
>> octave prompt:
>> 
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/miscellaneous
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/optimization
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/path
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/pkg
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/plot
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/polynomial
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/prefs
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/set
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/signal
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/sparse
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/specfun
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/special-matrix
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/startup
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/statistics
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/statistics/base
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/statistics/distributions
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/statistics/models
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/statistics/tests
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/strings
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/testfun
>> /temp/Octave-3.6.1.app/Contents/Resources/share/octave/3.6.1/m/time
>> 
>> Tom
> 
> Opps, my bad, I wanted to check to see if lookup.oct was in the loadpath. 
> Unfortunately, I don't see exactly how to do that.
> 
> You can check to see of lookup.oct is in your  load path.
> 
>       file_in_loadpath lookup.oct
> 
> You can also check the exec path.
> 
>       strsplit (EXEC_PATH, pathsep)
> 
> I get the results below.
> 
> file_in_loadpath lookup.oct
> ans = 
> /Users/bpabbott/Desktop/Octave-3.6.1.app/Contents/Resources/lib/octave/3.6.1/oct/x86_64-apple-darwin11.3.0/lookup.oct
> 
> strsplit (EXEC_PATH, pathsep)
> ans = 
> {
>  [1,1] = 
> /Users/bpabbott/Desktop/Octave-3.6.1.app/Contents/Resources/libexec/octave/3.6.1/site/exec/x86_64-apple-darwin11.3.0
>  [1,2] = 
> /Users/bpabbott/Desktop/Octave-3.6.1.app/Contents/Resources/libexec/octave/api-v48+/site/exec/x86_64-apple-darwin11.3.0
>  [1,3] = 
> /Users/bpabbott/Desktop/Octave-3.6.1.app/Contents/Resources/libexec/octave/site/exec/x86_64-apple-darwin11.3.0
>  [1,4] = 
> /Users/bpabbott/Desktop/Octave-3.6.1.app/Contents/Resources/libexec/octave/3.6.1/exec/x86_64-apple-darwin11.3.0
>  [1,5] = /Users/bpabbott/Desktop/Octave-3.6.1.app/Contents/Resources/bin
> }
> 
> As you have an .octaverc file, you should check that there are no contents 
> that might break the app bundle by modifying the core loadpath, exec path, or 
> core m-file path.

file_in_loadpath lookup.oct
        ==> returns NULL

strsplit (EXEC_PATH, pathsep)
        ==> returns errors, which I guess makes sense since lookup.oct is not 
in the load path

EXEC_PATH = 
/temp/Octave-3.6.1.app/Contents/Resources/libexec/octave/3.6.1/site/exec/x86_64-apple-darwin10.8.0:/temp/Octave-3.6.1.app/Contents/Resources/libexec/octave/api-v48+/site/exec/x86_64-apple-darwin10.8.0:/temp/Octave-3.6.1.app/Contents/Resources/libexec/octave/site/exec/x86_64-apple-darwin10.8.0:/temp/Octave-3.6.1.app/Contents/Resources/libexec/octave/3.6.1/exec/x86_64-apple-darwin10.8.0:/temp/Octave-3.6.1.app/Contents/Resources/bin
        ==> so this means that strsplit is not working because it's not in the 
EXEC_PATH either.

I moved my .octaverc out of the way and still got the same results. Doesn't 
look like I get lookup.oct in the EXEC_PATH, which I think causes all the other 
problems.

When I type restoredefaultpath; path, I get the same result as you do Ben.

weird.

Tom