Daniel Kraft | 1 Mar 2011 11:58
Picon

Implementation of a profiler

Hi all,

in January, I already posted with respect to a possible project to get 
me working on Octave (and maybe in the frame of Google Summer of Code). 
  See
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-January/022004.html.

Now, I think the most interesting project for me would be to work on a 
profiler.  Especially, since that is what would have been most useful to 
me as a user myself; and it also seems interesting to me.

I'm not sure when I will really have time to work on that, but my plan 
would be over the coming half year or so.  And I'll just write down some 
ideas here, and would be very interested to get your opinions with 
respect to them and work on a profiler in general (does it seem useful, 
doable and "good" the way I plan it?).

Admittedly, I have not yet looked at Octave's source code (further than 
checking out a hg repository).  But I suppose there's some kind of 
abstract syntax tree modelled by C++ classes that is generated by the 
parser and then used to evaluate different kinds of statements, 
expressions and the like.  For a profiler, my idea is to add code there 
that collects statistics like number of times something is 
evaluated/executed and the time needed for that.  This should be more or 
less straight-forward, and when that is done, some kind of UI (on the 
command-line similarly to gprof, for instance) can present the results.

However, I see two (possible) problems:

1) Collecting run-time for each statement may not work, because the 
(Continue reading)

Judd Storrs | 1 Mar 2011 16:34
Picon

Re: looking ahead to 3.6

On Mon, Feb 28, 2011 at 6:23 PM, John Swensen <jpswensen <at> comcast.net> wrote:
I took a quick look at the RStudio source and saw a lot of Java code (although there was some C++ code).  I couldn't ascertain whether the terminal emulator is in C++ or Java, but I am assuming the whole UI was Java as the main java dependency was GWT (the Google Web Toolkit).

FYI, because I was curious. It's not java in the traditional sense--GWT compiles java into javascript. The main interface seems to be a web application--it certainly seems like the interface runs as a web page inside an html display component which is surprisingly pleasant. I think they've separated the system into a "server" component that wraps the R interpreter with an AJAX interface and essentially a web application for an interface to communicate with the server. So it is quite different despite using QT for the implementation of the "browser". It's an interesting model.


--judd

Camillo | 1 Mar 2011 17:12
Picon

Re: SLATEC error: Chebyshev series too short for specified accuracy

On 27/feb/2011, at 11.29, Jarno Rajahalme wrote:

> On Feb 25, 2011, at 3:30 , ext Ben Abbott wrote:
> 
>> On Feb 24, 2011, at 7:57 PM, Camillo wrote:
>> 
>>> Hello,
>>> 
>>> I am working on a Mac build of Octave 3.4.0. It's almost complete: it passes 6908 tests, has 2 known
failures, and 5 unexpected ones. Four of these five are due to the same issue, an exception inside SLATEC:
"Chebyshev series too short for specified accuracy". I don't know Fortran and I'm not sure how to best
debug the issue. The compilers I am using are gcc and gfortran 4.2.1.
>>> 
>>> I first posted this question on the general mailing list, where Ben Abbot asked for more information, so
here it is:
>>> 
>>>> Where did you get your gfortran?
>>> 
>>> http://r.research.att.com/gfortran-42-5664.pkg
>>> 
>>>> What dependencies did you install?
>>> 
>>> All, except for gnuplot and ghostscript.
>>> 
>>>> What was the result of running ./configure? (it gives a summary at the end)
>>>> 
>>>> Finally, please copy-n-paste the actual error.
>>> 
>>> I'll attach the configure summary, and here are the insteresting parts of the output of "make check":
>>> 
>>> --------------------------------------------------------------------------------
>>> src/DLD-FUNCTIONS/besselj.cc ........................... PASS  180/180 
>>> src/DLD-FUNCTIONS/betainc.cc ........................... ***MESSAGE FROM ROUTINE INITS IN
LIBRARY SLATEC.
>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>> *  Chebyshev series too short for specified accuracy
>>> *  ERROR NUMBER = 1
>>> *   
>>> ***END OF MESSAGE
>>> 
>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>> 0          ERROR MESSAGE SUMMARY
>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>> SLATEC     INITS      Chebyshev series too         1         1         1
>>> 
>>> ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>> *  Chebyshev series too short for specified accuracy
>>> *  ERROR NUMBER = 1
>>> *   
>>> ***END OF MESSAGE
>>> 
>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>> 0          ERROR MESSAGE SUMMARY
>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>> SLATEC     INITS      Chebyshev series too         1         1         2
>>> 
>>> PASS    4/6    FAIL 2
>>> 
>>> ...
>>> 
>>> src/DLD-FUNCTIONS/gammainc.cc .......................... ***MESSAGE FROM ROUTINE INITS IN
LIBRARY SLATEC.
>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>> *  Chebyshev series too short for specified accuracy
>>> *  ERROR NUMBER = 1
>>> *   
>>> ***END OF MESSAGE
>>> 
>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>> 0          ERROR MESSAGE SUMMARY
>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>> SLATEC     INITS      Chebyshev series too         1         1         3
>>> 
>>> ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>> *  Chebyshev series too short for specified accuracy
>>> *  ERROR NUMBER = 1
>>> *   
>>> ***END OF MESSAGE
>>> 
>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>> 0          ERROR MESSAGE SUMMARY
>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>> SLATEC     INITS      Chebyshev series too         1         1         4
>>> 
>>> PASS    2/4    FAIL 2
>>> --------------------------------------------------------------------------------
>>> 
>>> This is the information about the fifth error from fntests.log:
>>> 
>>> --------------------------------------------------------------------------------
>>>>>>>> processing /private/tmp/homebrew-octave-3.4.0-kEbx/octave-3.4.0/src/mappers.cc
>>> ***** assert(arg (single(-1)), single(pi));
>>> !!!!! test failed
>>> assert (arg (single (-1)),single (pi)) expected
>>> 3.1416
>>> but got
>>> 3.1416
>>> values do not match
>>> --------------------------------------------------------------------------------
>>> 
>>> I know about the problem with Apple's BLAS and gfortran, and I am using a small wrapper library for the
affected routines (as suggested in
<http://developer.apple.com/hardwaredrivers/ve/errata.html#fortran_conventions>); this is
the "dotwrp" library you can see in the configure summary. I was told that a different wrapper has been
proposed on this list, replacing some functions from LAPACK as well; I was wondering if anybody has a
simple test case for some of those functions, so I could quickly check if the library I'm using is sufficient.
>>> 
>>> Best regards,
>>> Camillo Lugaresi
>>> 
>>> <configure summary>
>> 
>> I am also using 4.2.1 and the gfortran from AT&T.
>> 
>> Iv'e compiled for 32bit and do not see the SLATEC problem.
>> 
>> Jarno / Richard, might this be related to the 64bit vecLib problem?
>> 
> 
> I recall seeing similar error messages in the past. I recommend trying with the patch at http://savannah.gnu.org/patch/index.php?7468.
> 
> That patch provider gfortran native calling convention stubs for Apple BLAS and LAPACK calls. However,
it does not otherwise replace any LAPACK routines. 
> 
> Jarno

I tried applying that patch. Rather than fighting with autotools (OS X comes with an older version than
needed), I edited the configuration manually, but I think I got it to work. However, when I run "make
check", I get this:

--------------------------------------------------------------------------------
Integrated test scripts:

  src/DLD-FUNCTIONS/besselj.cc ........................... PASS  180/180 
  src/DLD-FUNCTIONS/betainc.cc ........................... ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
 ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
 *  Chebyshev series too short for specified accuracy
 *  ERROR NUMBER = 1
 *   
 ***END OF MESSAGE

 ***JOB ABORT DUE TO UNRECOVERED ERROR.
0          ERROR MESSAGE SUMMARY
 LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
 SLATEC     INITS      Chebyshev series too         1         1         1

 ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
 ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
 *  Chebyshev series too short for specified accuracy
 *  ERROR NUMBER = 1
 *   
 ***END OF MESSAGE

 ***JOB ABORT DUE TO UNRECOVERED ERROR.
0          ERROR MESSAGE SUMMARY
 LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
 SLATEC     INITS      Chebyshev series too         1         1         2

 PASS    4/6    FAIL 2
  src/DLD-FUNCTIONS/bsxfun.cc ............................ PASS   72/72  
  src/DLD-FUNCTIONS/cellfun.cc ........................... PASS   77/77  
  src/DLD-FUNCTIONS/chol.cc .............................. PASS   26/26  
  src/DLD-FUNCTIONS/conv2.cc ............................. PASS    4/4   
  src/DLD-FUNCTIONS/convhulln.cc ......................... PASS    2/2   
  src/DLD-FUNCTIONS/dassl.cc ............................. PASS    4/4   
  src/DLD-FUNCTIONS/det.cc ............................... PASS    5/5   
  src/DLD-FUNCTIONS/dlmread.cc ........................... PASS   20/20  
  src/DLD-FUNCTIONS/dmperm.cc ............................ PASS    5/5   
  src/DLD-FUNCTIONS/eig.cc ............................... PASS   20/20  
  src/DLD-FUNCTIONS/eigs.cc ..............................panic: Segmentation fault -- stopping myself...
make[2]: *** [check] Segmentation fault
make[1]: *** [check-recursive] Error 1
make: *** [check] Error 2
--------------------------------------------------------------------------------

What output do you get for "make check"?

Cheers,
CL

Laurent Hoeltgen | 1 Mar 2011 17:25
Picon
Gravatar

Re: looking ahead to 3.6

On Tue, 2011-03-01 at 10:34 -0500, Judd Storrs wrote:
> On Mon, Feb 28, 2011 at 6:23 PM, John Swensen <jpswensen <at> comcast.net>
> wrote:
>         
>         I took a quick look at the RStudio source and saw a lot of
>         Java code (although there was some C++ code).  I couldn't
>         ascertain whether the terminal emulator is in C++ or Java, but
>         I am assuming the whole UI was Java as the main java
>         dependency was GWT (the Google Web Toolkit).
> 
> 
> FYI, because I was curious. It's not java in the traditional
> sense--GWT compiles java into javascript. The main interface seems to
> be a web application--it certainly seems like the interface runs as a
> web page inside an html display component which is
> surprisingly pleasant. I think they've separated the system into a
> "server" component that wraps the R interpreter with an AJAX interface
> and essentially a web application for an interface to communicate with
> the server. So it is quite different despite using QT for
> the implementation of the "browser". It's an interesting model.
> 
> 
> 
> 
> --judd
> 
> 

Sage (http://www.sagemath.org/) does something similar. They regroup
common math tools and libraries which can be accessed through a
webinterface. The interface itself sends the commands to a server
component the evaluates the command.

Regards,
Laurent

Jarno Rajahalme | 1 Mar 2011 18:58

Re: SLATEC error: Chebyshev series too short for specified accuracy


On Mar 1, 2011, at 18:12 , ext Camillo wrote:

> On 27/feb/2011, at 11.29, Jarno Rajahalme wrote:
> 
>> On Feb 25, 2011, at 3:30 , ext Ben Abbott wrote:
>> 
>>> On Feb 24, 2011, at 7:57 PM, Camillo wrote:
>>> 
>>>> Hello,
>>>> 
>>>> I am working on a Mac build of Octave 3.4.0. It's almost complete: it passes 6908 tests, has 2 known
failures, and 5 unexpected ones. Four of these five are due to the same issue, an exception inside SLATEC:
"Chebyshev series too short for specified accuracy". I don't know Fortran and I'm not sure how to best
debug the issue. The compilers I am using are gcc and gfortran 4.2.1.
>>>> 
>>>> I first posted this question on the general mailing list, where Ben Abbot asked for more information,
so here it is:
>>>> 
>>>>> Where did you get your gfortran?
>>>> 
>>>> http://r.research.att.com/gfortran-42-5664.pkg
>>>> 
>>>>> What dependencies did you install?
>>>> 
>>>> All, except for gnuplot and ghostscript.
>>>> 
>>>>> What was the result of running ./configure? (it gives a summary at the end)
>>>>> 
>>>>> Finally, please copy-n-paste the actual error.
>>>> 
>>>> I'll attach the configure summary, and here are the insteresting parts of the output of "make check":
>>>> 
>>>> --------------------------------------------------------------------------------
>>>> src/DLD-FUNCTIONS/besselj.cc ........................... PASS  180/180 
>>>> src/DLD-FUNCTIONS/betainc.cc ........................... ***MESSAGE FROM ROUTINE INITS IN
LIBRARY SLATEC.
>>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>>> *  Chebyshev series too short for specified accuracy
>>>> *  ERROR NUMBER = 1
>>>> *   
>>>> ***END OF MESSAGE
>>>> 
>>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>>> 0          ERROR MESSAGE SUMMARY
>>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>>> SLATEC     INITS      Chebyshev series too         1         1         1
>>>> 
>>>> ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
>>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>>> *  Chebyshev series too short for specified accuracy
>>>> *  ERROR NUMBER = 1
>>>> *   
>>>> ***END OF MESSAGE
>>>> 
>>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>>> 0          ERROR MESSAGE SUMMARY
>>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>>> SLATEC     INITS      Chebyshev series too         1         1         2
>>>> 
>>>> PASS    4/6    FAIL 2
>>>> 
>>>> ...
>>>> 
>>>> src/DLD-FUNCTIONS/gammainc.cc .......................... ***MESSAGE FROM ROUTINE INITS IN
LIBRARY SLATEC.
>>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>>> *  Chebyshev series too short for specified accuracy
>>>> *  ERROR NUMBER = 1
>>>> *   
>>>> ***END OF MESSAGE
>>>> 
>>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>>> 0          ERROR MESSAGE SUMMARY
>>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>>> SLATEC     INITS      Chebyshev series too         1         1         3
>>>> 
>>>> ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
>>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>>> *  Chebyshev series too short for specified accuracy
>>>> *  ERROR NUMBER = 1
>>>> *   
>>>> ***END OF MESSAGE
>>>> 
>>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>>> 0          ERROR MESSAGE SUMMARY
>>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>>> SLATEC     INITS      Chebyshev series too         1         1         4
>>>> 
>>>> PASS    2/4    FAIL 2
>>>> --------------------------------------------------------------------------------
>>>> 
>>>> This is the information about the fifth error from fntests.log:
>>>> 
>>>> --------------------------------------------------------------------------------
>>>>>>>>> processing /private/tmp/homebrew-octave-3.4.0-kEbx/octave-3.4.0/src/mappers.cc
>>>> ***** assert(arg (single(-1)), single(pi));
>>>> !!!!! test failed
>>>> assert (arg (single (-1)),single (pi)) expected
>>>> 3.1416
>>>> but got
>>>> 3.1416
>>>> values do not match
>>>> --------------------------------------------------------------------------------
>>>> 
>>>> I know about the problem with Apple's BLAS and gfortran, and I am using a small wrapper library for the
affected routines (as suggested in
<http://developer.apple.com/hardwaredrivers/ve/errata.html#fortran_conventions>); this is
the "dotwrp" library you can see in the configure summary. I was told that a different wrapper has been
proposed on this list, replacing some functions from LAPACK as well; I was wondering if anybody has a
simple test case for some of those functions, so I could quickly check if the library I'm using is sufficient.
>>>> 
>>>> Best regards,
>>>> Camillo Lugaresi
>>>> 
>>>> <configure summary>
>>> 
>>> I am also using 4.2.1 and the gfortran from AT&T.
>>> 
>>> Iv'e compiled for 32bit and do not see the SLATEC problem.
>>> 
>>> Jarno / Richard, might this be related to the 64bit vecLib problem?
>>> 
>> 
>> I recall seeing similar error messages in the past. I recommend trying with the patch at http://savannah.gnu.org/patch/index.php?7468.
>> 
>> That patch provider gfortran native calling convention stubs for Apple BLAS and LAPACK calls. However,
it does not otherwise replace any LAPACK routines. 
>> 
>> Jarno
> 
> I tried applying that patch. Rather than fighting with autotools (OS X comes with an older version than
needed), I edited the configuration manually, but I think I got it to work. However, when I run "make
check", I get this:
> 
> --------------------------------------------------------------------------------
> Integrated test scripts:
> 
>  src/DLD-FUNCTIONS/besselj.cc ........................... PASS  180/180 
>  src/DLD-FUNCTIONS/betainc.cc ........................... ***MESSAGE FROM ROUTINE INITS IN
LIBRARY SLATEC.
> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
> *  Chebyshev series too short for specified accuracy
> *  ERROR NUMBER = 1
> *   
> ***END OF MESSAGE
> 
> ***JOB ABORT DUE TO UNRECOVERED ERROR.
> 0          ERROR MESSAGE SUMMARY
> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
> SLATEC     INITS      Chebyshev series too         1         1         1
> 
> ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
> *  Chebyshev series too short for specified accuracy
> *  ERROR NUMBER = 1
> *   
> ***END OF MESSAGE
> 
> ***JOB ABORT DUE TO UNRECOVERED ERROR.
> 0          ERROR MESSAGE SUMMARY
> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
> SLATEC     INITS      Chebyshev series too         1         1         2
> 
> PASS    4/6    FAIL 2
>  src/DLD-FUNCTIONS/bsxfun.cc ............................ PASS   72/72  
>  src/DLD-FUNCTIONS/cellfun.cc ........................... PASS   77/77  
>  src/DLD-FUNCTIONS/chol.cc .............................. PASS   26/26  
>  src/DLD-FUNCTIONS/conv2.cc ............................. PASS    4/4   
>  src/DLD-FUNCTIONS/convhulln.cc ......................... PASS    2/2   
>  src/DLD-FUNCTIONS/dassl.cc ............................. PASS    4/4   
>  src/DLD-FUNCTIONS/det.cc ............................... PASS    5/5   
>  src/DLD-FUNCTIONS/dlmread.cc ........................... PASS   20/20  
>  src/DLD-FUNCTIONS/dmperm.cc ............................ PASS    5/5   
>  src/DLD-FUNCTIONS/eig.cc ............................... PASS   20/20  
>  src/DLD-FUNCTIONS/eigs.cc ..............................panic: Segmentation fault -- stopping myself...
> make[2]: *** [check] Segmentation fault
> make[1]: *** [check-recursive] Error 1
> make: *** [check] Error 2
> --------------------------------------------------------------------------------
> 
> What output do you get for "make check"?
> 

I get only one FAIL on mappers, which is known and due to how Apple implements atan2f.

Did you note that with the BLAS wrapper you should NOT use -ff2c for Octave nor any dependencies (all fortran libraries).

  Jarno

Camillo | 1 Mar 2011 19:47
Picon

Re: SLATEC error: Chebyshev series too short for specified accuracy

On 01/mar/2011, at 18.58, Jarno Rajahalme wrote:

> 
> On Mar 1, 2011, at 18:12 , ext Camillo wrote:
> 
>> On 27/feb/2011, at 11.29, Jarno Rajahalme wrote:
>> 
>>> On Feb 25, 2011, at 3:30 , ext Ben Abbott wrote:
>>> 
>>>> On Feb 24, 2011, at 7:57 PM, Camillo wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> I am working on a Mac build of Octave 3.4.0. It's almost complete: it passes 6908 tests, has 2 known
failures, and 5 unexpected ones. Four of these five are due to the same issue, an exception inside SLATEC:
"Chebyshev series too short for specified accuracy". I don't know Fortran and I'm not sure how to best
debug the issue. The compilers I am using are gcc and gfortran 4.2.1.
>>>>> 
>>>>> I first posted this question on the general mailing list, where Ben Abbot asked for more information,
so here it is:
>>>>> 
>>>>>> Where did you get your gfortran?
>>>>> 
>>>>> http://r.research.att.com/gfortran-42-5664.pkg
>>>>> 
>>>>>> What dependencies did you install?
>>>>> 
>>>>> All, except for gnuplot and ghostscript.
>>>>> 
>>>>>> What was the result of running ./configure? (it gives a summary at the end)
>>>>>> 
>>>>>> Finally, please copy-n-paste the actual error.
>>>>> 
>>>>> I'll attach the configure summary, and here are the insteresting parts of the output of "make check":
>>>>> 
>>>>> --------------------------------------------------------------------------------
>>>>> src/DLD-FUNCTIONS/besselj.cc ........................... PASS  180/180 
>>>>> src/DLD-FUNCTIONS/betainc.cc ........................... ***MESSAGE FROM ROUTINE INITS IN
LIBRARY SLATEC.
>>>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>>>> *  Chebyshev series too short for specified accuracy
>>>>> *  ERROR NUMBER = 1
>>>>> *   
>>>>> ***END OF MESSAGE
>>>>> 
>>>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>>>> 0          ERROR MESSAGE SUMMARY
>>>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>>>> SLATEC     INITS      Chebyshev series too         1         1         1
>>>>> 
>>>>> ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
>>>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>>>> *  Chebyshev series too short for specified accuracy
>>>>> *  ERROR NUMBER = 1
>>>>> *   
>>>>> ***END OF MESSAGE
>>>>> 
>>>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>>>> 0          ERROR MESSAGE SUMMARY
>>>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>>>> SLATEC     INITS      Chebyshev series too         1         1         2
>>>>> 
>>>>> PASS    4/6    FAIL 2
>>>>> 
>>>>> ...
>>>>> 
>>>>> src/DLD-FUNCTIONS/gammainc.cc .......................... ***MESSAGE FROM ROUTINE INITS IN
LIBRARY SLATEC.
>>>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>>>> *  Chebyshev series too short for specified accuracy
>>>>> *  ERROR NUMBER = 1
>>>>> *   
>>>>> ***END OF MESSAGE
>>>>> 
>>>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>>>> 0          ERROR MESSAGE SUMMARY
>>>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>>>> SLATEC     INITS      Chebyshev series too         1         1         3
>>>>> 
>>>>> ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
>>>>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>>>>> *  Chebyshev series too short for specified accuracy
>>>>> *  ERROR NUMBER = 1
>>>>> *   
>>>>> ***END OF MESSAGE
>>>>> 
>>>>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>>>>> 0          ERROR MESSAGE SUMMARY
>>>>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>>>>> SLATEC     INITS      Chebyshev series too         1         1         4
>>>>> 
>>>>> PASS    2/4    FAIL 2
>>>>> --------------------------------------------------------------------------------
>>>>> 
>>>>> This is the information about the fifth error from fntests.log:
>>>>> 
>>>>> --------------------------------------------------------------------------------
>>>>>>>>>> processing /private/tmp/homebrew-octave-3.4.0-kEbx/octave-3.4.0/src/mappers.cc
>>>>> ***** assert(arg (single(-1)), single(pi));
>>>>> !!!!! test failed
>>>>> assert (arg (single (-1)),single (pi)) expected
>>>>> 3.1416
>>>>> but got
>>>>> 3.1416
>>>>> values do not match
>>>>> --------------------------------------------------------------------------------
>>>>> 
>>>>> I know about the problem with Apple's BLAS and gfortran, and I am using a small wrapper library for the
affected routines (as suggested in
<http://developer.apple.com/hardwaredrivers/ve/errata.html#fortran_conventions>); this is
the "dotwrp" library you can see in the configure summary. I was told that a different wrapper has been
proposed on this list, replacing some functions from LAPACK as well; I was wondering if anybody has a
simple test case for some of those functions, so I could quickly check if the library I'm using is sufficient.
>>>>> 
>>>>> Best regards,
>>>>> Camillo Lugaresi
>>>>> 
>>>>> <configure summary>
>>>> 
>>>> I am also using 4.2.1 and the gfortran from AT&T.
>>>> 
>>>> Iv'e compiled for 32bit and do not see the SLATEC problem.
>>>> 
>>>> Jarno / Richard, might this be related to the 64bit vecLib problem?
>>>> 
>>> 
>>> I recall seeing similar error messages in the past. I recommend trying with the patch at http://savannah.gnu.org/patch/index.php?7468.
>>> 
>>> That patch provider gfortran native calling convention stubs for Apple BLAS and LAPACK calls.
However, it does not otherwise replace any LAPACK routines. 
>>> 
>>> Jarno
>> 
>> I tried applying that patch. Rather than fighting with autotools (OS X comes with an older version than
needed), I edited the configuration manually, but I think I got it to work. However, when I run "make
check", I get this:
>> 
>> --------------------------------------------------------------------------------
>> Integrated test scripts:
>> 
>> src/DLD-FUNCTIONS/besselj.cc ........................... PASS  180/180 
>> src/DLD-FUNCTIONS/betainc.cc ........................... ***MESSAGE FROM ROUTINE INITS IN
LIBRARY SLATEC.
>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>> *  Chebyshev series too short for specified accuracy
>> *  ERROR NUMBER = 1
>> *   
>> ***END OF MESSAGE
>> 
>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>> 0          ERROR MESSAGE SUMMARY
>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>> SLATEC     INITS      Chebyshev series too         1         1         1
>> 
>> ***MESSAGE FROM ROUTINE INITS IN LIBRARY SLATEC.
>> ***POTENTIALLY RECOVERABLE ERROR, PROG ABORTED, TRACEBACK REQUESTED
>> *  Chebyshev series too short for specified accuracy
>> *  ERROR NUMBER = 1
>> *   
>> ***END OF MESSAGE
>> 
>> ***JOB ABORT DUE TO UNRECOVERED ERROR.
>> 0          ERROR MESSAGE SUMMARY
>> LIBRARY    SUBROUTINE MESSAGE START             NERR     LEVEL     COUNT
>> SLATEC     INITS      Chebyshev series too         1         1         2
>> 
>> PASS    4/6    FAIL 2
>> src/DLD-FUNCTIONS/bsxfun.cc ............................ PASS   72/72  
>> src/DLD-FUNCTIONS/cellfun.cc ........................... PASS   77/77  
>> src/DLD-FUNCTIONS/chol.cc .............................. PASS   26/26  
>> src/DLD-FUNCTIONS/conv2.cc ............................. PASS    4/4   
>> src/DLD-FUNCTIONS/convhulln.cc ......................... PASS    2/2   
>> src/DLD-FUNCTIONS/dassl.cc ............................. PASS    4/4   
>> src/DLD-FUNCTIONS/det.cc ............................... PASS    5/5   
>> src/DLD-FUNCTIONS/dlmread.cc ........................... PASS   20/20  
>> src/DLD-FUNCTIONS/dmperm.cc ............................ PASS    5/5   
>> src/DLD-FUNCTIONS/eig.cc ............................... PASS   20/20  
>> src/DLD-FUNCTIONS/eigs.cc ..............................panic: Segmentation fault -- stopping myself...
>> make[2]: *** [check] Segmentation fault
>> make[1]: *** [check-recursive] Error 1
>> make: *** [check] Error 2
>> --------------------------------------------------------------------------------
>> 
>> What output do you get for "make check"?
>> 
> 
> I get only one FAIL on mappers, which is known and due to how Apple implements atan2f.
> 
> Did you note that with the BLAS wrapper you should NOT use -ff2c for Octave nor any dependencies (all
fortran libraries).
> 
>  Jarno

Yes, I am not using -ff2c. But I remember now that I had compiled qrupdate with my BLAS workaround instead of
yours, so there may be a conflict there. Or perhaps I simply made a mistake in editing the configuration by
hand. I'll try to set up all the necessary tools to bootstrap a development snapshot when I have time
(unless someone wants to provide a tarball with the patch applied and configure regenerated).

CL
Jordi Gutiérrez Hermoso | 1 Mar 2011 20:13
Picon
Gravatar

Re: Implementation of a profiler

On 1 March 2011 04:58, Daniel Kraft <d <at> domob.eu> wrote:

> Now, I think the most interesting project for me would be to work on a
> profiler.  Especially, since that is what would have been most useful to me
> as a user myself; and it also seems interesting to me.

This is great news. I hope you go ahead with it. I'm currently
revising the Octave FAQ, and I see that a profiler has been a frequent
request. I would like to encourage you to pursue this project. I can't
personally supervise it as a GSoC project, however.

> PS: I guess that the usual FSF paperwork applies to Octave, right?

No, copyright right now isn't assigned with Octave. You keep it.

- Jordi G. H.

Jordi Gutiérrez Hermoso | 1 Mar 2011 20:22
Picon
Gravatar

Revising the FAQ

As announced, I pushed a substantial revision to the FAQ, trying to
bring it up to date:

     http://hg.savannah.gnu.org/hgweb/octave/rev/30f2a3b1d236

I put in comments many things I wasn't entirely sure about. I am
fairly certain of everything I did write. I don't think I wrote down
any blatant lies.

I want to include a new section and incorporate the Octave Wiki FAQ
with this one. The new section would be called "using Octave", since
the Octave Wiki FAQ mostly talks about how to accomplish several tasks
in Octave. Does this sound like a good idea?

I wonder if this is the right way to move the FAQ. Should it stay in
hg, or should I have moved everything to the wiki instead? Which way
would it be more likely for the FAQ to keep updated and relevant?

- Jordi G. H.

David Bateman | 1 Mar 2011 21:00
Favicon

Re: Revising the FAQ

Jordi Gutiérrez Hermoso wrote:
> As announced, I pushed a substantial revision to the FAQ, trying to
> bring it up to date:
>
>      http://hg.savannah.gnu.org/hgweb/octave/rev/30f2a3b1d236
>
> I put in comments many things I wasn't entirely sure about. I am
> fairly certain of everything I did write. I don't think I wrote down
> any blatant lies.
>
> I want to include a new section and incorporate the Octave Wiki FAQ
> with this one. The new section would be called "using Octave", since
> the Octave Wiki FAQ mostly talks about how to accomplish several tasks
> in Octave. Does this sound like a good idea?
>
> I wonder if this is the right way to move the FAQ. Should it stay in
> hg, or should I have moved everything to the wiki instead? Which way
> would it be more likely for the FAQ to keep updated and relevant?
>
> - Jordi G. H.
>
>   
Two points

- The OnCleanUp function exists in Octave 3.4, but the object created by
this function needs to be destroyed to run the cleanup code so in my
opinion the code using OnCleanUp is less clear than the use of
unwind_protect in Octave.

- The text about mat-files is still true

D.

Jordi Gutiérrez Hermoso | 1 Mar 2011 23:02
Picon
Gravatar

Re: Revising the FAQ

2011/3/1 David Bateman <dbateman <at> dbateman.org>:

> - The OnCleanUp function exists in Octave 3.4, but the object created by
> this function needs to be destroyed to run the cleanup code so in my
> opinion the code using OnCleanUp is less clear than the use of
> unwind_protect in Octave.
>
> - The text about mat-files is still true

Thanks, I fixed both of those points in the FAQ.

- Jordi G. H.


Gmane