From olaf.till at uni-jena.de Thu Oct 1 03:01:27 2009 From: olaf.till at uni-jena.de (Olaf Till) Date: Thu, 1 Oct 2009 10:01:27 +0200 Subject: griddata fails with same size interpolation vectors In-Reply-To: <4AC356E5.1040405@durham.ac.uk> References: <4AC356E5.1040405@durham.ac.uk> Message-ID: <20091001080127.GB3747@olaf> On Wed, Sep 30, 2009 at 02:02:29PM +0100, Grant Ingram wrote: > ... > This sequence of commands will fail: > > rand("state",1); > x=2*rand(100,1)-1; > y=2*rand(size(x))-1; > z=sin(2*(x.^2+y.^2)); > xi = linspace(-1,1,10); > yi = linspace(-1,1,10); > zi = griddata(x,y,z,xi,yi,"linear"); > mesh(xi,yi,zi); > print("griddata_check.eps","-depsc2"); The lines below (diff against Octave-3.2.2) should fix that for griddata.m (or you might prefer to give arguments xi and yi as column vectors). However, your mesh command is probably bound to fail anyway because zi would have to have dimensions (length (yi), length (xi)). Olaf --- orig-griddata.m 2009-08-20 11:19:23.000000000 +0200 +++ griddata.m 2009-10-01 09:22:34.000000000 +0200 @@ -63,6 +63,16 @@ [nr, nc] = size (xi); + if (nr == 1 && nc > 1) + xi = xi.'; + yi = yi.'; + nr = nc; + nc = 1; + transposed = true; + else + transposed = false; + endif + ## Triangulate data. tri = delaunay (x, y); zi = nan (size (xi)); @@ -106,10 +116,14 @@ ## Calculate D of plane equation ## Ax+By+Cz+D = 0; D = -(N(:,1) .* x1 + N(:,2) .* y1 + N(:,3) .* z1); - + ## Calculate zi by solving plane equation for xi, yi. zi(valid) = -(N(:,1).*xi(valid) + N(:,2).*yi(valid) + D) ./ N(:,3); + if (transposed) + zi = zi.'; + endif + else error ("griddata: unknown interpolation method"); endif From olaf.till at uni-jena.de Thu Oct 1 05:00:18 2009 From: olaf.till at uni-jena.de (Olaf Till) Date: Thu, 1 Oct 2009 12:00:18 +0200 Subject: empty matrix not treated as cell array when indexed with {} if a structure-field in entry is assigned to Message-ID: <20091001100018.GA4375@olaf> Hi, Octave version: 3.2.2 this works: octave:1> a = []; octave:2> a{1} = 1; but this not: octave:3> a = []; octave:4> a{1}.b = 1; error: matrix cannot be indexed with { Is that also the case in Octave 3.2.3? Olaf From dennisveatch at bellsouth.net Thu Oct 1 10:13:39 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Thu, 1 Oct 2009 11:13:39 -0400 Subject: dead-octave-bug-1, octave-3.2.3 Message-ID: <200910011113.39063.dennisveatch@bellsouth.net> The output. -- You can tuna piano, but you can't tune a fish. -------------- next part -------------- To: bug at octave.org Cc: dveatch Subject: [50 character or so descriptive subject here (for reference)] -------- Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu Description: ----------- The compile proces goes fine; nor problem there. When I attempt to run it from a terminal, it fails to run and throws this error; octave: symbol lookup error: /usr/lib/octave-3.2.3/liboctave.so: undefined symbol: pthread_mutexattr_init This also happens with version 3.2.2. Repeat-By: --------- The system is running gcc-4.4.1, glibc-2.10.1 and other needed friends. Prior to this it compiled and ran fine. Fix: --- Well, short of reverting my system back to the older versions of gcc/glibc, I don't know what the fix should be. Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux sidney 2.6.31.1 #1 SMP PREEMPT Fri Sep 25 12:33:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux configure opts: '--build=x86_64-pc-linux-gnu' '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-shared' '--enable-dl' '--with-g77' 'build_alias=x86_64-pc-linux-gnu' 'CC=gcc' 'CFLAGS=-O2 -march=x86-64' 'LDFLAGS=-s' 'CPPFLAGS=' 'CPP=cpp' 'CXX=g++' 'CXXFLAGS=-O2 -march=x86-64' Fortran compiler: gfortran FFLAGS: -O FLIBS: -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/../../.. -lz -lgfortranbegin -lgfortran -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.4.1 (GCC) CFLAGS: -O2 -march=x86-64 CPICFLAG: -fPIC C++ compiler: g++, version 4.4.1 CXXFLAGS: -O2 -march=x86-64 CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: -s LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.2.3 BLAS_LIBS: FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_FFTW3=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 From marwitz at physik.tu-berlin.de Thu Oct 1 11:36:21 2009 From: marwitz at physik.tu-berlin.de (Christian Marwitz) Date: Thu, 1 Oct 2009 18:36:21 +0200 (CEST) Subject: Bug: no textread and problems with colorbars Message-ID: Hallo, Sorry I am not a professional. I have installed octave 3.2.3 64bit on Suse 10.3. I get warnings about missing libraries. Where I can get the libraries? There are some rpm for octave 3.2.3 incl. the libraries. The installed program do not know 'textread' and have problems with colorbar constructions like ' cb=colorbar('EastOutside','YTickLabel',... {num2str(n),num2str(round((n-m)/2+m)),num2str(m),num2str(round((n-m)/2+m)),num2str(n)}, ... 'ytick',[0 0.25 0.5 0.75 1]); zlab = get(cb,'ylabel'); set(zlab,'String','Cycles'); set(gcf,'Colormap',cmaprh) ' please help me! I have a secound installation on windows Xp (ocatve 3.2.0) without any problems. But much less quick. Sincerely Christian ----- Federal Institute for Materials Research and Testing Christian Marwitz Unter den Eichen 44-46, 12203 Berlin House: 89, Dep. VI.2 Tel: +49 30 8104 3546 (Lab, Room 172) Tel: +49 30 8104 3591 (Office, Room 254) Fax: +49 30 8104 1817 Private Christian Marwitz Schudomastr. 45 12055 Berlin Tel: +49 30 66 400 440 (Alice) Mobile: +49 1577 785 86 96 (eplus) ----- From etienne at isr.ist.utl.pt Thu Oct 1 23:36:50 2009 From: etienne at isr.ist.utl.pt (etienne at isr.ist.utl.pt) Date: Thu, 01 Oct 2009 21:36:50 -0700 Subject: getfield() fails if many keys are given. Message-ID: <20091001213650.136930ptdrignrms@webmail.isr.ist.utl.pt> -------- Bug report for Octave 3.3.50+ configured for i686-pc-linux-gnu Description: ----------- getfield() fails if many keys are given. Repeat-By: --------- s = struct ("Hello", 0.123, "world", 45, "XXX",6) s = { Hello = 0.12300 world = 45 XXX = 6 } [vH, vX] = getfield (s, "Hello","XXX") error: scalar cannot be indexed with . error: called from: error: /home?tienne/prog?ctave/dist?ctave/tmpInstall/share?ctave/3.3.50+/m/miscellaneous/getfield.m at line 52, column 9 Fix: --- ======================================================================= --- scripts/miscellaneous/getfield.m.orig 2009-10-01 21:07:15.000000000 -0700 +++ scripts/miscellaneous/getfield.m 2009-10-01 21:20:35.000000000 -0700 @@ -40,16 +40,15 @@ ## @seealso{setfield, rmfield, isfield, isstruct, fieldnames, struct} ## @end deftypefn -## Author: Etienne Grossmann - -function s = getfield (s, varargin) +## Author: Etienne Grossmann +function varargout = getfield (s, varargin) for idx = 1:nargin-1 i = varargin{idx}; if (iscell (i)) - s = s(i{:}); + varargout{idx} = s(i{:}); else - s = s.(i); + varargout{idx} = s.(i); endif endfor ======================================================================= Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux sinonimo 2.6.26-2-686 #1 SMP Sun Jun 21 04:57:38 UTC 2009 i686 GNU/Linux configure opts: '--prefix=/home/etienne/prog/octave/dist/octave/tmpInstall' SED: /bin/sed Fortran compiler: gfortran FFLAGS: -O -mieee-fp FLIBS: -L/usr/lib/gcc/i486-linux-gnu/4.3.2 -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../.. -lgfortranbegin -lgfortran -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.2 (Debian 4.3.2-1.1) CFLAGS: -g -O2 CPICFLAG: -fPIC C++ compiler: g++, version 4.3.2 CXXFLAGS: -g -O2 CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/home/etienne/prog/octave/dist/octave/tmpInstall/lib/octave-3.3.50+ LEXLIB: LIBGLOB: LIBS: -lm AMD_CPPFLAGS: AMD_LDFLAGS: AMD_LIBS: -lamd ARPACK_LIBS: -larpack BLAS_LIBS: -llapack -lblas CAMD_CPPFLAGS: CAMD_LDFLAGS: CAMD_LIBS: -lcamd CARBON_LIBS: CCOLAMD_CPPFLAGS: CCOLAMD_LDFLAGS: CCOLAMD_LIBS: -lccolamd CHOLMOD_CPPFLAGS: CHOLMOD_LDFLAGS: CHOLMOD_LIBS: -lcholmod COLAMD_CPPFLAGS: COLAMD_LDFLAGS: COLAMD_LIBS: -lcolamd CURL_CPPFLAGS: CURL_LDFLAGS: CURL_LIBS: CXSPARSE_CPPFLAGS: CXSPARSE_LDFLAGS: CXSPARSE_LIBS: -lcxsparse DL_LIBS: -ldl FFTW3_CPPFLAGS: FFTW3_LDFLAGS: FFTW3_LIBS: -lfftw3 FFTW3F_CPPFLAGS: FFTW3F_LDFLAGS: FFTW3F_LIBS: -lfftw3f GRAPHICS_LIBS: -lfltk_gl -lfltk GLPK_CPPFLAGS: GLPK_LDFLAGS: GLPK_LIBS: -lglpk HDF5_CPPFLAGS: HDF5_LDFLAGS: HDF5_LIBS: -lhdf5 OPENGL_LIBS: -lfontconfig -lftgl -lfreetype -lz -L/usr/X11R6/lib -lGL -lGLU PTHREAD_CFLAGS: -pthread PTHREAD_LIBS: QHULL_CPPFLAGS: QHULL_LDFLAGS: QHULL_LIBS: -lqhull QRUPDATE_LIBS: READLINE_LIBS: -lreadline REGEX_LIBS: -L/usr/lib -lpcre TERM_LIBS: -lncurses UMFPACK_LIBS: -lumfpack X11_INCFLAGS: X11_LIBS: -lX11 Z_CPPFLAGS: Z_LDFLAGS: Z_LIBS: -lz DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -DOCTAVE_IDX_TYPE=int -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_PTHREAD=1 -DHAVE_X_WINDOWS=1 -DFLOAT_TRUNCATE= -DHAVE_LIBM=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_IEEE754_DATA_FORMAT=1 -DHAVE_QHULL_QHULL_A_H=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_Z=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3_H=1 -DHAVE_FFTW3=1 -DHAVE_FFTW3_H=1 -DHAVE_FFTW3F=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FREETYPE=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FONTCONFIG=1 -DHAVE_FLTK=1 -DHAVE_BLAS=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_CAMD_H=1 -DHAVE_CAMD=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From highegg at gmail.com Fri Oct 2 00:28:06 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 2 Oct 2009 07:28:06 +0200 Subject: griddata fails with same size interpolation vectors In-Reply-To: <20091001080127.GB3747@olaf> References: <4AC356E5.1040405@durham.ac.uk> <20091001080127.GB3747@olaf> Message-ID: <69d8d540910012228n391eb3a6p2297db1da2073a71@mail.gmail.com> On Thu, Oct 1, 2009 at 10:01 AM, Olaf Till wrote: > On Wed, Sep 30, 2009 at 02:02:29PM +0100, Grant Ingram wrote: >> ... >> This sequence of commands will fail: >> >> rand("state",1); >> x=2*rand(100,1)-1; >> y=2*rand(size(x))-1; >> z=sin(2*(x.^2+y.^2)); >> xi = linspace(-1,1,10); >> yi = linspace(-1,1,10); >> zi = griddata(x,y,z,xi,yi,"linear"); >> mesh(xi,yi,zi); >> print("griddata_check.eps","-depsc2"); > > The lines below (diff against Octave-3.2.2) should fix that for > griddata.m (or you might prefer to give arguments xi and yi as column > vectors). However, your mesh command is probably bound to fail anyway > because zi would have to have dimensions (length (yi), length (xi)). > > Olaf > > --- orig-griddata.m ? ? 2009-08-20 11:19:23.000000000 +0200 > +++ griddata.m ?2009-10-01 09:22:34.000000000 +0200 > @@ -63,6 +63,16 @@ > > ? [nr, nc] = size (xi); > > + ?if (nr == 1 && nc > 1) > + ? ?xi = xi.'; > + ? ?yi = yi.'; > + ? ?nr = nc; > + ? ?nc = 1; > + ? ?transposed = true; > + ?else > + ? ?transposed = false; > + ?endif > + > ? ## Triangulate data. > ? tri = delaunay (x, y); > ? zi = nan (size (xi)); > @@ -106,10 +116,14 @@ > ? ? ## Calculate D of plane equation > ? ? ## Ax+By+Cz+D = 0; > ? ? D = -(N(:,1) .* x1 + N(:,2) .* y1 + N(:,3) .* z1); > - > + > ? ? ## Calculate zi by solving plane equation for xi, yi. > ? ? zi(valid) = -(N(:,1).*xi(valid) + N(:,2).*yi(valid) + D) ./ N(:,3); > > + ? ?if (transposed) > + ? ? ?zi = zi.'; > + ? ?endif > + > ? else > ? ? error ("griddata: unknown interpolation method"); > ? endif I checked in a different fix, which should be more Matlab compatible: http://hg.savannah.gnu.org/hgweb/octave/rev/8cf522ce9c4d in any case, as you noted, the OP's script will still fail at "mesh". -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Fri Oct 2 00:25:26 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 2 Oct 2009 07:25:26 +0200 Subject: getfield() fails if many keys are given. In-Reply-To: <20091001213650.136930ptdrignrms@webmail.isr.ist.utl.pt> References: <20091001213650.136930ptdrignrms@webmail.isr.ist.utl.pt> Message-ID: <69d8d540910012225h1b62f292i24a4a15db4d9dae5@mail.gmail.com> On Fri, Oct 2, 2009 at 6:36 AM, wrote: > -------- > Bug report for Octave 3.3.50+ configured for i686-pc-linux-gnu > > Description: > ----------- > > ? getfield() fails if many keys are given. > > Repeat-By: > --------- > > s = struct ("Hello", 0.123, "world", 45, "XXX",6) > > s = > { > ? Hello = ?0.12300 > ? world = ?45 > ? XXX = ?6 > } > > > [vH, vX] = getfield (s, "Hello","XXX") > > error: scalar cannot be indexed with . > error: called from: > error: > /home?tienne/prog?ctave/dist?ctave/tmpInstall/share?ctave/3.3.50+/m/miscellaneous/getfield.m > at line 52, column 9 > > I think getfield is not supposed to work like that. Instead, getfield (s, "Hello","XXX") is equivalent to s.Hello.XXX which of course fails. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From marwitz at physik.tu-berlin.de Fri Oct 2 10:29:21 2009 From: marwitz at physik.tu-berlin.de (marwitz) Date: Fri, 2 Oct 2009 08:29:21 -0700 (PDT) Subject: Bug: no textread and problems with colorbars In-Reply-To: References: Message-ID: <25716715.post@talk.nabble.com> The Problems are solved. To read files with octave use the octave-io package. http://octave.sourceforge.net/packages.html The Problem with the colorbar is the 'axis square'. In my case 'axis square' manipulate the colorbar to a square colorbar!! cheers Christian -- View this message in context: http://www.nabble.com/Bug%3A-no-textread-and-problems-with-colorbars-tp25704159p25716715.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From etienne at isr.ist.utl.pt Fri Oct 2 22:41:30 2009 From: etienne at isr.ist.utl.pt (etienne at isr.ist.utl.pt) Date: Fri, 02 Oct 2009 20:41:30 -0700 Subject: getfield() fails if many keys are given. In-Reply-To: <69d8d540910012225h1b62f292i24a4a15db4d9dae5@mail.gmail.com> References: <20091001213650.136930ptdrignrms@webmail.isr.ist.utl.pt> <69d8d540910012225h1b62f292i24a4a15db4d9dae5@mail.gmail.com> Message-ID: <20091002204130.18843s1ay8962mg4@webmail.isr.ist.utl.pt> Hi Hajek, indeed, I apologize for the false alert. I was reviving some old code and thought that getfield() had broken, when in fact it must have changed its name to getfields(): octave:1> s = struct ("Hello", 0.123, "world", 45, "XXX",6) s = { Hello = 0.12300 world = 45 XXX = 6 } octave:2> [vH, vX] = getfields (s, "Hello","XXX") vH = 0.12300 vX = 6 So it's *my* code that I should fix... Etienne Quoting Jaroslav Hajek (Fri, 2 Oct 2009 07:25:26 +0200): > On Fri, Oct 2, 2009 at 6:36 AM, wrote: >> -------- >> Bug report for Octave 3.3.50+ configured for i686-pc-linux-gnu >> >> Description: >> ----------- >> >> ? getfield() fails if many keys are given. >> >> Repeat-By: >> --------- >> >> s = struct ("Hello", 0.123, "world", 45, "XXX",6) >> >> s = >> { >> ? Hello = ?0.12300 >> ? world = ?45 >> ? XXX = ?6 >> } >> >> >> [vH, vX] = getfield (s, "Hello","XXX") >> >> error: scalar cannot be indexed with . >> error: called from: >> error: >> /home?tienne/prog?ctave/dist?ctave/tmpInstall/share?ctave/3.3.50+/m/miscellaneous/getfield.m >> at line 52, column 9 >> >> > > I think getfield is not supposed to work like that. Instead, > > getfield (s, "Hello","XXX") > > is equivalent to > > s.Hello.XXX > > which of course fails. > > -- > RNDr. Jaroslav Hajek > computing expert & GNU Octave developer > Aeronautical Research and Test Institute (VZLU) > Prague, Czech Republic > url: www.highegg.matfyz.cz > -- http://www.isr.ist.utl.pt/~etienne ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From highegg at gmail.com Sat Oct 3 04:41:09 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Sat, 3 Oct 2009 11:41:09 +0200 Subject: getfield() fails if many keys are given. In-Reply-To: <20091002204130.18843s1ay8962mg4@webmail.isr.ist.utl.pt> References: <20091001213650.136930ptdrignrms@webmail.isr.ist.utl.pt> <69d8d540910012225h1b62f292i24a4a15db4d9dae5@mail.gmail.com> <20091002204130.18843s1ay8962mg4@webmail.isr.ist.utl.pt> Message-ID: <69d8d540910030241t3485b443h2017234e724cdd8f@mail.gmail.com> On Sat, Oct 3, 2009 at 5:41 AM, wrote: > > ?Hi Hajek, > > indeed, I apologize for the false alert. ? I was reviving some old code and > thought that getfield() had broken, when in fact it must have changed its > name to getfields(): > > octave:1> s = struct ("Hello", 0.123, "world", 45, "XXX",6) > s = > { > ?Hello = ?0.12300 > ?world = ?45 > ?XXX = ?6 > } > > octave:2> [vH, vX] = getfields (s, "Hello","XXX") > vH = ?0.12300 > vX = ?6 > > ?So it's *my* code that I should fix... > > ?Etienne > > OK. Btw., if you use structs as dictionaries, you may also want to take a look at the "dict" class in the general package (SVN version): octave:1> d = dict({"Hello","world","XXX"},{0.123,45,6}) d = dict: { Hello : 0.12300 XXX : 6 world : 45 } octave:2> d({"Hello","XXX"}) ans = { [1,1] = 0.12300 [1,2] = 6 } it's still a bit under development though, so there may be rough spots. Suggestions for features also welcome. hth -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From swsirlin at earthlink.net Sat Oct 3 00:03:03 2009 From: swsirlin at earthlink.net (sam sirlin) Date: Fri, 02 Oct 2009 22:03:03 -0700 Subject: bug in squeeze for chars? Message-ID: <4AC6DB07.4020000@earthlink.net> running 3.2.2 on freebsd, linux there seems to be a bug in squeeze on a characters squeeze('a') ans = sorry, printing char matrices not implemented yet the error message seems strange, as printing of char matrices seems to work just fine ['ab';'cd'] ans = ab cd squeeze seems ok for numbers squeeze(2) ans = 2.0000e+00 octave:25> From bpabbott at mac.com Sat Oct 3 17:41:07 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 03 Oct 2009 18:41:07 -0400 Subject: bug in squeeze for chars? In-Reply-To: <4AC6DB07.4020000@earthlink.net> References: <4AC6DB07.4020000@earthlink.net> Message-ID: <6A9668E2-F47C-4968-B31B-BFF5E7AA8C4B@mac.com> On Oct 3, 2009, at 1:03 AM, sam sirlin wrote: > running 3.2.2 on freebsd, linux > there seems to be a bug in squeeze on a characters > > squeeze('a') > ans = sorry, printing char matrices not implemented yet > > the error message seems strange, as printing of char matrices seems to > work just fine > > ['ab';'cd'] > ans = > > ab > cd > > > squeeze seems ok for numbers > > squeeze(2) > ans = 2.0000e+00 > octave:25> I'd be amazed if a proper solution were so easy (my c/c++ skills are not be be trusted), but I removed the check that produces the error "sorry, printing char matrices not implemented yet" and the results looks correct. octave:1> squeeze('a') ans = a and a more proper example ... octave:1> m(1,1,1) = 'a'; octave:2> m(1,1,2) = 'b'; octave:3> m(1,2,1) = 'c'; octave:4> m(1,2,2) = 'd'; octave:5> squeeze(m) ans = ab cd octave:6> size(squeeze(m)) ans = 2 2 octave:7> size(m) ans = 1 2 2 See the attached changeset (not intended to be committed). Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 924 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091003/5dfa468d/attachment.obj -------------- next part -------------- From swsirlin at earthlink.net Sat Oct 3 22:23:18 2009 From: swsirlin at earthlink.net (sam sirlin) Date: Sat, 03 Oct 2009 20:23:18 -0700 Subject: bug in squeeze for chars? In-Reply-To: <6A9668E2-F47C-4968-B31B-BFF5E7AA8C4B@mac.com> References: <4AC6DB07.4020000@earthlink.net> <6A9668E2-F47C-4968-B31B-BFF5E7AA8C4B@mac.com> Message-ID: <4AC81526.4030908@earthlink.net> Ben Abbott wrote: > > On Oct 3, 2009, at 1:03 AM, sam sirlin wrote: > >> running 3.2.2 on freebsd, linux >> there seems to be a bug in squeeze on a characters >> >> squeeze('a') >> ans = sorry, printing char matrices not implemented yet >> >> the error message seems strange, as printing of char matrices seems to >> work just fine >> >> ['ab';'cd'] >> ans = >> >> ab >> cd >> >> >> squeeze seems ok for numbers >> >> squeeze(2) >> ans = 2.0000e+00 >> octave:25> > > I'd be amazed if a proper solution were so easy (my c/c++ skills are > not be be trusted), but I removed the check that produces the error > "sorry, printing char matrices not implemented yet" and the results > looks correct. > > octave:1> squeeze('a') > ans = a > > and a more proper example ... > > octave:1> m(1,1,1) = 'a'; > octave:2> m(1,1,2) = 'b'; > octave:3> m(1,2,1) = 'c'; > octave:4> m(1,2,2) = 'd'; > octave:5> squeeze(m) > ans = > > ab > cd > > octave:6> size(squeeze(m)) > ans = > > 2 2 > > octave:7> size(m) > ans = > > 1 2 2 > > See the attached changeset (not intended to be committed). > > Ben Works for me! Thanks. Sam Sirlin From jwe at octave.org Sun Oct 4 00:07:08 2009 From: jwe at octave.org (John W. Eaton) Date: Sun, 4 Oct 2009 01:07:08 -0400 Subject: bug in squeeze for chars? In-Reply-To: <4AC81526.4030908@earthlink.net> References: <4AC6DB07.4020000@earthlink.net> <6A9668E2-F47C-4968-B31B-BFF5E7AA8C4B@mac.com> <4AC81526.4030908@earthlink.net> Message-ID: <19144.11644.565903.33028@segfault.lan> On 3-Oct-2009, sam sirlin wrote: | Ben Abbott wrote: | > | > On Oct 3, 2009, at 1:03 AM, sam sirlin wrote: | > | >> running 3.2.2 on freebsd, linux | >> there seems to be a bug in squeeze on a characters | >> | >> squeeze('a') | >> ans = sorry, printing char matrices not implemented yet | >> | >> the error message seems strange, as printing of char matrices seems to | >> work just fine | >> | >> ['ab';'cd'] | >> ans = | >> | >> ab | >> cd | >> | >> | >> squeeze seems ok for numbers | >> | >> squeeze(2) | >> ans = 2.0000e+00 | >> octave:25> | > | > I'd be amazed if a proper solution were so easy (my c/c++ skills are | > not be be trusted), but I removed the check that produces the error | > "sorry, printing char matrices not implemented yet" and the results | > looks correct. | > | > octave:1> squeeze('a') | > ans = a | > | > and a more proper example ... | > | > octave:1> m(1,1,1) = 'a'; | > octave:2> m(1,1,2) = 'b'; | > octave:3> m(1,2,1) = 'c'; | > octave:4> m(1,2,2) = 'd'; | > octave:5> squeeze(m) | > ans = | > | > ab | > cd | > | > octave:6> size(squeeze(m)) | > ans = | > | > 2 2 | > | > octave:7> size(m) | > ans = | > | > 1 2 2 | > | > See the attached changeset (not intended to be committed). | > | > Ben | Works for me! Thanks. I checked in the following change. http://hg.savannah.gnu.org/hgweb/octave/rev/90abfd8a2895 Simply skipping the error check doesn't fix the problem of squeeze ('a') returning an int8 object instead of a char object. My patch also fixes a similar problem for diag. Thanks, jwe From highegg at gmail.com Sun Oct 4 03:12:57 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Sun, 4 Oct 2009 10:12:57 +0200 Subject: bug in squeeze for chars? In-Reply-To: <19144.11644.565903.33028@segfault.lan> References: <4AC6DB07.4020000@earthlink.net> <6A9668E2-F47C-4968-B31B-BFF5E7AA8C4B@mac.com> <4AC81526.4030908@earthlink.net> <19144.11644.565903.33028@segfault.lan> Message-ID: <69d8d540910040112w34df0db9n25370499d585e960@mail.gmail.com> On Sun, Oct 4, 2009 at 7:07 AM, John W. Eaton wrote: > On ?3-Oct-2009, sam sirlin wrote: > > | Ben Abbott wrote: > | > > | > On Oct 3, 2009, at 1:03 AM, sam sirlin wrote: > | > > | >> running 3.2.2 on freebsd, linux > | >> there seems to be a bug in squeeze on a characters > | >> > | >> squeeze('a') > | >> ans = sorry, printing char matrices not implemented yet > | >> > | >> the error message seems strange, as printing of char matrices seems to > | >> work just fine > | >> > | >> ['ab';'cd'] > | >> ans = > | >> > | >> ab > | >> cd > | >> > | >> > | >> squeeze seems ok for numbers > | >> > | >> squeeze(2) > | >> ans = ?2.0000e+00 > | >> octave:25> > | > > | > I'd be amazed if a proper solution were so easy (my c/c++ skills are > | > not be be trusted), but I removed the check that produces the error > | > "sorry, printing char matrices not implemented yet" and the results > | > looks correct. > | > > | > octave:1> squeeze('a') > | > ans = a > | > > | > and a more proper example ... > | > > | > octave:1> m(1,1,1) = 'a'; > | > octave:2> m(1,1,2) = 'b'; > | > octave:3> m(1,2,1) = 'c'; > | > octave:4> m(1,2,2) = 'd'; > | > octave:5> squeeze(m) > | > ans = > | > > | > ab > | > cd > | > > | > octave:6> size(squeeze(m)) > | > ans = > | > > | > ? ?2 ? 2 > | > > | > octave:7> size(m) > | > ans = > | > > | > ? ?1 ? 2 ? 2 > | > > | > See the attached changeset (not intended to be committed). > | > > | > Ben > | Works for me! Thanks. > > I checked in the following change. > > ?http://hg.savannah.gnu.org/hgweb/octave/rev/90abfd8a2895 > > Simply skipping the error check doesn't fix the problem of squeeze > ('a') returning an int8 object instead of a char object. ?My patch > also fixes a similar problem for diag. > > Thanks, > > jwe What use is the is_string argument to octave_value::octave_value (const charNDArray&, bool is_str,...)? If is_str is false, it constructs an instance of octave_char_matrix ... that can't be properly printed, ischar() doesn't recognize it... is it actually used for any purpose? I mean - it obviously serves as a base to both the dq_string and sq_string, but it seems to me that it should never be constructed as a stand-alone instance. Or am I missing something? -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From tomas.kubin at fsv.cvut.cz Sun Oct 4 17:50:22 2009 From: tomas.kubin at fsv.cvut.cz (=?utf-8?B?SW5nLiBUb23DocWhIEt1YsOtbiBQaC5ELg==?=) Date: Mon, 5 Oct 2009 00:50:22 +0200 (CEST) Subject: patch and axes proterties Message-ID: <57801.81.0.203.147.1254696622.squirrel@webmail.fsv.cvut.cz> Bug report for Octave 3.0.1 configured for i486-pc-linux-gnu Description: ----------- The following code draws ellipses and pathces on the diferrent position. The function patch do not work correctly witch axes special settings. set(gca, 'XAxisLocation', 'top', 'YAxisLocation', 'right', 'XDir', 'reverse', 'YDir', 'reverse'); phi = linspace(0,2*pi,20); x = cos(phi); y = 2*sin(phi); hold on; patch(x, y, 'FaceColor', 'red') patch(x+2, y+5, 'FaceColor', 'green') plot(x, y, 'Color', 'red', 'linewidth', 3) plot(x+2, y+5, 'Color', 'green', 'linewidth', 3) Thanks Tomas Kubin Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux k151-67 2.6.26-2-686 #1 SMP Wed Aug 19 06:06:52 UTC 2009 i686 GNU/Linux configure opts: '--host=i486-linux-gnu' '--build=i486-linux-gnu' '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3gf' '--with-lapack=-llapackgf-3' '--with-hdf5' '--with-fftw' '--enable-shared' '--enable-rpath' '--disable-static' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXX=g++' 'CXXFLAGS=-g -O2' 'F77=gfortran' 'FFLAGS=-g -O2' Fortran compiler: gfortran FFLAGS: -O2 -g F2C: @F2C@ F2CFLAGS: @F2CFLAGS@ FLIBS: -L/usr/lib/gcc/i486-linux-gnu/4.3.2 -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.2 (Debian 4.3.2-1.1) CFLAGS: -O2 -g CPICFLAG: -fPIC C++ compiler: g++, version 4.3.2 CXXFLAGS: -O2 -g CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.0.1 BLAS_LIBS: -llapackgf-3 -lblas-3gf FFTW_LIBS: -lfftw3 LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DCXX_ABI=unknown -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMA=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_STRFTIME=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1 -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_EXP2=1 -DHAVE_LOG2=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot" User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /usr/lib/octave/3.0.1/site/exec/i486-pc-linux-gnu:/usr/lib/octave/api-v32/site/exec/i486-pc-linux-gnu:/usr/lib/octave/site/exec/i486-pc-linux-gnu:/usr/lib/octave/3.0.1/exec/i486-pc-linux-gnu:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/games IMAGE_PATH = .:/usr/share/octave/3.0.1/imagelib PAGER = pager PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot gnuplot_command_end = gnuplot_command_plot = pl gnuplot_command_replot = rep gnuplot_command_splot = sp gnuplot_command_title = t gnuplot_command_using = u gnuplot_command_with = w history_file = /home/kubin/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave3.0.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 print_answer_id_name = 1 print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From dbateman at dbateman.org Sun Oct 4 19:21:47 2009 From: dbateman at dbateman.org (David Bateman) Date: Mon, 05 Oct 2009 02:21:47 +0200 Subject: Plot Bug: 'markerfacecolor' does not work In-Reply-To: <19137.8142.214670.828607@segfault.lan> References: <4AB8EAD3.9070805@chalmers.se> <4AB924F7.8060104@dbateman.org> <4AB92AE1.7030806@dbateman.org> <19137.8142.214670.828607@segfault.lan> Message-ID: <4AC93C1B.1090800@dbateman.org> John W. Eaton wrote: > On 23-Sep-2009, Petr Mikulik wrote: > > | > > > 'markerfacecolor' does not work e.g. in the following plot-command: > | > > > plot(x, y, 'bo', 'markerfacecolor', 'r'); > | > > > The data points are still blue, but should be red. > | > > > | > > At the moment the gnuplot backend uses a single plot command for each line > | > > to gnuplot.. Gnuplot doesn't specify the line and point colour separately so > | > > as you found the markerfacecolor property is not respected.. We could quite > | > > easily modify the gnuplot backend code to use two separate gnuplot lines for > | > > each line to get the desired effect... > | > > > | > I have no desire (or time) to fully test the attached patch, but something > | > like this should give the behavior you want.. Does someone want to test this > | > patch further and maybe commit it? > | > | This patch changes colour of symbols to red instead of just "filling" it > | with red. > | > | Two plot commands are really necessary: if "markerfacecolor" is set and > | gnuplot point type is n=4,6,8,10,12 (diamonds, circles, triangles, ...), > | then: > | plot _data_ with point pt n+1 lc rgb _markerfacecolor_, \ > | _data_ with point pt n lc rgb _point_color_ > > I have no plans to do any more work on the gnuplot backend myself, but > would consider a patch that uses this method. > > Thanks, > > jwe > > What about something like the attached.. It respects both the MarkerEdgeColor and MarkerFaceColor properties.. It probably has a bit of redundant output to gnuplot for surface (for linestyles that aren't used or are rewritten), but it seems to work correctly for lines.. In particular h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', 'MarkerFaceColor', 'r'); drawnow; h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'auto', 'MarkerFaceColor', 'r'); drawnow; h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'none', 'MarkerFaceColor', 'r'); drawnow; h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', 'MarkerFaceColor', 'auto'); drawnow; h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', 'MarkerFaceColor', 'none'); drawnow; h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', 'MarkerFaceColor', 'r'); drawnow; h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'auto', 'MarkerFaceColor', 'r'); drawnow; h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'none', 'MarkerFaceColor', 'r'); drawnow; h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', 'MarkerFaceColor', 'auto'); drawnow; h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', 'MarkerFaceColor', 'none'); drawnow; all seem to work correctly.. If you want me to commit this patch I'll tidy it up a bit and commit it.. Note that I changed some of the marker types, as the marker '<', '>' and 'p' really don't exist in gnuplot and they were being faked with one of the filled markers previously. I replaced these with close existing marker types (ie '>' with '^') David -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091005/b1af7c53/attachment.ksh From dbateman at dbateman.org Sun Oct 4 19:31:41 2009 From: dbateman at dbateman.org (David Bateman) Date: Mon, 05 Oct 2009 02:31:41 +0200 Subject: patch and axes proterties In-Reply-To: <57801.81.0.203.147.1254696622.squirrel@webmail.fsv.cvut.cz> References: <57801.81.0.203.147.1254696622.squirrel@webmail.fsv.cvut.cz> Message-ID: <4AC93E6D.5030908@dbateman.org> Ing. Tom?? Kub?n Ph.D. wrote: > Bug report for Octave 3.0.1 configured for i486-pc-linux-gnu > > Description: > ----------- > > The following code draws ellipses and pathces on the diferrent position. > The function patch do not work correctly witch axes special settings. > > set(gca, 'XAxisLocation', 'top', > 'YAxisLocation', 'right', > 'XDir', 'reverse', > 'YDir', 'reverse'); > > phi = linspace(0,2*pi,20); > x = cos(phi); > y = 2*sin(phi); > > hold on; > > patch(x, y, 'FaceColor', 'red') > patch(x+2, y+5, 'FaceColor', 'green') > > plot(x, y, 'Color', 'red', 'linewidth', 3) > plot(x+2, y+5, 'Color', 'green', 'linewidth', 3) > > The graphics code has undergone massive changes after the version you are using.. The test case you gave works correctly in 3.3.50+ and I presume in the 3.2.x series.. I can however duplicate the problem in 3.0.5. I don't think there will be a backport of the fix to 3.0.x series as the fix is problem not easily extracted from feature additions to 3.2.x and in any case I don't think there will every be another 3.0.x release.. Can I suggest you upgrade to 3.2.x Cheers David From jwe at octave.org Sun Oct 4 19:31:15 2009 From: jwe at octave.org (John W. Eaton) Date: Sun, 4 Oct 2009 20:31:15 -0400 Subject: Plot Bug: 'markerfacecolor' does not work In-Reply-To: <4AC93C1B.1090800@dbateman.org> References: <4AB8EAD3.9070805@chalmers.se> <4AB924F7.8060104@dbateman.org> <4AB92AE1.7030806@dbateman.org> <19137.8142.214670.828607@segfault.lan> <4AC93C1B.1090800@dbateman.org> Message-ID: <19145.15955.163378.380033@segfault.lan> On 5-Oct-2009, David Bateman wrote: | John W. Eaton wrote: | > On 23-Sep-2009, Petr Mikulik wrote: | > | > | > > > 'markerfacecolor' does not work e.g. in the following plot-command: | > | > > > plot(x, y, 'bo', 'markerfacecolor', 'r'); | > | > > > The data points are still blue, but should be red. | > | > > | > | > > At the moment the gnuplot backend uses a single plot command for each line | > | > > to gnuplot.. Gnuplot doesn't specify the line and point colour separately so | > | > > as you found the markerfacecolor property is not respected.. We could quite | > | > > easily modify the gnuplot backend code to use two separate gnuplot lines for | > | > > each line to get the desired effect... | > | > > | > | > I have no desire (or time) to fully test the attached patch, but something | > | > like this should give the behavior you want.. Does someone want to test this | > | > patch further and maybe commit it? | > | | > | This patch changes colour of symbols to red instead of just "filling" it | > | with red. | > | | > | Two plot commands are really necessary: if "markerfacecolor" is set and | > | gnuplot point type is n=4,6,8,10,12 (diamonds, circles, triangles, ...), | > | then: | > | plot _data_ with point pt n+1 lc rgb _markerfacecolor_, \ | > | _data_ with point pt n lc rgb _point_color_ | > | > I have no plans to do any more work on the gnuplot backend myself, but | > would consider a patch that uses this method. | > | > Thanks, | > | > jwe | > | > | What about something like the attached.. It respects both the | MarkerEdgeColor and MarkerFaceColor properties.. It probably has a bit | of redundant output to gnuplot for surface (for linestyles that aren't | used or are rewritten), but it seems to work correctly for lines.. In | particular | | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', | 'MarkerFaceColor', 'r'); drawnow; | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'auto', | 'MarkerFaceColor', 'r'); drawnow; | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'none', | 'MarkerFaceColor', 'r'); drawnow; | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', | 'MarkerFaceColor', 'auto'); drawnow; | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', | 'MarkerFaceColor', 'none'); drawnow; | | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', | 'MarkerFaceColor', 'r'); drawnow; | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'auto', | 'MarkerFaceColor', 'r'); drawnow; | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'none', | 'MarkerFaceColor', 'r'); drawnow; | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', | 'MarkerFaceColor', 'auto'); drawnow; | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', | 'MarkerFaceColor', 'none'); drawnow; | | all seem to work correctly.. If you want me to commit this patch I'll | tidy it up a bit and commit it.. Note that I changed some of the marker | types, as the marker '<', '>' and 'p' really don't exist in gnuplot and | they were being faked with one of the filled markers previously. I | replaced these with close existing marker types (ie '>' with '^') If it works, then yes, please commit it. Thanks, jwe From jwe at octave.org Sun Oct 4 23:12:52 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 5 Oct 2009 00:12:52 -0400 Subject: bug in squeeze for chars? In-Reply-To: <69d8d540910040112w34df0db9n25370499d585e960@mail.gmail.com> References: <4AC6DB07.4020000@earthlink.net> <6A9668E2-F47C-4968-B31B-BFF5E7AA8C4B@mac.com> <4AC81526.4030908@earthlink.net> <19144.11644.565903.33028@segfault.lan> <69d8d540910040112w34df0db9n25370499d585e960@mail.gmail.com> Message-ID: <19145.29252.419992.386432@segfault.lan> On 4-Oct-2009, Jaroslav Hajek wrote: | What use is the is_string argument to octave_value::octave_value | (const charNDArray&, bool is_str,...)? | If is_str is false, it constructs an instance of octave_char_matrix | ... that can't be properly printed, ischar() doesn't recognize it... | is it actually used for any purpose? I think it was originally intended to be a way to express char-size numeric values. But I don't think we need that now that we have int8. How about the following patch? http://hg.savannah.gnu.org/hgweb/octave/rev/34d6f005db4b In addition to providing the new constructors octave_value (const charMatrix& chm, char type = '"'); octave_value (const charNDArray& chnda, char type = '"'); octave_value (const ArrayN& chnda, char type = '"'); I left the old versions octave_value (const charMatrix& chm, bool is_string, char type = '"') GCC_ATTR_DEPRECATED; octave_value (const charNDArray& chnda, bool is_string, char type = '"') GCC_ATTR_DEPRECATED; octave_value (const ArrayN& chnda, bool is_string, char type = '"') GCC_ATTR_DEPRECATED; but modified them so that the is_string argument is ignored (always assumed true) and also marked them as deprecated. Normally, I would favor removing these functions and telling people to update any code that depends on the old signature. But instead of getting an error for a call with octave_value (charNDArray, bool, char) the following constructor will be used instead octave_value (const Array& inda, bool zero_based = false, bool cache_index = false); This happens because we have various type conversion constructors in place that can convert Array object of one type to another. I started to try to fix that by adding "explicit" qualifiers to the templated type conversion constructors in the Array classes, but that quickly became mess, so it seems better to leave the constructors in place an mark them as deprecated rather than allow confusing and subtle errors to happen without warning. I also changed the default to single quoted strings rather than double quoted because that makes the most sense for compatibility. Comments? jwe From highegg at gmail.com Mon Oct 5 00:55:37 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 5 Oct 2009 07:55:37 +0200 Subject: empty matrix not treated as cell array when indexed with {} if a structure-field in entry is assigned to In-Reply-To: <20091001100018.GA4375@olaf> References: <20091001100018.GA4375@olaf> Message-ID: <69d8d540910042255u517a3b31m55577769bff7c81f@mail.gmail.com> On Thu, Oct 1, 2009 at 12:00 PM, Olaf Till wrote: > Hi, > > Octave version: 3.2.2 > > this works: > > octave:1> a = []; > octave:2> a{1} = 1; > > but this not: > > octave:3> a = []; > octave:4> a{1}.b = 1; > error: matrix cannot be indexed with { > > Is that also the case in Octave 3.2.3? > > Olaf Probably not. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Mon Oct 5 08:50:31 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 5 Oct 2009 15:50:31 +0200 Subject: bug in squeeze for chars? In-Reply-To: <19145.29252.419992.386432@segfault.lan> References: <4AC6DB07.4020000@earthlink.net> <6A9668E2-F47C-4968-B31B-BFF5E7AA8C4B@mac.com> <4AC81526.4030908@earthlink.net> <19144.11644.565903.33028@segfault.lan> <69d8d540910040112w34df0db9n25370499d585e960@mail.gmail.com> <19145.29252.419992.386432@segfault.lan> Message-ID: <69d8d540910050650k659c2980ofe0fd026aaa0655a@mail.gmail.com> On Mon, Oct 5, 2009 at 6:12 AM, John W. Eaton wrote: > On ?4-Oct-2009, Jaroslav Hajek wrote: > > | What use is the is_string argument to octave_value::octave_value > | (const charNDArray&, bool is_str,...)? > | If is_str is false, it constructs an instance of octave_char_matrix > | ... that can't be properly printed, ischar() doesn't recognize it... > | is it actually used for any purpose? > > I think it was originally intended to be a way to express char-size > numeric values. ?But I don't think we need that now that we have > int8. > > How about the following patch? > > ?http://hg.savannah.gnu.org/hgweb/octave/rev/34d6f005db4b > > In addition to providing the new constructors > > ?octave_value (const charMatrix& chm, ?char type = '"'); > ?octave_value (const charNDArray& chnda, char type = '"'); > ?octave_value (const ArrayN& chnda, char type = '"'); > > I left the old versions > > ?octave_value (const charMatrix& chm, bool is_string, > ? ? ? ? ? ? ? ?char type = '"') GCC_ATTR_DEPRECATED; > ?octave_value (const charNDArray& chnda, bool is_string, > ? ? ? ? ? ? ? ?char type = '"') GCC_ATTR_DEPRECATED; > ?octave_value (const ArrayN& chnda, bool is_string, > ? ? ? ? ? ? ? ?char type = '"') GCC_ATTR_DEPRECATED; > > but modified them so that the is_string argument is ignored (always > assumed true) and also marked them as deprecated. > > Normally, I would favor removing these functions and telling people to > update any code that depends on the old signature. ?But instead of > getting an error for a call with > > ?octave_value (charNDArray, bool, char) > > the following constructor will be used instead > > ?octave_value (const Array& inda, > ? ? ? ? ? ? ? ?bool zero_based = false, bool cache_index = false); > > This happens because we have various type conversion constructors in > place that can convert Array object of one type to another. ?I started > to try to fix that by adding "explicit" qualifiers to the templated > type conversion constructors in the Array classes, but that quickly > became mess, so it seems better to leave the constructors in place an > mark them as deprecated rather than allow confusing and subtle errors > to happen without warning. > > I also changed the default to single quoted strings rather than double > quoted because that makes the most sense for compatibility. > > Comments? > I supplemented it with http://hg.savannah.gnu.org/hgweb/octave/rev/f42f0d707e8e to avoid registering the internal (abstract) type. Otherwise, I think it looks OK now. regards -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From dbateman at dbateman.org Mon Oct 5 12:24:32 2009 From: dbateman at dbateman.org (David Bateman) Date: Mon, 05 Oct 2009 19:24:32 +0200 Subject: Plot Bug: 'markerfacecolor' does not work In-Reply-To: <19145.15955.163378.380033@segfault.lan> References: <4AB8EAD3.9070805@chalmers.se> <4AB924F7.8060104@dbateman.org> <4AB92AE1.7030806@dbateman.org> <19137.8142.214670.828607@segfault.lan> <4AC93C1B.1090800@dbateman.org> <19145.15955.163378.380033@segfault.lan> Message-ID: <4ACA2BD0.1000802@dbateman.org> John W. Eaton wrote: > On 5-Oct-2009, David Bateman wrote: > > | John W. Eaton wrote: > | > On 23-Sep-2009, Petr Mikulik wrote: > | > > | > | > > > 'markerfacecolor' does not work e.g. in the following plot-command: > | > | > > > plot(x, y, 'bo', 'markerfacecolor', 'r'); > | > | > > > The data points are still blue, but should be red. > | > | > > > | > | > > At the moment the gnuplot backend uses a single plot command for each line > | > | > > to gnuplot.. Gnuplot doesn't specify the line and point colour separately so > | > | > > as you found the markerfacecolor property is not respected.. We could quite > | > | > > easily modify the gnuplot backend code to use two separate gnuplot lines for > | > | > > each line to get the desired effect... > | > | > > > | > | > I have no desire (or time) to fully test the attached patch, but something > | > | > like this should give the behavior you want.. Does someone want to test this > | > | > patch further and maybe commit it? > | > | > | > | This patch changes colour of symbols to red instead of just "filling" it > | > | with red. > | > | > | > | Two plot commands are really necessary: if "markerfacecolor" is set and > | > | gnuplot point type is n=4,6,8,10,12 (diamonds, circles, triangles, ...), > | > | then: > | > | plot _data_ with point pt n+1 lc rgb _markerfacecolor_, \ > | > | _data_ with point pt n lc rgb _point_color_ > | > > | > I have no plans to do any more work on the gnuplot backend myself, but > | > would consider a patch that uses this method. > | > > | > Thanks, > | > > | > jwe > | > > | > > | What about something like the attached.. It respects both the > | MarkerEdgeColor and MarkerFaceColor properties.. It probably has a bit > | of redundant output to gnuplot for surface (for linestyles that aren't > | used or are rewritten), but it seems to work correctly for lines.. In > | particular > | > | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', > | 'MarkerFaceColor', 'r'); drawnow; > | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'auto', > | 'MarkerFaceColor', 'r'); drawnow; > | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'none', > | 'MarkerFaceColor', 'r'); drawnow; > | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', > | 'MarkerFaceColor', 'auto'); drawnow; > | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', > | 'MarkerFaceColor', 'none'); drawnow; > | > | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', > | 'MarkerFaceColor', 'r'); drawnow; > | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'auto', > | 'MarkerFaceColor', 'r'); drawnow; > | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'none', > | 'MarkerFaceColor', 'r'); drawnow; > | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', > | 'MarkerFaceColor', 'auto'); drawnow; > | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', > | 'MarkerFaceColor', 'none'); drawnow; > | > | all seem to work correctly.. If you want me to commit this patch I'll > | tidy it up a bit and commit it.. Note that I changed some of the marker > | types, as the marker '<', '>' and 'p' really don't exist in gnuplot and > | they were being faked with one of the filled markers previously. I > | replaced these with close existing marker types (ie '>' with '^') > > If it works, then yes, please commit it. > > Thanks, > > jwe > > Before committing and to check that I got it right, could I ask someone what surf (peaks, 'Marker', 'o', 'MarkerEdgeColor', 'g', 'MarkerFaceColor', 'b') gives in Matlab? I'd basically like to see if matlab respects the marker colors David From kai.habel at gmx.de Mon Oct 5 13:21:39 2009 From: kai.habel at gmx.de (Kai Habel) Date: Mon, 05 Oct 2009 20:21:39 +0200 Subject: Plot Bug: 'markerfacecolor' does not work In-Reply-To: <4ACA2BD0.1000802@dbateman.org> References: <4AB8EAD3.9070805@chalmers.se> <4AB924F7.8060104@dbateman.org> <4AB92AE1.7030806@dbateman.org> <19137.8142.214670.828607@segfault.lan> <4AC93C1B.1090800@dbateman.org> <19145.15955.163378.380033@segfault.lan> <4ACA2BD0.1000802@dbateman.org> Message-ID: <4ACA3933.4060205@gmx.de> David Bateman schrieb: > John W. Eaton wrote: > >> On 5-Oct-2009, David Bateman wrote: >> >> | John W. Eaton wrote: >> | > On 23-Sep-2009, Petr Mikulik wrote: >> | > >> | > | > > > 'markerfacecolor' does not work e.g. in the following plot-command: >> | > | > > > plot(x, y, 'bo', 'markerfacecolor', 'r'); >> | > | > > > The data points are still blue, but should be red. >> | > | > > >> | > | > > At the moment the gnuplot backend uses a single plot command for each line >> | > | > > to gnuplot.. Gnuplot doesn't specify the line and point colour separately so >> | > | > > as you found the markerfacecolor property is not respected.. We could quite >> | > | > > easily modify the gnuplot backend code to use two separate gnuplot lines for >> | > | > > each line to get the desired effect... >> | > | > > >> | > | > I have no desire (or time) to fully test the attached patch, but something >> | > | > like this should give the behavior you want.. Does someone want to test this >> | > | > patch further and maybe commit it? >> | > | >> | > | This patch changes colour of symbols to red instead of just "filling" it >> | > | with red. >> | > | >> | > | Two plot commands are really necessary: if "markerfacecolor" is set and >> | > | gnuplot point type is n=4,6,8,10,12 (diamonds, circles, triangles, ...), >> | > | then: >> | > | plot _data_ with point pt n+1 lc rgb _markerfacecolor_, \ >> | > | _data_ with point pt n lc rgb _point_color_ >> | > >> | > I have no plans to do any more work on the gnuplot backend myself, but >> | > would consider a patch that uses this method. >> | > >> | > Thanks, >> | > >> | > jwe >> | > >> | > >> | What about something like the attached.. It respects both the >> | MarkerEdgeColor and MarkerFaceColor properties.. It probably has a bit >> | of redundant output to gnuplot for surface (for linestyles that aren't >> | used or are rewritten), but it seems to work correctly for lines.. In >> | particular >> | >> | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', >> | 'MarkerFaceColor', 'r'); drawnow; >> | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'auto', >> | 'MarkerFaceColor', 'r'); drawnow; >> | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'none', >> | 'MarkerFaceColor', 'r'); drawnow; >> | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', >> | 'MarkerFaceColor', 'auto'); drawnow; >> | h = plot (1:10, 'bo-', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', >> | 'MarkerFaceColor', 'none'); drawnow; >> | >> | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', >> | 'MarkerFaceColor', 'r'); drawnow; >> | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'auto', >> | 'MarkerFaceColor', 'r'); drawnow; >> | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'none', >> | 'MarkerFaceColor', 'r'); drawnow; >> | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', >> | 'MarkerFaceColor', 'auto'); drawnow; >> | h = plot (1:10, 'bo', 'MarkerSize', 10, 'MarkerEdgeColor', 'g', >> | 'MarkerFaceColor', 'none'); drawnow; >> | >> | all seem to work correctly.. If you want me to commit this patch I'll >> | tidy it up a bit and commit it.. Note that I changed some of the marker >> | types, as the marker '<', '>' and 'p' really don't exist in gnuplot and >> | they were being faked with one of the filled markers previously. I >> | replaced these with close existing marker types (ie '>' with '^') >> >> If it works, then yes, please commit it. >> >> Thanks, >> >> jwe >> >> >> > Before committing and to check that I got it right, could I ask someone what > > surf (peaks, 'Marker', 'o', 'MarkerEdgeColor', 'g', 'MarkerFaceColor', 'b') > > gives in Matlab? I'd basically like to see if matlab respects the marker > colors > > David > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > It seems matlab respects these properties in a surface plot. (graphic sent via PM) Kai From highegg at gmail.com Tue Oct 6 01:48:15 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 6 Oct 2009 08:48:15 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <1254227866.5541.26.camel@boulder> References: <1254127649.10433.2.camel@boulder> <1254128713.10433.8.camel@boulder> <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com> <1254223027.5541.15.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> Message-ID: <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> On Tue, Sep 29, 2009 at 2:37 PM, Cyrus Hall wrote: > On Tue, 2009-09-29 at 13:53 +0200, Jaroslav Hajek wrote: >> I see nothing suspicious. If you have valgrind installed, please try >> >> octave:1> ?A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i]; >> octave:2> ?[v, d] = eig (A, B); >> >> with ./run-octave -valgrind >> >> and post all messages that appear *after* the initial prompt. This can >> discover whether you're having an invalid memory access. >> >> hth > > Wow, the number of jumps that depend on uninitialized values in LAPACK > is concerning. ?The output was so large that I've uploaded it: > > http://www.inf.unisi.ch/phd/hall/octave-3.2.3-valgrind > > Note that the input is not listed in the dump as it was piped to octave > via redirection. ?The script consists of your two suggested lines: > > A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i]; > [v, d] = eig (A, B); > > All of the output after the octave prints the header comes after the > second line in the script is executed. > > Cheers, > Cyrus > > Sorry for the late reply. Unfortunately, I'm out of ideas. I suggest you try with a different BLAS and LAPACK to see if the problem persists. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From cardoso at enst.fr Tue Oct 6 05:11:34 2009 From: cardoso at enst.fr (Jean-Francois Cardoso) Date: Tue, 6 Oct 2009 03:11:34 -0700 (PDT) Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> References: <1254127649.10433.2.camel@boulder> <1254128713.10433.8.camel@boulder> <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com> <1254223027.5541.15.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> Message-ID: <25765985.post@talk.nabble.com> Jaroslav Hajek-2 wrote: > > Sorry for the late reply. Unfortunately, I'm out of ideas. I suggest > you try with a different BLAS and LAPACK to see if the problem > persists. > I had similar problems. I just discovered that they were due to a miscompiled atlas package for SSE2 in Ubuntu repositories. I fixed the issue by replacing the atlas/sse2 packages by generic atlas packages. This seems to be a known issue: https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/406520 https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/363510 Cheers, JF -- View this message in context: http://www.nabble.com/Octave-3.2.2-3.2.3-failures-of-eig-eigs-during-make-check-tp25642455p25765985.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From g.l.ingram at durham.ac.uk Tue Oct 6 07:08:24 2009 From: g.l.ingram at durham.ac.uk (Grant Ingram) Date: Tue, 06 Oct 2009 13:08:24 +0100 Subject: griddata fails with same size interpolation vectors Message-ID: <4ACB3338.7070603@durham.ac.uk> Dear Bugs, On Fri Oct 2 00:28:06 CDT 2009, Jaroslav Hajek wrote: > I checked in a different fix, which should be more Matlab compatible: > http://hg.savannah.gnu.org/hgweb/octave/rev/8cf522ce9c4d > > in any case, as you noted, the OP's script will still fail at "mesh". Thanks for that! Note that if use the griddata.m file linked above I need to transpose the yi vector to get it to work. rand("state",1); x=2*rand(100,1)-1; y=2*rand(size(x))-1; z=sin(2*(x.^2+y.^2)); xi = linspace(-1,1,10); yi = linspace(-1,1,10); [XI,YI,ZI] = griddata(x,y,z,xi,yi,"linear"); mesh(XI,YI,ZI); print("griddata_check.eps","-depsc2"); Gives: error: surface: rows (z) must be the same as length (y) and columns (z) must be the same as length (x) Adding yi = yi(:); as follows makes the whole thing work: rand("state",1); x=2*rand(100,1)-1; y=2*rand(size(x))-1; z=sin(2*(x.^2+y.^2)); xi = linspace(-1,1,10); yi = linspace(-1,1,10); yi = yi(:); [XI,YI,ZI] = griddata(x,y,z,xi,yi,"linear"); mesh(XI,YI,ZI); print("griddata_check.eps","-depsc2"); I'm not sure if that is the behaviour that you want. All best wishes, Grant -- Grant Ingram School of Engineering and Computing Sciences Durham University g.l.ingram at durham.ac.uk +44 (0)191 3342428 From g.l.ingram at durham.ac.uk Tue Oct 6 07:14:37 2009 From: g.l.ingram at durham.ac.uk (Grant Ingram) Date: Tue, 06 Oct 2009 13:14:37 +0100 Subject: Typos in Geometry Section of the Manual? Message-ID: <4ACB34AD.80800@durham.ac.uk> Dear Bugs, In octave-3.2.3/doc/interpreter/geometry.texi I think there are a couple of typos. Suggested corrections below. --- geometry.texi 2009-09-29 18:40:12.617707131 +0100 +++ geometry_gli.texi 2009-10-06 12:33:36.179974824 +0100 @@ -690,11 +690,11 @@ @c ./geometry/griddata3.m @anchor{doc-griddata3} - at deftypefn {Function File} {@var{vi} =} griddata3 (@var{x}, @var{y}, @var{z}, @var{v} @var{xi}, @var{yi}, @var{zi}, @var{method}, @var{options}) + at deftypefn {Function File} {@var{vi} =} griddata3 (@var{x}, @var{y}, @var{z}, @var{v}, @var{xi}, @var{yi}, @var{zi}, @var{method}, @var{options}) -Generate a regular mesh from irregular data using interpolation. -The function is defined by @code{@var{y} = f (@var{x}, at var{y}, at var{z})}. -The interpolation points are all @var{xi}. +Generate a regular mesh from irregular data using interpolation. The +function is defined by @code{@var{v} = f (@var{x}, at var{y}, at var{z})}. +The interpolation points are all @code{@var{xi}, at var{yi}, at var{zi}}. The interpolation method can be @code{"nearest"} or @code{"linear"}. If method is omitted it defaults to @code{"linear"}. -- Grant Ingram School of Engineering and Computing Sciences Durham University g.l.ingram at durham.ac.uk +44 (0)191 3342428 From hallc at lu.unisi.ch Tue Oct 6 08:04:19 2009 From: hallc at lu.unisi.ch (Cyrus Hall) Date: Tue, 6 Oct 2009 15:04:19 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <25765985.post@talk.nabble.com> References: <1254127649.10433.2.camel@boulder> <1254128713.10433.8.camel@boulder> <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com> <1254223027.5541.15.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> Message-ID: <1254834259.6888.55.camel@boulder> I can confirm that removing the SEE2 optimized version fixed the problem and that all tests now pass. Thanks for pointing me toward the proper bug. This is a serious bug to have gone unfixed for nearly half a year! I wonder how many published papers contain useless results because of this. Scary. Has anyone thought about integrating a check for a broken atlas in configure? This is serious enough that it may be worth checking to assure the integrity of the final build. It would also prompt whoever maintains Octave for various distributions to assure they had packaged a fixed version of atlas. Cheers, Cyrus On Tue, 2009-10-06 at 12:11 +0200, Jean-Francois Cardoso wrote: > > > Jaroslav Hajek-2 wrote: > > > > Sorry for the late reply. Unfortunately, I'm out of ideas. I suggest > > you try with a different BLAS and LAPACK to see if the problem > > persists. > > > > I had similar problems. I just discovered that they were due to a > miscompiled > atlas package for SSE2 in Ubuntu repositories. > I fixed the issue by replacing the atlas/sse2 packages by generic atlas > packages. > > This seems to be a known issue: > https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/406520 > https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/363510 > > Cheers, JF > From highegg at gmail.com Tue Oct 6 08:08:13 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 6 Oct 2009 15:08:13 +0200 Subject: griddata fails with same size interpolation vectors In-Reply-To: <4ACB3338.7070603@durham.ac.uk> References: <4ACB3338.7070603@durham.ac.uk> Message-ID: <69d8d540910060608i665377c9k96c2a5b548ed8771@mail.gmail.com> On Tue, Oct 6, 2009 at 2:08 PM, Grant Ingram wrote: > Dear Bugs, > > On Fri Oct 2 00:28:06 CDT 2009, Jaroslav Hajek wrote: >> I checked in a different fix, which should be more Matlab compatible: >> http://hg.savannah.gnu.org/hgweb/octave/rev/8cf522ce9c4d >> >> in any case, as you noted, the OP's script will still fail at "mesh". > > Thanks for that! > > Note that if use the griddata.m file linked above I need to transpose > the yi vector to get it to work. > > rand("state",1); > x=2*rand(100,1)-1; > y=2*rand(size(x))-1; > z=sin(2*(x.^2+y.^2)); > xi = linspace(-1,1,10); > yi = linspace(-1,1,10); > [XI,YI,ZI] = griddata(x,y,z,xi,yi,"linear"); > mesh(XI,YI,ZI); > print("griddata_check.eps","-depsc2"); > > Gives: > > error: surface: rows (z) must be the same as length (y) and columns (z) > must be the same as length (x) > > Adding yi = yi(:); as follows makes the whole thing work: > > rand("state",1); > x=2*rand(100,1)-1; > y=2*rand(size(x))-1; > z=sin(2*(x.^2+y.^2)); > xi = linspace(-1,1,10); > yi = linspace(-1,1,10); > yi = yi(:); > [XI,YI,ZI] = griddata(x,y,z,xi,yi,"linear"); > mesh(XI,YI,ZI); > print("griddata_check.eps","-depsc2"); > > I'm not sure if that is the behaviour that you want. > > All best wishes, > > Grant I think so. Matlab's online docs say: "XI can be a row vector, in which case it specifies a matrix with constant columns. Similarly, YI can be a column vector, and it specifies a matrix with constant rows." -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Tue Oct 6 08:15:59 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 6 Oct 2009 15:15:59 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <1254834259.6888.55.camel@boulder> References: <1254127649.10433.2.camel@boulder> <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com> <1254223027.5541.15.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> Message-ID: <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> On Tue, Oct 6, 2009 at 3:04 PM, Cyrus Hall wrote: > I can confirm that removing the SEE2 optimized version fixed the problem > and that all tests now pass. ?Thanks for pointing me toward the proper > bug. > > This is a serious bug to have gone unfixed for nearly half a year! ?I > wonder how many published papers contain useless results because of > this. ?Scary. > > Has anyone thought about integrating a check for a broken atlas in > configure? ?This is serious enough that it may be worth checking to > assure the integrity of the final build. ?It would also prompt whoever > maintains Octave for various distributions to assure they had packaged a > fixed version of atlas. > > Cheers, > Cyrus > Since both BLAS and LAPACK test suites exist, I think it is fairly unnecessary. As you can see, the final Octave test suite can reveal such errors. Also, rebuilding Octave with generic BLAS/LAPACK is trivial. The main lesson for me (and maybe for you) is that broken ATLAS is not an uncommon source of problems. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From jwe at octave.org Tue Oct 6 08:16:09 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 6 Oct 2009 09:16:09 -0400 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <1254834259.6888.55.camel@boulder> References: <1254127649.10433.2.camel@boulder> <1254128713.10433.8.camel@boulder> <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com> <1254223027.5541.15.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> Message-ID: <19147.17177.769365.780601@segfault.lan> On 6-Oct-2009, Cyrus Hall wrote: | Has anyone thought about integrating a check for a broken atlas in | configure? What is the simplest reliable check? If the problem is the same as the one we discussed here recently: https://www-old.cae.wisc.edu/pipermail/help-octave/2009-August/015913.html (also follow the link to the other thread referenced in that message) then the problem is really that the machine constants like eps were calculated incorrectly. Previously, when this happend, Octave would just issue a warning. In the current sources, it is a fatal error. The patch I checked in is here: http://hg.savannah.gnu.org/hgweb/octave/rev/264fb5520973 If the bug is the same, then when you started your copy of Octave linked with the miscompiled ATLAS, did you get a warning about "unrecognized floating point format"? Did you ignore it? jwe From hallc at lu.unisi.ch Tue Oct 6 08:41:25 2009 From: hallc at lu.unisi.ch (Cyrus Hall) Date: Tue, 6 Oct 2009 15:41:25 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <19147.17177.769365.780601@segfault.lan> References: <1254127649.10433.2.camel@boulder> <1254128713.10433.8.camel@boulder> <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com> <1254223027.5541.15.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <19147.17177.769365.780601@segfault.lan> Message-ID: <1254836485.6888.60.camel@boulder> On Tue, 2009-10-06 at 15:16 +0200, John W. Eaton wrote: > On 6-Oct-2009, Cyrus Hall wrote: > > | Has anyone thought about integrating a check for a broken atlas in > | configure? > > What is the simplest reliable check? No idea. I frankly know nothing about these libraries as an end-user of octave and other mathematics platforms. That said, there does appear to be a simple test posted on the ubuntu bug reports that Jean-Francois linked to: https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/406520 > If the problem is the same as the one we discussed here recently: > > https://www-old.cae.wisc.edu/pipermail/help-octave/2009-August/015913.html > > (also follow the link to the other thread referenced in that message) > then the problem is really that the machine constants like eps were > calculated incorrectly. > > Previously, when this happend, Octave would just issue a warning. In > the current sources, it is a fatal error. The patch I checked in is > here: > > http://hg.savannah.gnu.org/hgweb/octave/rev/264fb5520973 > > If the bug is the same, then when you started your copy of Octave > linked with the miscompiled ATLAS, did you get a warning about > "unrecognized floating point format"? Did you ignore it? I did not get this warning. I believe my problem was related to the SSE2 optimization problem, as removing that package immediately fixed the issue. Cheers, Cyrus From jwe at octave.org Tue Oct 6 08:46:26 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 6 Oct 2009 09:46:26 -0400 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> References: <1254127649.10433.2.camel@boulder> <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com> <1254223027.5541.15.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> Message-ID: <19147.18994.389924.155498@segfault.lan> On 6-Oct-2009, Jaroslav Hajek wrote: | Since both BLAS and LAPACK test suites exist, I think it is fairly | unnecessary. I agree. I think it would be better to add or improve the tests for lapack/blas in the lapack/blas package itself. Or does Octave have to take on the role of testing for all the packages it depends on?n jwe From hallc at lu.unisi.ch Tue Oct 6 08:47:45 2009 From: hallc at lu.unisi.ch (Cyrus Hall) Date: Tue, 6 Oct 2009 15:47:45 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> References: <1254127649.10433.2.camel@boulder> <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com> <1254223027.5541.15.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> Message-ID: <1254836865.6888.67.camel@boulder> On Tue, 2009-10-06 at 15:15 +0200, Jaroslav Hajek wrote: > Since both BLAS and LAPACK test suites exist, I think it is fairly > unnecessary. As you can see, the final Octave test suite can reveal > such errors. Also, rebuilding Octave with generic BLAS/LAPACK is > trivial. The main lesson for me (and maybe for you) is that broken > ATLAS is not an uncommon source of problems. While make check does a great job of finding the problem, it does not diagnose it, leaving the user unable to proceed. My hours of google searching and browsing through bug reports did not turn up the problem. As such, I would conclude figuring out what is wrong when one sees failures in eig, eigs, and an apparent infinite loop in the qr tests, is difficult at best. Since this particular problem seems to be fairly easy to find (see my reply to John), it might be worth the effort. Cheers, Cyrus From highegg at gmail.com Tue Oct 6 09:03:40 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 6 Oct 2009 16:03:40 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <1254836865.6888.67.camel@boulder> References: <1254127649.10433.2.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> Message-ID: <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> On Tue, Oct 6, 2009 at 3:47 PM, Cyrus Hall wrote: > On Tue, 2009-10-06 at 15:15 +0200, Jaroslav Hajek wrote: >> Since both BLAS and LAPACK test suites exist, I think it is fairly >> unnecessary. As you can see, the final Octave test suite can reveal >> such errors. Also, rebuilding Octave with generic BLAS/LAPACK is >> trivial. The main lesson for me (and maybe for you) is that broken >> ATLAS is not an uncommon source of problems. > > While make check does a great job of finding the problem, it does not > diagnose it, leaving the user unable to proceed. > Yeah, it would be really marvelous if software always told you how to proceed when you run into problems. Just like Star Trek. > > My hours of google searching and browsing through bug reports did not > turn up the problem. Maybe you were the first to observe it, or others did but did not leave footprints. > As such, I would conclude figuring out what is > wrong when one sees failures in eig, eigs, and an apparent infinite loop > in the qr tests, is difficult at best. I would not quite say so. Next time, I will suggest replacing ATLAS as the first attempt when facing this kind of problem. > ?Since this particular problem > seems to be fairly easy to find (see my reply to John), it might be > worth the effort. If you really think it is worth your effort - I do not object to a basic configure test for working BLAS. Just remember that configure tests should be reasonably fast and not much memory consuming. regards -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Tue Oct 6 09:11:40 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 6 Oct 2009 16:11:40 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <19147.18994.389924.155498@segfault.lan> References: <1254127649.10433.2.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <19147.18994.389924.155498@segfault.lan> Message-ID: <69d8d540910060711s27f3281erf679fc124d885a86@mail.gmail.com> On Tue, Oct 6, 2009 at 3:46 PM, John W. Eaton wrote: > On ?6-Oct-2009, Jaroslav Hajek wrote: > > | Since both BLAS and LAPACK test suites exist, I think it is fairly > | unnecessary. > > I agree. ?I think it would be better to add or improve the tests for > lapack/blas in the lapack/blas package itself. ?Or does Octave have to > take on the role of testing for all the packages it depends on?n > > jwe > As a side note, Octave in fact *does* make a fairly good testbed, both for the dependent libraries and compilers used. It's just we of course can't test everything in the configure script. Thinking about this, however, maybe it would be nice if there was some information about what relevant libraries might be broken if a function is not working, such as linear algebra -> BLAS, LAPACK sparse algebra -> SuiteSparse eigs, svds -> ARPACK convhull, delaunay,... -> Qhull qrupdate,cholupdate,.. -> qrupdate regexp -> pcre etc. of course, one can always ask on the list, which is a good idea anyway... -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From hallc at lu.unisi.ch Tue Oct 6 09:26:57 2009 From: hallc at lu.unisi.ch (Cyrus Hall) Date: Tue, 6 Oct 2009 16:26:57 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> References: <1254127649.10433.2.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> Message-ID: <1254839217.6888.89.camel@boulder> On Tue, 2009-10-06 at 16:03 +0200, Jaroslav Hajek wrote: > On Tue, Oct 6, 2009 at 3:47 PM, Cyrus Hall wrote: > > On Tue, 2009-10-06 at 15:15 +0200, Jaroslav Hajek wrote: > >> Since both BLAS and LAPACK test suites exist, I think it is fairly > >> unnecessary. As you can see, the final Octave test suite can reveal > >> such errors. Also, rebuilding Octave with generic BLAS/LAPACK is > >> trivial. The main lesson for me (and maybe for you) is that broken > >> ATLAS is not an uncommon source of problems. > > > > While make check does a great job of finding the problem, it does not > > diagnose it, leaving the user unable to proceed. > > > > Yeah, it would be really marvelous if software always told you how to > proceed when you run into problems. Just like Star Trek. I don't really appreciate this response. I was arguing that it might be important to make sure Octave is built such that it produces accurate results. You respond by insinuating that I'm just lazy. Not a great way to recruit people to help. Maybe I'm taking this a little too seriously, but it seems like this would be a common configuration problem under builds of octave on 32-bit Ubuntu. As a researcher, that deeply concerns me, as I know many of my colleagues both work on that platform and are less careful about checking for problems in the software they use. A warning on the download page would at least be a step in the right direction. That said, I do understand being reluctant to check for what amounts to someone else's bug, which will ideally be fixed sooner than later. As such, I will try and push on the Ubuntu side. They have been packaging atlas 3.6.0 for four releases now, a version which is now five years out of date. Time to get them to move forward. Cheers, Cyrus From jwe at octave.org Tue Oct 6 10:18:44 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 6 Oct 2009 11:18:44 -0400 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <1254839217.6888.89.camel@boulder> References: <1254127649.10433.2.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> <1254839217.6888.89.camel@boulder> Message-ID: <19147.24532.187977.39678@segfault.lan> On 6-Oct-2009, Cyrus Hall wrote: | Maybe I'm taking this a little too seriously, but it seems like this | would be a common configuration problem under builds of octave on 32-bit | Ubuntu. As a researcher, that deeply concerns me, as I know many of my | colleagues both work on that platform and are less careful about | checking for problems in the software they use. A warning on the | download page would at least be a step in the right direction. It would be great to have someone actively maintaining the web pages... jwe From rishiamrit at gmail.com Tue Oct 6 11:30:29 2009 From: rishiamrit at gmail.com (Rishi Amrit) Date: Tue, 6 Oct 2009 11:30:29 -0500 Subject: keyboard in octave 3.2.3 Message-ID: Hi, I have a keyboard statement inside a function which I am calling from my main script. WhenOctave stops in the debug mode, I dont see the variables in the scope of that function. I only see the variables in the out main script. Eg: contents of main.m: a=1; b=2; fun2; contents of fun2.m: function fun2 c=1; d=2; keyboard Now when I run, octave> main keyboard: stopped in fun2.m octave> who a ans b Instead I should be seeing c and d, and not a and b Thanks, Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091006/eb53cf20/attachment.html From highegg at gmail.com Tue Oct 6 11:33:21 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 6 Oct 2009 18:33:21 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <1254839217.6888.89.camel@boulder> References: <1254127649.10433.2.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> <1254839217.6888.89.camel@boulder> Message-ID: <69d8d540910060933m6e243d82sdec31b5e615d244f@mail.gmail.com> On Tue, Oct 6, 2009 at 4:26 PM, Cyrus Hall wrote: > On Tue, 2009-10-06 at 16:03 +0200, Jaroslav Hajek wrote: >> On Tue, Oct 6, 2009 at 3:47 PM, Cyrus Hall wrote: >> > On Tue, 2009-10-06 at 15:15 +0200, Jaroslav Hajek wrote: >> >> Since both BLAS and LAPACK test suites exist, I think it is fairly >> >> unnecessary. As you can see, the final Octave test suite can reveal >> >> such errors. Also, rebuilding Octave with generic BLAS/LAPACK is >> >> trivial. The main lesson for me (and maybe for you) is that broken >> >> ATLAS is not an uncommon source of problems. >> > >> > While make check does a great job of finding the problem, it does not >> > diagnose it, leaving the user unable to proceed. >> > >> >> Yeah, it would be really marvelous if software always told you how to >> proceed when you run into problems. Just like Star Trek. > > I don't really appreciate this response. ?I was arguing that it might be > important to make sure Octave is built such that it produces accurate > results. ?You respond by insinuating that I'm just lazy. ?Not a great > way to recruit people to help. > Sorry, that was just a joke. I was entertained by your implication "Octave does not diagnose its bug" --> "user is enable to proceed". Clearly you *were* able to proceed - point for you. Obviously you are not lazy. > Maybe I'm taking this a little too seriously, but it seems like this > would be a common configuration problem under builds of octave on 32-bit > Ubuntu. ?As a researcher, that deeply concerns me, as I know many of my > colleagues both work on that platform and are less careful about > checking for problems in the software they use. ?A warning on the > download page would at least be a step in the right direction. > They're lucky you're their colleague, then :) Even common problems need to be discovered first. I build Octave on Ubuntu too, but haven't encountered this, because I use a non-free BLAS library. Shame on me :) But surely, if you want to add the info somewhere, either on Octave wiki or the Octave web page, proposals are welcome. > That said, I do understand being reluctant to check for what amounts to > someone else's bug, which will ideally be fixed sooner than later. ?As > such, I will try and push on the Ubuntu side. ?They have been packaging > atlas 3.6.0 for four releases now, a version which is now five years out > of date. ?Time to get them to move forward. > As I said, Octave is itself a good sanity check for its libraries, which was also demonstrated by your case. What is maybe missing is a map broken Octave functions -> possibly broken external libraries. It's easy to get that information on the mailing list or from the sources, but maybe it could be even easier. I don't think it's reasonable to sanity-check everything in the configure script. Sometimes that would be even fairly difficult. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From hallc at lu.unisi.ch Tue Oct 6 11:52:33 2009 From: hallc at lu.unisi.ch (Cyrus Hall) Date: Tue, 6 Oct 2009 18:52:33 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <69d8d540910060933m6e243d82sdec31b5e615d244f@mail.gmail.com> References: <1254127649.10433.2.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> <1254839217.6888.89.camel@boulder> <69d8d540910060933m6e243d82sdec31b5e615d244f@mail.gmail.com> Message-ID: <1254847953.6888.123.camel@boulder> On Tue, 2009-10-06 at 18:33 +0200, Jaroslav Hajek wrote: > Sorry, that was just a joke. I was entertained by your implication > "Octave does not diagnose its bug" --> "user is enable to proceed". > Clearly you *were* able to proceed - point for you. Obviously you are > not lazy. No problem, I just misinterpreted it. Digital communication sucks for interpretation. I should have read it more carefully. > But surely, if you want to add the info > somewhere, either on Octave wiki or the Octave web page, proposals are > welcome. I hadn't thought of the wiki; good idea. I'd be happy to edit it if someone could send me a password. > As I said, Octave is itself a good sanity check for its libraries, > which was also demonstrated by your case. What is maybe missing is a > map broken Octave functions -> possibly broken external libraries. > It's easy to get that information on the mailing list or from the > sources, but maybe it could be even easier. I don't think it's > reasonable to sanity-check everything in the configure script. > Sometimes that would be even fairly difficult. I understand this point of view. I'll continue to follow up on this with the Ubuntu developers and put some notes up on the wiki when possible. Thanks for your help, Cyrus From jwe at octave.org Tue Oct 6 12:24:02 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 6 Oct 2009 13:24:02 -0400 Subject: keyboard in octave 3.2.3 In-Reply-To: References: Message-ID: <19147.32050.91238.456309@segfault.lan> On 6-Oct-2009, Rishi Amrit wrote: | I have a keyboard statement inside a function which I am calling from my | main script. WhenOctave stops in the debug mode, I dont see the variables in | the scope of that function. I only see the variables in the out main script. | Eg: | | contents of main.m: | | a=1; b=2; | fun2; | | | contents of fun2.m: | | function fun2 | c=1; d=2; | keyboard | | | | Now when I run, | | octave> main | keyboard: stopped in fun2.m | octave> who | a ans b | | | Instead I should be seeing c and d, and not a and b Here is what I see with the current development sources (I added another call to keyboard at the end of your main function): segfault:822> ./run-octave GNU Octave, version 3.3.50+ Copyright (C) 2009 John W. Eaton and others. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. Octave was configured for "x86_64-unknown-linux-gnu". Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to (but first, please read http://www.octave.org/bugs.html to learn how to write a helpful report). For information about changes from previous versions, type `news'. octave:1> main stopped in /scratch/jwe/build/octave/fun2.m at line 3 3: keyboard debug> dbwhere /scratch/jwe/build/octave/fun2.m: line 3, column 1 3: keyboard debug> who Variables in the current scope: c d debug> c c = 1 debug> d d = 2 debug> dbcont stopped in /scratch/jwe/build/octave/main.m at line 3 3: keyboard debug> dbwhere /scratch/jwe/build/octave/main.m: line 3, column 1 3: keyboard debug> who Variables in the current scope: a ans b debug> a a = 1 debug> b b = 2 so it looks like this problem has already been fixed. See the following thread, which you started: http://www.nabble.com/local-variables-in-debugger-%3A-Octave-3.2.2-to24800796.html#a24800796 I think the first two patches could be applied to the 3.2.x branch. I'm not sure why they were not. It might not be possible to apply the third patch to the 3.2.x branch as it removes some variables from a class and changes at least one function signature, which might cause some binary compatibility problems. jwe From rishiamrit at gmail.com Tue Oct 6 12:30:35 2009 From: rishiamrit at gmail.com (Rishi Amrit) Date: Tue, 6 Oct 2009 12:30:35 -0500 Subject: keyboard in octave 3.2.3 In-Reply-To: <19147.32050.91238.456309@segfault.lan> References: <19147.32050.91238.456309@segfault.lan> Message-ID: On Tue, Oct 6, 2009 at 12:24 PM, John W. Eaton wrote: > On 6-Oct-2009, Rishi Amrit wrote: > > | I have a keyboard statement inside a function which I am calling from > my > | main script. WhenOctave stops in the debug mode, I dont see the variables > in > | the scope of that function. I only see the variables in the out main > script. > | Eg: > | > | contents of main.m: > | > | a=1; b=2; > | fun2; > | > | > | contents of fun2.m: > | > | function fun2 > | c=1; d=2; > | keyboard > | > | > | > | Now when I run, > | > | octave> main > | keyboard: stopped in fun2.m > | octave> who > | a ans b > | > | > | Instead I should be seeing c and d, and not a and b > > Here is what I see with the current development sources (I added > another call to keyboard at the end of your main function): > > segfault:822> ./run-octave > GNU Octave, version 3.3.50+ > Copyright (C) 2009 John W. Eaton and others. > This is free software; see the source code for copying conditions. > There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or > FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. > > Octave was configured for "x86_64-unknown-linux-gnu". > > Additional information about Octave is available at http://www.octave.org > . > > Please contribute if you find this software useful. > For more information, visit http://www.octave.org/help-wanted.html > > Report bugs to (but first, please read > http://www.octave.org/bugs.html to learn how to write a helpful report). > > For information about changes from previous versions, type `news'. > > octave:1> main > stopped in /scratch/jwe/build/octave/fun2.m at line 3 > 3: keyboard > debug> dbwhere > /scratch/jwe/build/octave/fun2.m: line 3, column 1 > 3: keyboard > debug> who > Variables in the current scope: > > c d > > debug> c > c = 1 > debug> d > d = 2 > debug> dbcont > stopped in /scratch/jwe/build/octave/main.m at line 3 > 3: keyboard > debug> dbwhere > /scratch/jwe/build/octave/main.m: line 3, column 1 > 3: keyboard > debug> who > Variables in the current scope: > > a ans b > > debug> a > a = 1 > debug> b > b = 2 > > > so it looks like this problem has already been fixed. > > See the following thread, which you started: > > > http://www.nabble.com/local-variables-in-debugger-%3A-Octave-3.2.2-to24800796.html#a24800796 > > I think the first two patches could be applied to the 3.2.x branch. > I'm not sure why they were not. It might not be possible to apply the > third patch to the 3.2.x branch as it removes some variables from a class > and changes at least one function signature, which might cause some > binary compatibility problems. > I have both the bleeding edge and 3.2.3 installed. It works fine in the bleeding edge as you point out above. But it does not work on 3.2.3 stable version. So there is a difference maybe because of the thrid patch ? Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091006/0aa7689a/attachment.html From jwe at octave.org Tue Oct 6 12:45:05 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 6 Oct 2009 13:45:05 -0400 Subject: keyboard in octave 3.2.3 In-Reply-To: References: <19147.32050.91238.456309@segfault.lan> Message-ID: <19147.33313.794895.876509@segfault.lan> On 6-Oct-2009, Rishi Amrit wrote: | I have both the bleeding edge and 3.2.3 installed. It works fine in the | bleeding edge as you point out above. But it does not work on 3.2.3 stable | version. So there is a difference maybe because of the thrid patch ? I don't think any of the three patches mentioned in the earlier thread were applied to the 3.2.x branch. But you can look for yourself. The 3.2.x archive is here: http://hg.tw-math.de/release-3-2-x jwe From thomas.weber.mail at gmail.com Tue Oct 6 12:52:31 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Tue, 6 Oct 2009 19:52:31 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <1254834259.6888.55.camel@boulder> References: <1254128713.10433.8.camel@boulder> <69d8d540909282218x5f85ffd8hac1bbde932328d8b@mail.gmail.com> <1254223027.5541.15.camel@boulder> <69d8d540909290421g2842edecr4465e649974ff18e@mail.gmail.com> <1254224604.5541.19.camel@boulder> <69d8d540909290453j37f531e3l91d19744ad5e5c1e@mail.gmail.com> <1254227866.5541.26.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> Message-ID: <20091006175231.GA8392@atlan> On Tue, Oct 06, 2009 at 03:04:19PM +0200, Cyrus Hall wrote: > I can confirm that removing the SEE2 optimized version fixed the problem > and that all tests now pass. Thanks for pointing me toward the proper > bug. > > This is a serious bug to have gone unfixed for nearly half a year! I > wonder how many published papers contain useless results because of > this. Scary. > > Has anyone thought about integrating a check for a broken atlas in > configure? This is serious enough that it may be worth checking to > assure the integrity of the final build. It would also prompt whoever > maintains Octave for various distributions to assure they had packaged a > fixed version of atlas. No, it wouldn't. Octave in Debian is built against the BLAS reference implementation. I suspect other distributions do the same: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1581875 Thomas (Debian packager) From highegg at gmail.com Tue Oct 6 14:25:09 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 6 Oct 2009 21:25:09 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <1254847953.6888.123.camel@boulder> References: <1254127649.10433.2.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> <1254839217.6888.89.camel@boulder> <69d8d540910060933m6e243d82sdec31b5e615d244f@mail.gmail.com> <1254847953.6888.123.camel@boulder> Message-ID: <69d8d540910061225y5344be2bgbb833f671277d448@mail.gmail.com> On Tue, Oct 6, 2009 at 6:52 PM, Cyrus Hall wrote: > On Tue, 2009-10-06 at 18:33 +0200, Jaroslav Hajek wrote: >> Sorry, that was just a joke. I was entertained by your implication >> "Octave does not diagnose its bug" --> "user is enable to proceed". >> Clearly you *were* able to proceed - point for you. Obviously you are >> not lazy. > > No problem, I just misinterpreted it. ?Digital communication sucks for > interpretation. ?I should have read it more carefully. > >> But surely, if you want to add the info >> somewhere, either on Octave wiki or the Octave web page, proposals are >> welcome. > > I hadn't thought of the wiki; good idea. ?I'd be happy to edit it if > someone could send me a password. > Send a request to octave-dev at lists.sourceforge.net (OctaveForge list) and Etienne will give you a password. To be able to edit Octave's web pages, which is done via CVS, you need to join Octave developers group on Savannah. Or just make a patch and post it. >> As I said, Octave is itself a good sanity check for its libraries, >> which was also demonstrated by your case. What is maybe missing is a >> map broken Octave functions -> possibly broken external libraries. >> It's easy to get that information on the mailing list or from the >> sources, but maybe it could be even easier. I don't think it's >> reasonable to sanity-check everything in the configure script. >> Sometimes that would be even fairly difficult. > > I understand this point of view. ?I'll continue to follow up on this > with the Ubuntu developers and put some notes up on the wiki when > possible. > > Thanks for your help, > Cyrus > > you're welcome. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From jwe at octave.org Tue Oct 6 14:28:52 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 6 Oct 2009 15:28:52 -0400 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <69d8d540910061225y5344be2bgbb833f671277d448@mail.gmail.com> References: <1254127649.10433.2.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> <1254839217.6888.89.camel@boulder> <69d8d540910060933m6e243d82sdec31b5e615d244f@mail.gmail.com> <1254847953.6888.123.camel@boulder> <69d8d540910061225y5344be2bgbb833f671277d448@mail.gmail.com> Message-ID: <19147.39540.209463.218911@segfault.lan> On 6-Oct-2009, Jaroslav Hajek wrote: | To be able to edit Octave's web | pages, which is done via CVS, you need to join Octave developers group | on Savannah. Or just make a patch and post it. Since the ultimate source for the web pages are text files that are processed with m4 to generate HTML, it is really more helpful to join the group and edit the ultimate source files directly rather than sending patches to the HTML files your browser sees. jwe From highegg at gmail.com Tue Oct 6 14:33:38 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 6 Oct 2009 21:33:38 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <19147.39540.209463.218911@segfault.lan> References: <1254127649.10433.2.camel@boulder> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> <1254839217.6888.89.camel@boulder> <69d8d540910060933m6e243d82sdec31b5e615d244f@mail.gmail.com> <1254847953.6888.123.camel@boulder> <69d8d540910061225y5344be2bgbb833f671277d448@mail.gmail.com> <19147.39540.209463.218911@segfault.lan> Message-ID: <69d8d540910061233n458ca294i85bff087d68851b3@mail.gmail.com> On Tue, Oct 6, 2009 at 9:28 PM, John W. Eaton wrote: > On ?6-Oct-2009, Jaroslav Hajek wrote: > > | To be able to edit Octave's web > | pages, which is done via CVS, you need to join Octave developers group > | on Savannah. Or just make a patch and post it. > > Since the ultimate source for the web pages are text files that are > processed with m4 to generate HTML, it is really more helpful to join > the group and edit the ultimate source files directly rather than > sending patches to the HTML files your browser sees. > I was thinking more along the line that you don't need to join the group; you can make an anonymous checkout and edit what you need; then post a patch. Of course, for more contributions, it's probably better to join. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From highegg at gmail.com Wed Oct 7 04:22:56 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 7 Oct 2009 11:22:56 +0200 Subject: Typos in Geometry Section of the Manual? In-Reply-To: <4ACB34AD.80800@durham.ac.uk> References: <4ACB34AD.80800@durham.ac.uk> Message-ID: <69d8d540910070222r71470e99xf418c81f1104198e@mail.gmail.com> On Tue, Oct 6, 2009 at 2:14 PM, Grant Ingram wrote: > Dear Bugs, > > In octave-3.2.3/doc/interpreter/geometry.texi I think there are a couple > of typos. ?Suggested corrections below. > > --- geometry.texi ? ? ? 2009-09-29 18:40:12.617707131 +0100 > +++ geometry_gli.texi ? 2009-10-06 12:33:36.179974824 +0100 > @@ -690,11 +690,11 @@ > > ?@c ./geometry/griddata3.m > ?@anchor{doc-griddata3} > - at deftypefn {Function File} {@var{vi} =} griddata3 (@var{x}, @var{y}, > @var{z}, @var{v} @var{xi}, @var{yi}, @var{zi}, @var{method}, @var{options}) > + at deftypefn {Function File} {@var{vi} =} griddata3 (@var{x}, @var{y}, > @var{z}, @var{v}, @var{xi}, @var{yi}, @var{zi}, @var{method}, @var{options}) > > -Generate a regular mesh from irregular data using interpolation. > -The function is defined by @code{@var{y} = f (@var{x}, at var{y}, at var{z})}. > -The interpolation points are all @var{xi}. > +Generate a regular mesh from irregular data using interpolation. ?The > +function is defined by @code{@var{v} = f (@var{x}, at var{y}, at var{z})}. > +The interpolation points are all @code{@var{xi}, at var{yi}, at var{zi}}. > > ?The interpolation method can be @code{"nearest"} or @code{"linear"}. > ?If method is omitted it defaults to @code{"linear"}. > > -- > Grant Ingram > School of Engineering and Computing Sciences > Durham University > g.l.ingram at durham.ac.uk +44 (0)191 3342428 The .texi sources are autogenerated intermediate files. If you want to correct the docstring of an m-function, you need to patch the m-function itself. Please do so and repost. hth -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From hallc at lu.unisi.ch Wed Oct 7 10:55:09 2009 From: hallc at lu.unisi.ch (Cyrus Hall) Date: Wed, 7 Oct 2009 17:55:09 +0200 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <19147.39540.209463.218911@segfault.lan> References: <1254127649.10433.2.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> <1254839217.6888.89.camel@boulder> <69d8d540910060933m6e243d82sdec31b5e615d244f@mail.gmail.com> <1254847953.6888.123.camel@boulder> <69d8d540910061225y5344be2bgbb833f671277d448@mail.gmail.com> <19147.39540.209463.218911@segfault.lan> Message-ID: <1254930909.6888.502.camel@boulder> I'd be happy to submit a patch to the m4 source for the web page. Where can I find it? The WWW directory in the Mercurial repo does not appear to contain them, nor could I find them elsewhere in the source tree. Cheers, Cyrus On Tue, 2009-10-06 at 21:28 +0200, John W. Eaton wrote: > On 6-Oct-2009, Jaroslav Hajek wrote: > > | To be able to edit Octave's web > | pages, which is done via CVS, you need to join Octave developers group > | on Savannah. Or just make a patch and post it. > > Since the ultimate source for the web pages are text files that are > processed with m4 to generate HTML, it is really more helpful to join > the group and edit the ultimate source files directly rather than > sending patches to the HTML files your browser sees. > > jwe From jwe at octave.org Wed Oct 7 11:39:38 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 7 Oct 2009 12:39:38 -0400 Subject: Octave 3.2.2/3.2.3 failures of eig/eigs during make check In-Reply-To: <1254930909.6888.502.camel@boulder> References: <1254127649.10433.2.camel@boulder> <69d8d540910052348j698d394fqe56ea30229963c9b@mail.gmail.com> <25765985.post@talk.nabble.com> <1254834259.6888.55.camel@boulder> <69d8d540910060615m4c9241bbu6ec59c0ed689c169@mail.gmail.com> <1254836865.6888.67.camel@boulder> <69d8d540910060703h4246396foc34c4f2e6da6bf9c@mail.gmail.com> <1254839217.6888.89.camel@boulder> <69d8d540910060933m6e243d82sdec31b5e615d244f@mail.gmail.com> <1254847953.6888.123.camel@boulder> <69d8d540910061225y5344be2bgbb833f671277d448@mail.gmail.com> <19147.39540.209463.218911@segfault.lan> <1254930909.6888.502.camel@boulder> Message-ID: <19148.50250.366821.127872@segfault.lan> On 7-Oct-2009, Cyrus Hall wrote: | I'd be happy to submit a patch to the m4 source for the web page. Where | can I find it? The WWW directory in the Mercurial repo does not appear | to contain them, nor could I find them elsewhere in the source tree. The source archive for the web pages is separate from the Octave sources. You can find them here: https://savannah.gnu.org/cvs/?group=octave jwe From marco.caliari at univr.it Fri Oct 9 08:56:40 2009 From: marco.caliari at univr.it (Marco Caliari) Date: Fri, 09 Oct 2009 15:56:40 +0200 (CEST) Subject: Legend label order Message-ID: Dear maintainers, it appears that the changeset http://hg.savannah.gnu.org/hgweb/octave/rev/350148cc0774 was not ported to 3.2.3 and the following x=linspace(0,10);,plot(x,x,x,x.^2),legend('linear') gives a wrong legend label. Best regards, Marco From putanowr at l5.pk.edu.pl Sat Oct 10 23:19:57 2009 From: putanowr at l5.pk.edu.pl (Roman Putanowicz) Date: Sun, 11 Oct 2009 06:19:57 +0200 Subject: Segmentation fault with keyboard() Message-ID: <20091011041957.GA17801@jinx.l5.pk.edu.pl> Bug report for Octave 3.2.3 configured for i686-pc-linux-gnu Description: ----------- Octave exits with segmentation fault when running the script containing keyboard() call: keyboard: stopped in ala.m panic: Segmentation fault -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete Segmentation fault By the way that script has worked in with vesion 3.0.5 Repeat-By: --------- This is the script that causes seg fault: keyboard() a = 23; b = sin(a) disp(b) Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux tomi 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux configure opts: '--prefix=/space/install/' Fortran compiler: gfortran FFLAGS: -O -mieee-fp FLIBS: -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.. -lz -lgfortranbegin -lgfortran -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.3 (Debian 4.3.3-3) CFLAGS: -g -O2 CPICFLAG: -fPIC C++ compiler: g++, version 4.3.3 CXXFLAGS: -g -O2 CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/space/install//lib/octave-3.2.3 BLAS_LIBS: -llapack -lcblas -lf77blas -latlas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /space/install//libexec/octave/3.2.3/site/exec/i686-pc-linux-gnu:/space/install//libexec/octave/api-v37/site/exec/i686-pc-linux-gnu:/space/install//libexec/octave/site/exec/i686-pc-linux-gnu:/space/install//libexec/octave/3.2.3/exec/i686-pc-linux-gnu:/space/install//bin:/home/putanowr/bin:/home/putanowr/install/bin:/space/install/bin:/space/install/salome/bin/salome:/home/putanowr/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:. IMAGE_PATH = .:/space/install//share/octave/3.2.3/imagelib PAGER = less PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /home/putanowr/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /space/install//share/info/octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From jwe at octave.org Sun Oct 11 15:33:54 2009 From: jwe at octave.org (John W. Eaton) Date: Sun, 11 Oct 2009 16:33:54 -0400 Subject: dead-octave-bug-1, octave-3.2.3 In-Reply-To: <200910011113.39063.dennisveatch@bellsouth.net> References: <200910011113.39063.dennisveatch@bellsouth.net> Message-ID: <19154.16690.967444.4559@hugo.lan> On 1-Oct-2009, Dennis Veatch wrote: | To: bug at octave.org | Cc: dveatch | Subject: [50 character or so descriptive subject here (for reference)] | -------- | Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu | | Description: | ----------- | | The compile proces goes fine; nor problem there. When I attempt to run it from a terminal, it | fails to run and throws this error; | octave: symbol lookup error: /usr/lib/octave-3.2.3/liboctave.so: undefined symbol: pthread_mutexattr_init | | This also happens with version 3.2.2. | | Repeat-By: | --------- | | The system is running gcc-4.4.1, glibc-2.10.1 and other needed friends. Prior to this it compiled and | ran fine. | | Fix: | --- | | Well, short of reverting my system back to the older versions of gcc/glibc, I don't know what the | fix should be. I think you may need to link with -lpthread. I recently added a check for pthread to Octave's configure script, so this should not be a problem in the next major release. I'm not sure whether it is worth applyhing the patch to the 3.2.x release branch. If you are interested in trying the change I checked in with 3.2.x, look for the following patch in the sources on savannah: changeset: 9488:ee572cdd4b97 user: John W. Eaton date: Wed Aug 05 13:27:58 2009 -0400 summary: add configure checks for pthread library and compiler flags Sorry, I can't give a direct URL for the changeset at the moment. jwe From dimitris.mpouzas at gmail.com Mon Oct 12 01:03:57 2009 From: dimitris.mpouzas at gmail.com (Dimitrios Bouzas) Date: Mon, 12 Oct 2009 09:03:57 +0300 Subject: Wrong results in cov(X,Y) when X and Y are complex valued vectors Message-ID: <4AD2C6CD.5010508@gmail.com> -------- Bug report for Octave 3.0.1 configured for i486-pc-linux-gnu Description: ----------- According to my opinion, it looks like that octave has a major flaw, when it comes to the calculation of the covariance of two complex valued vectors. In particular the problem appears in the case where the argument vectors differ in dimension (column vs row vector or vice versa). Due to probable efficiency reasons the author of Octave's cov() transposes the arguments if they are row vectors. The problem is that in Octave like in Matlab when transposing a complex valued matrix you don't get its algebraic transpose but instead its conjugate transpose. The above leads in calculating the covariance of the column vector argument with the conjugate transpose of the row vector argument. Considering that each argument vector is a collection of observations of a random variable the above according to my opinion is wrong. Repeat-By: --------- * Please replace this item with a description of the sequence of events that causes the problem to occur. Fix: --- Replace (') operator with (.') operator when transposing a row vector in cov(X,Y) code. Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux Aradis 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:49:34 UTC 2009 i686 GNU/Linux configure opts: '--host=i486-linux-gnu' '--build=i486-linux-gnu' '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3gf' '--with-lapack=-llapackgf-3' '--with-hdf5' '--with-fftw' '--enable-shared' '--enable-rpath' '--disable-static' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS=' 'CXX=g++' 'CXXFLAGS=-g -O2' 'F77=gfortran' 'FFLAGS=-g -O2' Fortran compiler: gfortran FFLAGS: -O2 -g F2C: @F2C@ F2CFLAGS: @F2CFLAGS@ FLIBS: -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) CFLAGS: -O2 -g CPICFLAG: -fPIC C++ compiler: g++, version 4.3.3 CXXFLAGS: -O2 -g CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.0.1 BLAS_LIBS: -llapackgf-3 -lblas-3gf FFTW_LIBS: -lfftw3 LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DCXX_ABI=unknown -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMA=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_STRFTIME=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1 -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_EXP2=1 -DHAVE_LOG2=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot" User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /usr/lib/octave/3.0.1/site/exec/i486-pc-linux-gnu:/usr/lib/octave/api-v32/site/exec/i486-pc-linux-gnu:/usr/lib/octave/site/exec/i486-pc-linux-gnu:/usr/lib/octave/3.0.1/exec/i486-pc-linux-gnu:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games IMAGE_PATH = .:/usr/share/octave/3.0.1/imagelib PAGER = pager PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot gnuplot_command_end = gnuplot_command_plot = pl gnuplot_command_replot = rep gnuplot_command_splot = sp gnuplot_command_title = t gnuplot_command_using = u gnuplot_command_with = w history_file = /home/dimitris/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave3.0.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 print_answer_id_name = 1 print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From sebastien.villemot at ens.fr Tue Oct 13 04:28:30 2009 From: sebastien.villemot at ens.fr (=?ISO-8859-1?Q?S=E9bastien?= Villemot) Date: Tue, 13 Oct 2009 09:28:30 +0000 Subject: Race condition between Octave 3.2.3 and unlink() Message-ID: <1255426110.31610.13.camel@karaba.cepremap.org> Hi everyone, If I create a file foo1.m with the following content: ----------------foo1.m------------------ system("echo 1+2 > foo2.m"); foo2; ---------------------------------------- The following command will fail most of the time (but not always): $ touch foo2.m && rm -f foo2.m && octave foo1.m When it fails, the error message is: error: `foo2' undefined near line 2 column 1 error: called from: error: foo1.m at line 2, column 1 Introducing a long-enough time delay between the rm and Octave solves the problem: $ touch foo2.m && rm -f foo2.m && sleep 1 && octave foo1.m Tested on Octave 3.2.3 with Debian unstable. I have reported this to Debian BTS (but the report is partly incorrect since I had first thought this was a race condition between two instances of Octave). Best, -- S?bastien Villemot From highegg at gmail.com Tue Oct 13 06:40:07 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 13 Oct 2009 13:40:07 +0200 Subject: Wrong results in cov(X, Y) when X and Y are complex valued vectors In-Reply-To: <4AD2C6CD.5010508@gmail.com> References: <4AD2C6CD.5010508@gmail.com> Message-ID: <69d8d540910130440u6a113dfrde7154874b77a0ff@mail.gmail.com> On Mon, Oct 12, 2009 at 8:03 AM, Dimitrios Bouzas wrote: > -------- > Bug report for Octave 3.0.1 configured for i486-pc-linux-gnu > > Description: > ----------- > > ? ?According to my opinion, it looks like that octave has a major flaw, > ? ?when it comes to the calculation of the covariance of two complex valued > ? ?vectors. In particular the problem appears in the case where the > argument > ? ?vectors differ in dimension (column vs row vector or vice versa). > ? ?Due to probable efficiency reasons the author of Octave's cov() > transposes > ? ?the arguments if they are row vectors. The problem is that in Octave > like > ? ?in Matlab when transposing a complex valued matrix you don't get its > ? ?algebraic transpose but instead its conjugate transpose. > ? ?The above leads in calculating the covariance of the column vector > ? ?argument with the conjugate transpose of the row vector argument. > ? ?Considering that each argument vector is a collection of observations > ? ?of a random variable the above according to my opinion is wrong. > > Repeat-By: > --------- > > ?* Please replace this item with a description of the sequence of > ? ?events that causes the problem to occur. > > Fix: > --- > I think there's a hell lot of conjugation in the cov source. For real case, everything is clear, but for the complex case, I can't find an authoritative source on what the sample covariance should look like. Can anyone who knows more statistics give me a clue? Is the following patch OK? Or should it work differently? Note that this will also affect cor. diff --git a/scripts/statistics/base/cov.m b/scripts/statistics/base/cov.m --- a/scripts/statistics/base/cov.m +++ b/scripts/statistics/base/cov.m @@ -44,23 +44,23 @@ endif if (rows (x) == 1) - x = x'; + x = x.'; endif n = rows (x); if (nargin == 2) if (rows (y) == 1) - y = y'; + y = y.'; endif if (rows (y) != n) error ("cov: x and y must have the same number of observations"); endif x = center (x, 1); y = center (y, 1); - c = conj (x' * y / (n - 1)); + c = x' * y / (n - 1); elseif (nargin == 1) x = center (x, 1); - c = conj (x' * x / (n - 1)); + c = x' * x / (n - 1); endif endfunction -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From info at tech-chat.de Tue Oct 13 07:21:28 2009 From: info at tech-chat.de (info at tech-chat.de) Date: Tue, 13 Oct 2009 14:21:28 +0200 (CEST) Subject: fmod arguments in data.cc interchanged? Message-ID: <1482578078.512901.1255436488165.JavaMail.open-xchange@oxltgw17.schlund.de> Hi at all, octave version 3.1.55 help fmod says: ...fmod (X, Y) ?Compute the floating point remainder of dividing X by Y using the ?C library function `fmod'... but in data.cc ?... ?octave_value arg_y = args(0); ?octave_value arg_x = args(1); ?... ?retval = fmod (x, y); Therefore, the output here is: octave:104> fmod(6.2,2) ans =? 2 octave:105> fmod(2,6.2) ans =? 0.20000 previous version of data.cc had
1110 [http://velveeta.che.wisc.edu/cgi-bin/hgwebdir.cgi/octave/file/tip//src/data.cc?rev=HEAD&content-type=text/plain#l1110 ] octave_value arg_x = args(0);
1111 [http://velveeta.che.wisc.edu/cgi-bin/hgwebdir.cgi/octave/file/tip//src/data.cc?rev=HEAD&content-type=text/plain#l1111 ] octave_value arg_y = args(1); Best regards, Andy
-------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091013/0dff9c3d/attachment.html From mirek at zind.ikem.pwr.wroc.pl Tue Oct 13 16:05:30 2009 From: mirek at zind.ikem.pwr.wroc.pl (Miroslaw Kwasniak) Date: Tue, 13 Oct 2009 23:05:30 +0200 Subject: Wrong results in cov(X, Y) when X and Y are complex valued vectors In-Reply-To: <69d8d540910130440u6a113dfrde7154874b77a0ff@mail.gmail.com> References: <4AD2C6CD.5010508@gmail.com> <69d8d540910130440u6a113dfrde7154874b77a0ff@mail.gmail.com> Message-ID: <20091013210530.GA18123@zind.ikem.pwr.wroc.pl> On Tue, Oct 13, 2009 at 01:40:07PM +0200, Jaroslav Hajek wrote: > I think there's a hell lot of conjugation in the cov source. For real > case, everything is clear, but for the complex case, I can't find an > authoritative source on what the sample covariance should look like. > Can anyone who knows more statistics give me a clue? A proper definition is Cxy=E((x-E(x))*conj((y-E(y))) which is equivalent to conj(x'*y)/(n-1) for columnwise vectors. ^^^^^ I'm not sure if this scaling factor is ok. Then this part of your patch is wrong - original part was OK: > - c = conj (x' * y / (n - 1)); > + c = x' * y / (n - 1); > elseif (nargin == 1) > x = center (x, 1); > - c = conj (x' * x / (n - 1)); > + c = x' * x / (n - 1); > endif Mirek From mirek at zind.ikem.pwr.wroc.pl Tue Oct 13 16:05:30 2009 From: mirek at zind.ikem.pwr.wroc.pl (Miroslaw Kwasniak) Date: Tue, 13 Oct 2009 23:05:30 +0200 Subject: Wrong results in cov(X, Y) when X and Y are complex valued vectors In-Reply-To: <69d8d540910130440u6a113dfrde7154874b77a0ff@mail.gmail.com> References: <4AD2C6CD.5010508@gmail.com> <69d8d540910130440u6a113dfrde7154874b77a0ff@mail.gmail.com> Message-ID: <20091013210530.GA18123@zind.ikem.pwr.wroc.pl> On Tue, Oct 13, 2009 at 01:40:07PM +0200, Jaroslav Hajek wrote: > I think there's a hell lot of conjugation in the cov source. For real > case, everything is clear, but for the complex case, I can't find an > authoritative source on what the sample covariance should look like. > Can anyone who knows more statistics give me a clue? A proper definition is Cxy=E((x-E(x))*conj((y-E(y))) which is equivalent to conj(x'*y)/(n-1) for columnwise vectors. ^^^^^ I'm not sure if this scaling factor is ok. Then this part of your patch is wrong - original part was OK: > - c = conj (x' * y / (n - 1)); > + c = x' * y / (n - 1); > elseif (nargin == 1) > x = center (x, 1); > - c = conj (x' * x / (n - 1)); > + c = x' * x / (n - 1); > endif Mirek From storrsjm at email.uc.edu Tue Oct 13 17:27:49 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Tue, 13 Oct 2009 18:27:49 -0400 Subject: Wrong results in cov(X, Y) when X and Y are complex valued vectors In-Reply-To: <20091013210530.GA18123@zind.ikem.pwr.wroc.pl> References: <4AD2C6CD.5010508@gmail.com> <69d8d540910130440u6a113dfrde7154874b77a0ff@mail.gmail.com> <20091013210530.GA18123@zind.ikem.pwr.wroc.pl> Message-ID: I thought I would compare with what Matlab does. Matlab returns a covariance matrix. Matlab 7.5.0 (R2007b) >> x = exp(-i*(0:100)/100*pi) ; >> y = exp(-i*0.9999*((0:100)+10)/100*pi) ; >> cov(x,y) ans = 0.6088 0.5790 - 0.1880i 0.5790 + 0.1880i 0.6087 Octave 3.2.2 (without the patch) returns a single value: octave:1> x = exp(-i*(0:100)/100*pi) ; octave:2> y = exp(-i*0.9999*((0:100)+10)/100*pi) ; octave:3> cov(x,y) ans = 0.57899 + 0.18801i --judd -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091013/815bba57/attachment.html From storrsjm at email.uc.edu Tue Oct 13 17:27:49 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Tue, 13 Oct 2009 18:27:49 -0400 Subject: Wrong results in cov(X, Y) when X and Y are complex valued vectors In-Reply-To: <20091013210530.GA18123@zind.ikem.pwr.wroc.pl> References: <4AD2C6CD.5010508@gmail.com> <69d8d540910130440u6a113dfrde7154874b77a0ff@mail.gmail.com> <20091013210530.GA18123@zind.ikem.pwr.wroc.pl> Message-ID: I thought I would compare with what Matlab does. Matlab returns a covariance matrix. Matlab 7.5.0 (R2007b) >> x = exp(-i*(0:100)/100*pi) ; >> y = exp(-i*0.9999*((0:100)+10)/100*pi) ; >> cov(x,y) ans = 0.6088 0.5790 - 0.1880i 0.5790 + 0.1880i 0.6087 Octave 3.2.2 (without the patch) returns a single value: octave:1> x = exp(-i*(0:100)/100*pi) ; octave:2> y = exp(-i*0.9999*((0:100)+10)/100*pi) ; octave:3> cov(x,y) ans = 0.57899 + 0.18801i --judd -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091013/815bba57/attachment-0001.html From bea at f2s.com Tue Oct 13 18:07:30 2009 From: bea at f2s.com (samwise) Date: Wed, 14 Oct 2009 00:07:30 +0100 Subject: Error when starting up Octave Message-ID: <1255475250.24009.105.camel@samwise-laptop> Dear Octave Bugs, I would be most grateful for your help. I cannot get rid of the following bug when starting-up Octave (the Octave terminal screen output is shown between the two lines of asterisks): *************************************************************************** Starting Octave... load("-text","/home/samwise/.qtoctave/1255468463.variables" ); cd(qtoctave_pwd); clear qtoctave_pwd; GNU Octave, version 3.0.1 Copyright (C) 2008 John W. Eaton and others. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. Octave was configured for "i486-pc-linux-gnu". Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to (but first, please read http://www.octave.org/bugs.html to learn how to write a helpful report). For information about changes from previous versions, type `news'. octave:1>error: octave_base_value::load_ascii(): wrong type argument `swig_ref' error: load: trouble reading ascii file `/home/samwise/.qtoctave/1255468463.variables' error: load: reading file /home/samwise/.qtoctave/1255468463.variables octave:2> ******************************************************************************* In fact, I don't have a variable called swig_ref at all (and never have had!). I am running GNU Octave on an old Toshiba Satellite (laptop) under Ubuntu 8.10 (Intrepid Ibex). The Command List has only the command 'quit' listed as this is the command that I used to exit Octave previously. The file 1255468463.variables contains the following: ********************************************************************************************************** # Created by Octave 3.0.1, Tue Oct 13 22:14:25 2009 BST # name: __nargin__ # type: scalar 5 # name: __SWIG_MODULE__4 # type: global uint64 scalar 3046835264 # name: ftp # type: global swig_ref ********************************************************************************************************** config.rc contains: ********************************************************************************************************** #QtOctave local configuration. lines_in_terminal=1000 navigator_start_path=/home/samwise/Octave work terminal_background_color=White terminal_error_color=Red terminal_font=Courier 10 Pitch terminal_foreground_color=Black ********************************************************************************************************** the last_windows_layout.xml source (what ever source means!) file is: ********************************************************************************************************** 000000ff00000000fd00000000000002480000021200000004000000040000000800000008fc00000000 000000ff00000000fd00000000000000640000008300000004000000040000000800000008fc00000000 000000ff00000000fd000000000000011e0000008f00000004000000040000000800000008fc00000000 000000ff00000000fd000000000000011e000000f700000004000000040000000800000008fc00000001000000020000000100000020004e0061007600690067006100740069006f006e00200074006f006f006c007301000000000000011e0000000000000000 000000ff00000000fd00000001000000000000011e0000022efc0200000002fc0000004600000168000000f201000019fa000000010100000002fb0000001e005600610072006900610062006c0065007300270020004c0069007300740100000000ffffffff0000005d00fffffffb00000012004e006100760069006700610074006f007201000000000000011e0000004f00fffffffb0000001c0043006f006d006d0061006e0064007300270020004c00690073007401000001b4000000c00000007c00ffffff000002540000022e00000004000000040000000800000008fc0000000100000002000000040000002a0054006f006f006c004200610072003a0020005400650072006d0069006e0061006c002000520075006e01000000000000007a00000000000000000000001e0054006f006f006c004200610072003a0020004d00610074007200690078010000007a0000003000000000000000000000001a0054006f006f006c004200610072003a002000480065006c007001000000aa0000007a00000000000000000000001c0054006f006f006c004200610072003a00200044006f0063006b00730100000124000002540000000000000000 000000ff00000000fd00000000000001b9000000ce00000004000000040000000800000008fc00000000 000000ff00000000fd00000001000000000000010000000150fc0200000001fb0000001200460069006c00650020006c0069007300740100000040000001500000006200ffffff000001160000015000000004000000040000000800000008fc0000000100000002000000010000001c0045006400690074006f00720020004f007000740069006f006e007301000000000000021c0000000000000000 ************************************************************************************************************ and the projects.xml file looks like : *********************************************************************************************************** /home/samwise/Octave work /home/samwise/.qtoctave/1255468463.variables /home/samwise/Octave work/mat2vec.m quit *********************************************************************************************************** You can see from this that I created and successfully ran a little .m file that takes a matrix and converts it into a vector. I don't understand the term __SWIG_MODULE__4 in the variables file. Could this mean that one of the toolbox files is causing problems - I have also installed quite a lot of toolboxes on the basis that I'm interested in using Octave for my research as well as my teaching. I would be very grateful if you could sort this problem out for me. (I'll then try and tackle the problem of installing Octave properly on my windows machine - I need an interface and the correct 'environment(?)' to run it (I think)). Kind regards, Samwise Hamfast From highegg at gmail.com Wed Oct 14 00:31:16 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 14 Oct 2009 07:31:16 +0200 Subject: fmod arguments in data.cc interchanged? In-Reply-To: <1482578078.512901.1255436488165.JavaMail.open-xchange@oxltgw17.schlund.de> References: <1482578078.512901.1255436488165.JavaMail.open-xchange@oxltgw17.schlund.de> Message-ID: <69d8d540910132231u150f9ef7x56919bc1950673d8@mail.gmail.com> On Tue, Oct 13, 2009 at 2:21 PM, info at tech-chat.de wrote: > Hi at all, > octave version 3.1.55 > help fmod says: ...fmod (X, Y) > ?Compute the floating point remainder of dividing X by Y using the > ?C library function `fmod'... > > but in data.cc > ?... > ?octave_value arg_y = args(0); > ?octave_value arg_x = args(1); > ?... > ?retval = fmod (x, y); > > Therefore, the output here is: > octave:104> fmod(6.2,2) > ans =? 2 > octave:105> fmod(2,6.2) > ans =? 0.20000 > > previous version of data.cc had > >
> 1110 octave_value arg_x = args(0); > > >
> 1111 octave_value arg_y = args(1); > > > > > > Best regards, Andy > > > > This is already fixed in both 3.2.x and development tree. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From godfrey at isl.stanford.edu Wed Oct 14 01:32:28 2009 From: godfrey at isl.stanford.edu (Michael D Godfrey) Date: Tue, 13 Oct 2009 23:32:28 -0700 Subject: Wrong results in cov(X,Y) when X and Y are complex valued vectors Message-ID: <4AD5707C.2030401@isl.stanford.edu> Jaroslav Hajek wrote: x = center (x, 1); y = center (y, 1); - c = conj (x' * y / (n - 1)); + c = x' * y / (n - 1); ====================================== But in order to provide Matlab compatibility this needs to be: x = center (x, 1); y = center (y, 1); - c = conj (x' * y / (n - 1)); + xy = [x y]; + c = xy' * xy / (n - 1); ====================================== This is not intended to be a real bug fix. It is only intended to show what is needed for compatibility. This code should be thought about more. Michael From highegg at gmail.com Wed Oct 14 01:45:12 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 14 Oct 2009 08:45:12 +0200 Subject: Wrong results in cov(X, Y) when X and Y are complex valued vectors In-Reply-To: <4AD5707C.2030401@isl.stanford.edu> References: <4AD5707C.2030401@isl.stanford.edu> Message-ID: <69d8d540910132345w3e56447fyf50099a6ed8f8859@mail.gmail.com> On Wed, Oct 14, 2009 at 8:32 AM, Michael D Godfrey wrote: > Jaroslav Hajek wrote: > > ? ? ?x = center (x, 1); > ? ? ?y = center (y, 1); > - ? ?c = conj (x' * y / (n - 1)); > + ? ?c = x' * y / (n - 1); > ====================================== > > But in order to provide Matlab compatibility this needs to be: > > ? ? ?x = center (x, 1); > ? ? ?y = center (y, 1); > - ? ?c = conj (x' * y / (n - 1)); > + ? ?xy = [x y]; > + ? ?c = xy' * xy / (n - 1); > ====================================== > > This is not intended to be a real bug fix. ?It is only > intended to show what is needed for compatibility. > This code should be thought about more. > > Michael > I see you are right - in Matlab (acc. to docs) cov (x, y) is equivalent to cov ([x(:), y(:)]). However, is this what we want in Octave? In Octave, cov (x, y) computes a cross-covariance matrix, which is I think also what R does. Anyone can surely use cov ([x, y]) in Octave; however, there seems to be no easy way to get the cross-covariance matrix (or correlation matrix) out of Matlab - you need to compute a joint covariance matrix, and then extract the relevant submatrix, which is not only longer code but also a waste of time and memory. Hence, I think this is one of the design defects of Matlab that we should not duplicate. opinions? -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From godfrey at isl.stanford.edu Wed Oct 14 01:53:10 2009 From: godfrey at isl.stanford.edu (Michael D Godfrey) Date: Tue, 13 Oct 2009 23:53:10 -0700 Subject: Wrong results in cov(X, Y) when X and Y are complex valued vectors In-Reply-To: <69d8d540910132345w3e56447fyf50099a6ed8f8859@mail.gmail.com> References: <4AD5707C.2030401@isl.stanford.edu> <69d8d540910132345w3e56447fyf50099a6ed8f8859@mail.gmail.com> Message-ID: <4AD57556.6000207@isl.stanford.edu> On 10/13/2009 11:45 PM, Jaroslav Hajek wrote: > Hence, I think this is one of the design defects of Matlab that we > should not duplicate. I agree. I do not understand why Matlab does cov() that way. The code definitely does what the documentation that you quoted says. This is easy to demonstrate. I will ask around to see if anyone has an explanation. I guess that another possibility to consider is to implement a compatible cov(x,y), and rename the "real" cov something else. I prefer your view. But, if it is decided to be NOT compatible it will be good to document this as clearly as possible. People moving code from Matlab will be a bit surprised. Michael From tmacchant at yahoo.co.jp Wed Oct 14 02:54:22 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Wed, 14 Oct 2009 16:54:22 +0900 (JST) Subject: Error when starting up Octave In-Reply-To: <1255475250.24009.105.camel@samwise-laptop> Message-ID: <20091014075422.15800.qmail@web3801.mail.bbt.yahoo.co.jp> Hello Ir seems that qroctave is related to this error > load("-text","/home/samwise/.qtoctave/1255468463.variables" > > ); cd(qtoctave_pwd); clear qtoctave_pwd; > I could not understand what you would like to do by the above. Can you execute octave without qtocgtave? If octave is executed normally without qtoctave, the problem relies on qtroctave. In that case, here is not proper space to ask your problem and ask problem at qtoctave site. Regards Tatsuro --- samwise wrote: > Dear Octave Bugs, > > I would be most grateful for your help. I cannot get rid of the > following bug when starting-up Octave (the Octave terminal screen output > is shown between the two lines of asterisks): > > *************************************************************************** > Starting Octave... > load("-text","/home/samwise/.qtoctave/1255468463.variables" > > ); cd(qtoctave_pwd); clear qtoctave_pwd; > > GNU Octave, version 3.0.1 > > Copyright (C) 2008 John W. Eaton and others. > > This is free software; see the source code for copying conditions. > > There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or > > FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. > > Octave was configured for "i486-pc-linux-gnu". > > Additional information about Octave is available at > http://www.octave.org. > > Please contribute if you find this software useful. > > For more information, visit http://www.octave.org/help-wanted.html > > Report bugs to (but first, please read > > http://www.octave.org/bugs.html to learn how to write a helpful report). > > For information about changes from previous versions, type `news'. > > octave:1>error: octave_base_value::load_ascii(): wrong type argument > `swig_ref' > > error: load: trouble reading ascii file > `/home/samwise/.qtoctave/1255468463.variables' > > error: load: reading file /home/samwise/.qtoctave/1255468463.variables > > octave:2> > ******************************************************************************* > > In fact, I don't have a variable called swig_ref at all (and never have > had!). I am running GNU Octave on an old Toshiba Satellite (laptop) > under Ubuntu 8.10 (Intrepid Ibex). The Command List has only the command > 'quit' listed as this is the command that I used to exit Octave > previously. The file 1255468463.variables contains the following: > > ********************************************************************************************************** > > # Created by Octave 3.0.1, Tue Oct 13 22:14:25 2009 BST > > # name: __nargin__ > # type: scalar > 5 > # name: __SWIG_MODULE__4 > # type: global uint64 scalar > 3046835264 > # name: ftp > # type: global swig_ref > > ********************************************************************************************************** > > config.rc contains: > > ********************************************************************************************************** > > #QtOctave local configuration. > lines_in_terminal=1000 > navigator_start_path=/home/samwise/Octave work > terminal_background_color=White > terminal_error_color=Red > terminal_font=Courier 10 Pitch > terminal_foreground_color=Black > > ********************************************************************************************************** > > the last_windows_layout.xml source (what ever source means!) file is: > > ********************************************************************************************************** > > > > > > 000000ff00000000fd00000000000002480000021200000004000000040000000800000008fc00000000 > > > > > 000000ff00000000fd00000000000000640000008300000004000000040000000800000008fc00000000 > > > > 000000ff00000000fd000000000000011e0000008f00000004000000040000000800000008fc00000000 > > > > 000000ff00000000fd000000000000011e000000f700000004000000040000000800000008fc00000001000000020000000100000020004e0061007600690067006100740069006f006e00200074006f006f006c007301000000000000011e0000000000000000 > > > 000000ff00000000fd00000001000000000000011e0000022efc0200000002fc0000004600000168000000f201000019fa000000010100000002fb0000001e005600610072006900610062006c0065007300270020004c0069007300740100000000ffffffff0000005d00fffffffb00000012004e006100760069006700610074006f007201000000000000011e0000004 f00fffffffb0000001c0043006f006d006d0061006e0064007300270020004c00690073007401000001b4000000c00000007c00ffffff000002540000022e00000004000000040000000800000008fc0000000100000002000000040000002a0054006f006f006c004200610072003a0020005400650072006d0069006e0061006c002000520075006e01000000000000007a00000 000000000000000001e0054006f006f006c004200610072003a0020004d00610074007200690078010000007a0000003000000000000000000000001a0054006f006f006c004200610072003a002000480065006c007001000000aa0000007a00000000000000000000001c0054006f006f006c004200610072003a00200044006f0063006b0073010000012400000254000000000 0000000 > > > > 000000ff00000000fd00000000000001b9000000ce00000004000000040000000800000008fc00000000 > > > > 000000ff00000000fd00000001000000000000010000000150fc0200000001fb0000001200460069006c00650020006c0069007300740100000040000001500000006200ffffff000001160000015000000004000000040000000800000008fc0000000100000002000000010000001c0045006400690074006f00720020004f007000740069006f006e007301000000000 000021c0000000000000000 > > > > ************************************************************************************************************ > > and the projects.xml file looks like : > > *********************************************************************************************************** > > > > > /home/samwise/Octave work > /home/samwise/.qtoctave/1255468463.variables > /home/samwise/Octave work/mat2vec.m > quit > > > > *********************************************************************************************************** > > You can see from this that I created and successfully ran a little .m > file that takes a matrix and converts it into a vector. I don't > understand the term __SWIG_MODULE__4 in the variables file. Could this > mean that one of the toolbox files is causing problems - I have also > installed quite a lot of toolboxes on the basis that I'm interested in > using Octave for my research as well as my teaching. > > I would be very grateful if you could sort this problem out for me. > (I'll then try and tackle the problem of installing Octave properly on > my windows machine - I need an interface and the correct > 'environment(?)' to run it (I think)). > > Kind regards, > > Samwise Hamfast > > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From jwleblan at gmail.com Wed Oct 14 11:19:52 2009 From: jwleblan at gmail.com (Joel LeBlanc) Date: Wed, 14 Oct 2009 12:19:52 -0400 Subject: Script vs command line bug Message-ID: <34716c2e0910140919g31aff3c1saa5198b20135a083@mail.gmail.com> I am observing an odd bug in the development branch of the code (ae1967559f5a tip) where code successfully executes from within a script, but not from the command prompt. The code involves calling a method (display) from an object that has been inherited from another object that defines the display function. I have put together an (almost) minimal example and attached the code. To replicate the problem. 1) cd to the path where you extracted the files 2) execute runMe.m (you should get some stuff displayed to the sceen) 3) execute the lines contained in runMe.m manually at the prompt (I get the error listed below) >> t = Sample(); >> t error: display: not defined for class "Sample" error: called from display at line 36 column 3 stopped in /Users/leblanc/code/octave/scripts/general/display.m Thanks, ~Joel -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091014/299c8647/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: inheritTest.zip Type: application/zip Size: 7633 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091014/299c8647/attachment-0001.zip From godfrey at isl.stanford.edu Wed Oct 14 12:40:00 2009 From: godfrey at isl.stanford.edu (Michael D. Godfrey) Date: Wed, 14 Oct 2009 10:40:00 -0700 Subject: cov(), corrcoeff() and Matlab Message-ID: <4AD60CF0.5060906@isl.stanford.edu> I noticed in the Matlab doc that both of these functions are for: Class support for inputs X,Y: float: double, single but they do not check the inputs to enforce this. So, if Octave cov() behaves differently from Matlab for complex arguments it can be argued that this is an extension that is not defined for Matlab. (Am I correct in assuming that "Class support" really means that the arguments should be double or single but not complex?) The Matlab definition of corrcoef is: R = corrcoef(X) returns a matrix R of correlation coefficients calculated from an input matrix X whose rows are observations and whose columns are variables. The matrix R = corrcoef(X) is related to the covariance matrix C = cov(X) by R(i,j) = C(i,j)/sqrt(C(i,i)C(j,j)) So, I think that Jaroslav's original fix is correct for complex arguments and is the best choice. Good to verify that this is compatible with R. And, on all statistics functions I would say that R-compatibility is likely to be a better choice. R was and is written by statisticians, Matlab is not. Michael From godfrey at isl.stanford.edu Wed Oct 14 13:01:43 2009 From: godfrey at isl.stanford.edu (Michael D. Godfrey) Date: Wed, 14 Oct 2009 11:01:43 -0700 Subject: cov, corrcoef isssues Message-ID: <4AD61207.2080908@isl.stanford.edu> I just noticed that in Matlab: x = 1+1i; class(x) ans = double and: whos Name Size Bytes Class Attributes ans 1x6 12 char x 1x1 16 double complex ================================= (Also, there is no iscomplex() function in Matlab.) So, this implies that in Matlab "Class" double includes complex. The use of the term "attribute" above seems to be a bit unfortunate. In the Matlab documentation "attribute" is a part of the Simulink stuff. I could not find anything that fit the above usage. Anyhow, I would move the use of complex arguments in Matlab cov(x,y) from not allowed to not documented. From storrsjm at email.uc.edu Wed Oct 14 13:14:20 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Wed, 14 Oct 2009 14:14:20 -0400 Subject: cov(), corrcoeff() and Matlab In-Reply-To: <4AD60CF0.5060906@isl.stanford.edu> References: <4AD60CF0.5060906@isl.stanford.edu> Message-ID: >Am I correct in assuming that "Class support" really means that the arguments should be double or single but not complex? I don't think so. I believe the "class support" statement is notification that overloading the function is likely to behave differently than you might otherwise expect. Matlab's dispatch rules are arcane and convoluted. I think this notice means that if you create an overloaded function to handle a new type, whether your version or Matlab's version is called will be determined solely by the type of X. So if your new type happened to show up in Y with X as type double or float, Matlab's version would be called anyway. If X and Y didn't have "class support" then your overloaded function would be called if either X or Y were your new type. It don't know how the new classdef stuff works so there may be more wrinkles. > R was and is written by statisticians, Matlab is not. R is already a free software implementation of S+, why reinvent that wheel here? If someone likes R's approach, why not use R instead of octave they're both free software? There are other features of the S+ language that are fundamentally incompatible with Matlab syntax. Do you expect those to be implemented here as well? FWIW, SPM and fmristat are just two examples of a projects built by statisticians on Matlab. --judd On Wed, Oct 14, 2009 at 1:40 PM, Michael D. Godfrey < godfrey at isl.stanford.edu> wrote: > I noticed in the Matlab doc that both of these functions > are for: > Class support for inputs X,Y: > float: double, single > > but they do not check the inputs to enforce this. > > So, if Octave cov() behaves differently from Matlab > for complex arguments it can be argued that this is > an extension that is not defined for Matlab. > > (Am I correct in assuming that "Class support" really > means that the arguments should be double or single > but not complex?) > > The Matlab definition of corrcoef is: > R = corrcoef(X) returns a matrix R of correlation coefficients calculated > from an input matrix X whose rows are observations and whose > columns are variables. The matrix R = corrcoef(X) is related to > the covariance matrix C = cov(X) by > R(i,j) = C(i,j)/sqrt(C(i,i)C(j,j)) > > So, I think that Jaroslav's original fix is correct for complex > arguments and is the best choice. Good to verify that this > is compatible with R. And, on all statistics functions I would > say that R-compatibility is likely to be a better choice. R was and > is written by statisticians, Matlab is not. > > Michael > > > > > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091014/b80ba07c/attachment.html From storrsjm at email.uc.edu Wed Oct 14 13:18:40 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Wed, 14 Oct 2009 14:18:40 -0400 Subject: cov(), corrcoeff() and Matlab In-Reply-To: References: <4AD60CF0.5060906@isl.stanford.edu> Message-ID: On Wed, Oct 14, 2009 at 2:14 PM, Judd Storrs wrote: > >Am I correct in assuming that "Class support" really means that the > arguments should be double or single but not complex? > > I don't think so. I believe the "class support" statement is notification > that overloading the function is likely to behave differently than you might > otherwise expect. Matlab's dispatch rules are arcane and convoluted. I think > this notice means that if you create an overloaded function to handle a new > type, whether your version or Matlab's version is called will be determined > solely by the type of X. So if your new type happened to show up in Y with X > as type double or float, Matlab's version would be called anyway. If X and Y > didn't have "class support" then your overloaded function would be called if > either X or Y were your new type. It don't know how the new classdef stuff > works so there may be more wrinkles. An additional thought is that it may also mean that other types (such as integer types) are coerced to float or double automatigically. --judd -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091014/34886e7a/attachment.html From storrsjm at email.uc.edu Wed Oct 14 13:26:11 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Wed, 14 Oct 2009 14:26:11 -0400 Subject: cov(), corrcoeff() and Matlab In-Reply-To: References: <4AD60CF0.5060906@isl.stanford.edu> Message-ID: Well scratch that. I have no idea what they mean--there are no overloaded definitions of cov. It looked like it could make sense... >> functions(@cov) ans = function: 'cov' type: 'simple' file: '/usr/local/stow/matlab-R2007b/matlab/R2007b/toolbox/matlab/datafun/cov.m' --judd On Wed, Oct 14, 2009 at 2:18 PM, Judd Storrs wrote: > On Wed, Oct 14, 2009 at 2:14 PM, Judd Storrs wrote: > >> >Am I correct in assuming that "Class support" really means that the >> arguments should be double or single but not complex? >> >> I don't think so. I believe the "class support" statement is notification >> that overloading the function is likely to behave differently than you might >> otherwise expect. Matlab's dispatch rules are arcane and convoluted. I think >> this notice means that if you create an overloaded function to handle a new >> type, whether your version or Matlab's version is called will be determined >> solely by the type of X. So if your new type happened to show up in Y with X >> as type double or float, Matlab's version would be called anyway. If X and Y >> didn't have "class support" then your overloaded function would be called if >> either X or Y were your new type. It don't know how the new classdef stuff >> works so there may be more wrinkles. > > > An additional thought is that it may also mean that other types (such as > integer types) are coerced to float or double automatigically. > > --judd > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091014/3b405f8b/attachment.html From dennisveatch at bellsouth.net Wed Oct 14 08:24:27 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Wed, 14 Oct 2009 09:24:27 -0400 Subject: Fwd: Re: dead-octave-bug-1, octave-3.2.3 Message-ID: <200910140924.27497.dennisveatch@bellsouth.net> Oops. ---------- Forwarded Message ---------- Subject: Re: dead-octave-bug-1, octave-3.2.3 Date: Monday 12 October 2009 From: "John W. Eaton" To: Dennis Veatch Please reply on the list so others may comment. Thanks, jwe On 12-Oct-2009, Dennis Veatch wrote: | On Sunday 11 October 2009 4:33:54 pm you wrote: | > On 1-Oct-2009, Dennis Veatch wrote: | > | To: bug at octave.org | > | Cc: dveatch | > | Subject: [50 character or so descriptive subject here (for reference)] | > | -------- | > | Bug report for Octave 3.2.3 configured for x86_64-pc-linux-gnu | > | | > | Description: | > | ----------- | > | | > | The compile proces goes fine; nor problem there. When I attempt to run | > | it from a terminal, it fails to run and throws this error; | > | octave: symbol lookup error: /usr/lib/octave-3.2.3/liboctave.so: | > | undefined symbol: pthread_mutexattr_init | > | | > | This also happens with version 3.2.2. | > | | > | Repeat-By: | > | --------- | > | | > | The system is running gcc-4.4.1, glibc-2.10.1 and other needed friends. | > | Prior to this it compiled and ran fine. | > | | > | Fix: | > | --- | > | | > | Well, short of reverting my system back to the older versions of | > | gcc/glibc, I don't know what the fix should be. | > | > I think you may need to link with -lpthread. I recently added a check | > for pthread to Octave's configure script, so this should not be a | > problem in the next major release. I'm not sure whether it is worth | > applyhing the patch to the 3.2.x release branch. If you are | > interested in trying the change I checked in with 3.2.x, look for the | > following patch in the sources on savannah: | > | > changeset: 9488:ee572cdd4b97 | > user: John W. Eaton | > date: Wed Aug 05 13:27:58 2009 -0400 | > summary: add configure checks for pthread library and compiler flags | > | > Sorry, I can't give a direct URL for the changeset at the moment. | > | > jwe | > | | No problem finding it. Applied it but the make fails on; | | make[3]: Entering directory `/usr/src/octave-3.2.3/libcruft/misc' | making quit.d from quit.cc | g++: @PTHREAD_CFLAGS@: No such file or directory | making f77-extern.d from f77-extern.cc | g++: @PTHREAD_CFLAGS@: No such file or directory | making cquit.d from cquit.c | gcc: @PTHREAD_CFLAGS@: No such file or directory | making lo-error.d from lo-error.c | gcc: @PTHREAD_CFLAGS@: No such file or directory | making f77-fcn.d from f77-fcn.c | gcc: @PTHREAD_CFLAGS@: No such file or directory | make[3]: Leaving directory `/usr/src/octave-3.2.3/libcruft/misc' | make[3]: Entering directory `/usr/src/octave-3.2.3/libcruft/misc' | mkdir pic | making d1mach.def from d1mach.f | making r1mach.def from r1mach.f | making i1mach.def from i1mach.f | touch stmp-pic | gfortran -c -fPIC -O d1mach.f -o pic/d1mach.o | gfortran -c -fPIC -O r1mach.f -o pic/r1mach.o | gfortran -c -fPIC -O i1mach.f -o pic/i1mach.o | gcc -c -fPIC -I. -I../.. -I../../liboctave -I../../src - I../../libcruft/misc | -DHAVE_CONFIG_H -Wall -W -Wshadow -Wformat -O2 -march=x86-64 -pipe | @PTHREAD_CFLAGS@ f77-fcn.c -o pic/f77-fcn.o | gcc: @PTHREAD_CFLAGS@: No such file or directory | f77-fcn.c: In function 'xstopx_': | | | -- | You can tuna piano, but you can't tune a fish. ------------------------------------------------------- -- You can tuna piano, but you can't tune a fish. From thomas.weber.mail at gmail.com Wed Oct 14 15:40:58 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Wed, 14 Oct 2009 22:40:58 +0200 Subject: [Pkg-octave-devel] Bug#550828: error: lsode: `__lsode_fcn__Q__' is not valid as a function In-Reply-To: <20091013101618.14890.61729.reportbug@localhost.localdomain> References: <20091013101618.14890.61729.reportbug@localhost.localdomain> Message-ID: <20091014204058.GA17234@atlan> Hi, I'm forwarding below a bug against Octave 3.2.3 in Debian. It seems there is a regression in lsode()'s behaviour compared to the 3.0 series. I've checked that Octave 3.2.2 hits the same error. I am however not sure if the new behavior is a bug or the old behavior worked just by chance. Thanks Thomas On Tue, Oct 13, 2009 at 12:16:18PM +0200, Kim Hansen wrote: > Package: octave3.2 > Version: 3.2.3-1 > Severity: normal > > > > lsode does not work in octave3.2: > > kim at raph:~$ octave3.2 -q > octave3.2:1> lsode("t",0,[0,1]) > error: eval: invalid use of statement list > error: lsode: `__lsode_fcn__Q__' is not valid as a function > octave3.2:1> > kim at raph:~$ > > > The expected behaviour is: > > kim at raph:~$ octave -q > octave:1> lsode("t",0,[0,1]) > ans = > > 0.00000 > 0.50000 > > octave:2> > kim at raph:~$ From highegg at gmail.com Thu Oct 15 07:39:56 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Thu, 15 Oct 2009 14:39:56 +0200 Subject: [Pkg-octave-devel] Bug#550828: error: lsode: `__lsode_fcn__Q__' is not valid as a function In-Reply-To: <20091014204058.GA17234@atlan> References: <20091013101618.14890.61729.reportbug@localhost.localdomain> <20091014204058.GA17234@atlan> Message-ID: <69d8d540910150539r2c842b18tc6212e888747795f@mail.gmail.com> On Wed, Oct 14, 2009 at 10:40 PM, Thomas Weber wrote: > Hi, > > I'm forwarding below a bug against Octave 3.2.3 in Debian. It seems > there is a regression in lsode()'s behaviour compared to the 3.0 series. > I've checked that Octave 3.2.2 hits the same error. > > I am however not sure if the new behavior is a bug or the old behavior > worked just by chance. > > Thanks > ? ? ? ?Thomas > It's a bug that has laid dormant there for years - extract_function was defining function via eval with nargout = 1, and for some reason that is no longer allowed (which is probably good) - just passing explicit zero solves the problem. However, this way of passing functions as bodies in string with implied arguments (usually it's "x", here "t, x") is considered obsolete. So I also added a warning. This feature will likely be removed at some point, maybe in 3.6. http://hg.savannah.gnu.org/hgweb/octave/rev/04386b72d3df thanks -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From sebastien.villemot at ens.fr Thu Oct 15 09:09:30 2009 From: sebastien.villemot at ens.fr (=?ISO-8859-1?Q?S=E9bastien?= Villemot) Date: Thu, 15 Oct 2009 14:09:30 +0000 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <1255426110.31610.13.camel@karaba.cepremap.org> References: <1255426110.31610.13.camel@karaba.cepremap.org> Message-ID: <1255615770.20678.21.camel@karaba.cepremap.org> Hi, I think I found the culprit for what I thought was a race condition in Octave. The problem has to do with the way Octave 3.2 updates its load-path: it only updates its cache of the current directory if the modification time of the directory changes (see load_path::dir_info::update() in src/load-path.cc). The problem is that modification times (as returned by stat()) are expressed in seconds; so when two changes of the directory occur within the same second, Octave can miss the second one. Here is an example script which demonstrates this: --------------------------- system("echo 1+1 > foo.m"); delete("foo.m"); try foo; catch end system("echo 1+1 > foo.m"); foo; --------------------------- The first two lines update the modification time of the directory (file creation then deletion). Then the call to script "foo" in the try/catch block will obviously fail, and by the way it will update the load-path cache. Then it creates the file "foo.m", and tries to launch that script. Two cases are possible: * the creation of "foo.m" occurred within the same second than its deletion a few lines above. The modification time of the directory is not updated. Then on the second call to script "foo", Octave will not update its load-path cache, and fail with an undefined symbol error * the creation of "foo.m" occurred in a different second: Octave updates its load-path, and everything goes well. So on my machine this script randomly fails, depending on when it was launched and how fast Octave performed the file system operations. In my opinion this invalidates the idea of updating load-path cache based on modification times. The only workaround for the moment is to insert sleep() calls at the right place to enforce changes in the modification times. I am applying such a workaround for Dynare, since otherwise this bug makes it randomly fail. Best, -- S?bastien Villemot Dynare developer Member of Debian Octave Group From tmacchant at yahoo.co.jp Fri Oct 16 06:25:00 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Fri, 16 Oct 2009 20:25:00 +0900 (JST) Subject: bug? of gnuplot_drawnow.m (unknown property "__pixels_per_inch__") Message-ID: <20091016112500.35920.qmail@web3807.mail.bbt.yahoo.co.jp> Hello In the thread http://www.nabble.com/Silent-plot(x,y)-td25917144.html I found the bug of gnuplot_drawnow.m. x=[0:1]; for i=[0:100] plot(x,x*i); filename=sprintf("%02d.png",i); drawnow('png',filename); end The above works on octave 3.0.5 (mingw). However, it does not work on octave 3.2.2 (mingw), 3.3.50+ (mingw) and octave 3.2.3(cygwin) error: get: unknown property "__pixels_per_inch__" error: called from: error: C:\Programs\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\plot\gnuplot_drawnow.m at line 190, column 14 error: C:\Programs\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\plot\gnuplot_drawnow.m at line 74, column 7 **__pixels_per_inch__ is inch is not defined in gnuplot_drawnow.m The below code does not cause error. plot (1:10);print ('dummy.png','-dpng');clf; x=[0:1]; for i=[0:10] plot(x,x*i); filename=sprintf("%02d.png",i); drawnow('png',filename); end close;unlink('dummy.png'); This is because the __pixels_per_inch__ is set in executing print.m The below quick huck seems to kick out problem. $ diff -ur gnuplot_drawnow.m.orig gnuplot_drawnow.m --- gnuplot_drawnow.m.orig 2009-08-21 04:06:28 +0900 +++ gnuplot_drawnow.m 2009-10-16 20:04:33 +0900 @@ -187,7 +187,17 @@ end_unwind_protect if (term_units_are_pixels (term)) ## Convert to inches using the property set by print(). - gnuplot_size = gnuplot_size * get (h, "__pixels_per_inch__"); + try + get (h, "__pixels_per_inch__"); + catch + figure_properties = get (gcf); + if (! isfield (figure_properties, "__pixels_per_inch__")) + addproperty ("__pixels_per_inch__", gcf, "double", 150); + endif + set (gcf, "__pixels_per_inch__", 150) + end + gnuplot_size = gnuplot_size * get (h, "__pixels_per_inch__"); + else ## Implicit margins are in units of "inches" gnuplot_size = gnuplot_size - implicit_margin; This patch is for gnuplotdraw.m of octave 3.2.2. I have not enough knowledge of graphic handles so that I cannot judge whether the above is bug or not. Please give me suggestion on this matter Thanks!! Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From bpabbott at mac.com Fri Oct 16 06:48:19 2009 From: bpabbott at mac.com (Ben Abbott) Date: Fri, 16 Oct 2009 07:48:19 -0400 Subject: bug? of gnuplot_drawnow.m (unknown property "__pixels_per_inch__") In-Reply-To: <20091016112500.35920.qmail@web3807.mail.bbt.yahoo.co.jp> References: <20091016112500.35920.qmail@web3807.mail.bbt.yahoo.co.jp> Message-ID: <23A80539-6005-4C34-8D5A-E425C23E4063@mac.com> On Oct 16, 2009, at 7:25 AM, Tatsuro MATSUOKA wrote: > Hello > > In the thread > > http://www.nabble.com/Silent-plot(x,y)-td25917144.html > > I found the bug of gnuplot_drawnow.m. > > x=[0:1]; > for i=[0:100] > plot(x,x*i); > filename=sprintf("%02d.png",i); > drawnow('png',filename); > end > > The above works on octave 3.0.5 (mingw). > > However, it does not work on octave 3.2.2 (mingw), 3.3.50+ (mingw) > and octave 3.2.3(cygwin) > error: get: unknown property "__pixels_per_inch__" > error: called from: > error: C:\Programs\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\plot > \gnuplot_drawnow.m at line 190, > column 14 > error: C:\Programs\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\plot > \gnuplot_drawnow.m at line 74, > column 7 > > **__pixels_per_inch__ is inch is not defined in gnuplot_drawnow.m > > The below code does not cause error. > plot (1:10);print ('dummy.png','-dpng');clf; > x=[0:1]; > for i=[0:10] > plot(x,x*i); > filename=sprintf("%02d.png",i); > drawnow('png',filename); > end > close;unlink('dummy.png'); > > This is because the __pixels_per_inch__ is set in executing print.m > > The below quick huck seems to kick out problem. > $ diff -ur gnuplot_drawnow.m.orig gnuplot_drawnow.m > --- gnuplot_drawnow.m.orig 2009-08-21 04:06:28 +0900 > +++ gnuplot_drawnow.m 2009-10-16 20:04:33 +0900 > @@ -187,7 +187,17 @@ > end_unwind_protect > if (term_units_are_pixels (term)) > ## Convert to inches using the property set by print(). > - gnuplot_size = gnuplot_size * get (h, > "__pixels_per_inch__"); > + try > + get (h, "__pixels_per_inch__"); > + catch > + figure_properties = get (gcf); > + if (! isfield (figure_properties, > "__pixels_per_inch__")) > + addproperty ("__pixels_per_inch__", > gcf, "double", 150); > + endif > + set (gcf, "__pixels_per_inch__", 150) > + end > + gnuplot_size = gnuplot_size * get (h, > "__pixels_per_inch__"); > + > else > ## Implicit margins are in units of "inches" > gnuplot_size = gnuplot_size - implicit_margin; > > This patch is for gnuplotdraw.m of octave 3.2.2. > > I have not enough knowledge of graphic handles so that I cannot > judge whether the above is bug or not. > > > Please give me suggestion on this matter > > Thanks!! > > Tatsuro I already responded to the other thread, so I apologize for the duplication here. I think it is a bug (one of mine actually). For me, the changeset produces an output equivalent the size specified by papersize, with the contents of the figure placed in the area specified by paperposition. Tatsuro, do you see the same thing (my sources are a bit out of date). Ben From Thomas.Treichl at gmx.net Fri Oct 16 13:58:07 2009 From: Thomas.Treichl at gmx.net (Thomas Treichl) Date: Fri, 16 Oct 2009 20:58:07 +0200 Subject: Undefined symbols: QR::raw, QR::std, QR::economy Message-ID: <4AD8C23F.1080001@gmx.net> Hi, on my Mac 10.4 I have the following problem for a while that: g++ -bundle -bundle_loader ../src/octave -L/Applications/Octave.app/Contents/Resources/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Developer/SDKs/MacOSX10.4u.sdk -Wl,-lexpat -o qr.oct pic/qr.o -L/Applications/Octave.app/Contents/Resources/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Developer/SDKs/MacOSX10.4u.sdk -Wl,-lexpat -L. -loctinterp -L../liboctave -loctave -L../libcruft -lcruft -lfftw3 -lfftw3f -lhdf5 -lz -L/tmp/deps-i386/lib -lfontconfig -lftgl -L/tmp/deps-i386/lib -lfreetype -Wl,-framework -Wl,OpenGL -Wl,-framework -Wl,Carbon -lreadline -lncurses -Wl,-framework -Wl,vecLib -L/Applications/Octave.app/Contents/Resources/lib/gcc-lib/i386-apple-darwin8.11.1/4.0.3 -lf95 -lm -lqrupdate -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: QR::raw QR::std QR::economy collect2: ld returned 1 exit status make[2]: *** [qr.oct] Error 1 make[1]: *** [src] Error 2 make: *** [all] Error 2 In which library should these symbols be defined? My source version is bash$ hg tip changeset: 9733:aab4f2aa9ed9 tag: tip user: Jaroslav Hajek date: Fri Oct 16 13:13:36 2009 +0200 summary: make ismember more matlab compatible Thanks for help, Thomas From highegg at gmail.com Fri Oct 16 14:47:29 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 16 Oct 2009 21:47:29 +0200 Subject: Undefined symbols: QR::raw, QR::std, QR::economy In-Reply-To: <4AD8C23F.1080001@gmx.net> References: <4AD8C23F.1080001@gmx.net> Message-ID: <69d8d540910161247u120325c3n5ce0ba9575416964@mail.gmail.com> On Fri, Oct 16, 2009 at 8:58 PM, Thomas Treichl wrote: > Hi, > > on my Mac 10.4 I have the following problem for a while that: > > g++ -bundle -bundle_loader ../src/octave > -L/Applications/Octave.app/Contents/Resources/lib > -Wl,-headerpad_max_install_names ? -Wl,-syslibroot > -Wl,/Developer/SDKs/MacOSX10.4u.sdk -Wl,-lexpat -o qr.oct pic/qr.o > -L/Applications/Octave.app/Contents/Resources/lib > -Wl,-headerpad_max_install_names ? -Wl,-syslibroot > -Wl,/Developer/SDKs/MacOSX10.4u.sdk -Wl,-lexpat -L. -loctinterp -L../liboctave > -loctave -L../libcruft -lcruft ? -lfftw3 -lfftw3f ?-lhdf5 ?-lz > -L/tmp/deps-i386/lib -lfontconfig ? -lftgl -L/tmp/deps-i386/lib -lfreetype > -Wl,-framework -Wl,OpenGL ?-Wl,-framework -Wl,Carbon -lreadline -lncurses > -Wl,-framework -Wl,vecLib > -L/Applications/Octave.app/Contents/Resources/lib/gcc-lib/i386-apple-darwin8.11.1/4.0.3 > -lf95 -lm ? -lqrupdate ? ? ? ?-lcholmod -lumfpack -lamd -lcamd -lcolamd > -lccolamd -lcxsparse ? ? ? ?-lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd > -lcxsparse > /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: > QR::raw > QR::std > QR::economy > collect2: ld returned 1 exit status > make[2]: *** [qr.oct] Error 1 > make[1]: *** [src] Error 2 > make: *** [all] Error 2 > > In which library should these symbols be defined? > > My source version is > > ? bash$ hg tip > ? changeset: ? 9733:aab4f2aa9ed9 > ? tag: ? ? ? ? tip > ? user: ? ? ? ?Jaroslav Hajek > ? date: ? ? ? ?Fri Oct 16 13:13:36 2009 +0200 > ? summary: ? ? make ismember more matlab compatible > > Thanks for help, > > ? Thomas > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > This patch should fix it. Apparently Savannah is down (at least I can't connect to it), so I'll upload it later. However, I though that namespace-level definition of static integral & enum member constants is not required by the C++ standard. I'll check, but maybe it's a compiler bug. hth -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz diff --git a/liboctave/dbleQR.cc b/liboctave/dbleQR.cc --- a/liboctave/dbleQR.cc +++ b/liboctave/dbleQR.cc @@ -84,6 +84,8 @@ #endif } +const QR::type QR::raw, QR::std, QR::economy; + QR::QR (const Matrix& a, qr_type_t qr_type) { init (a, qr_type); From Thomas.Treichl at gmx.net Fri Oct 16 15:10:29 2009 From: Thomas.Treichl at gmx.net (Thomas Treichl) Date: Fri, 16 Oct 2009 22:10:29 +0200 Subject: Undefined symbols: QR::raw, QR::std, QR::economy In-Reply-To: <69d8d540910161247u120325c3n5ce0ba9575416964@mail.gmail.com> References: <4AD8C23F.1080001@gmx.net> <69d8d540910161247u120325c3n5ce0ba9575416964@mail.gmail.com> Message-ID: <4AD8D335.1070900@gmx.net> Jaroslav Hajek schrieb: > On Fri, Oct 16, 2009 at 8:58 PM, Thomas Treichl wrote: >> Hi, >> >> on my Mac 10.4 I have the following problem for a while that: >> >> g++ -bundle -bundle_loader ../src/octave >> -L/Applications/Octave.app/Contents/Resources/lib >> -Wl,-headerpad_max_install_names -Wl,-syslibroot >> -Wl,/Developer/SDKs/MacOSX10.4u.sdk -Wl,-lexpat -o qr.oct pic/qr.o >> -L/Applications/Octave.app/Contents/Resources/lib >> -Wl,-headerpad_max_install_names -Wl,-syslibroot >> -Wl,/Developer/SDKs/MacOSX10.4u.sdk -Wl,-lexpat -L. -loctinterp -L../liboctave >> -loctave -L../libcruft -lcruft -lfftw3 -lfftw3f -lhdf5 -lz >> -L/tmp/deps-i386/lib -lfontconfig -lftgl -L/tmp/deps-i386/lib -lfreetype >> -Wl,-framework -Wl,OpenGL -Wl,-framework -Wl,Carbon -lreadline -lncurses >> -Wl,-framework -Wl,vecLib >> -L/Applications/Octave.app/Contents/Resources/lib/gcc-lib/i386-apple-darwin8.11.1/4.0.3 >> -lf95 -lm -lqrupdate -lcholmod -lumfpack -lamd -lcamd -lcolamd >> -lccolamd -lcxsparse -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd >> -lcxsparse >> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: >> QR::raw >> QR::std >> QR::economy >> collect2: ld returned 1 exit status >> make[2]: *** [qr.oct] Error 1 >> make[1]: *** [src] Error 2 >> make: *** [all] Error 2 >> >> In which library should these symbols be defined? >> >> My source version is >> >> bash$ hg tip >> changeset: 9733:aab4f2aa9ed9 >> tag: tip >> user: Jaroslav Hajek >> date: Fri Oct 16 13:13:36 2009 +0200 >> summary: make ismember more matlab compatible >> >> Thanks for help, >> >> Thomas >> _______________________________________________ >> Bug-octave mailing list >> Bug-octave at octave.org >> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave >> > > This patch should fix it. Apparently Savannah is down (at least I > can't connect to it), so I'll upload it later. > However, I though that namespace-level definition of static integral & > enum member constants is not required by the C++ standard. I'll check, > but maybe it's a compiler bug. > > hth This works very well, Jaroslav. Thank you very much, Thomas From octave at nomad.inbox5.com Fri Oct 16 18:01:08 2009 From: octave at nomad.inbox5.com (Rik) Date: Fri, 16 Oct 2009 16:01:08 -0700 Subject: Feature request : Engineering format for display Message-ID: 10/16/09 The target user for most of Octave is scientists and engineers. The scientists can already display results in their favorite format, scientific notation. Engineers, however, have to make due with scientific notation. As an electrical engineer I do a lot of work with kiloohms and megaohms and it would be much more convenient if I could display results in an engineering format (mantissa + exponent where the exponent is a multiple of 3). I realize the C++ stream libraries don't naturally support engineering format, but a look at the code in pr-output.cc seems like it should be possible to insert a routine that does the work before passing it on to the output. Not that it matters, but Matlab has figured it out and 'format eng' is an accepted command (http://www.mathworks.com/access/helpdesk/help/techdoc/ref/format.html). --Rik From prawlins at microseismic.com Fri Oct 16 15:22:57 2009 From: prawlins at microseismic.com (pgr) Date: Fri, 16 Oct 2009 13:22:57 -0700 (PDT) Subject: Cannot compile octave-3.2.2 on RHEL5 In-Reply-To: <8CBF24EA3805A88-1068-8F46@webmail-dh24.sysops.aol.com> References: <8CBF24EA3805A88-1068-8F46@webmail-dh24.sysops.aol.com> Message-ID: <25931779.post@talk.nabble.com> gbohannon wrote: > > To: bug at octave.org > Cc: gbohannon > Subject: Cannot compile octave-3.2.2 on RHEL5 > -------- > Bug report for Octave 3.0.1 configured for x86_64-unknown-linux-gnu > > Description: > ----------- > > I have octave 3.0.1 installed and it works fine. I am trying to install > 3.2.2 from source. > This is a Red Hat Enterprise Linux 5 system, and I believe it is up to > date. > > I first run configure, then make. After compiling for a while, it stops > with this message: > > gcc -c -I/usr/include/freetype2 -I. -I.. -I../liboctave -I../src > -I../libcruft/misc? -DHAVE_CONFIG_H? -Wall -W -Wshadow -Wformat -g -O2 > main.c -o main.o > g++ -I/usr/include/freetype2 -I. -I.. -I../liboctave -I../src > -I../libcruft/misc? -DHAVE_CONFIG_H? -Wall -W -Wshadow -Wold-style-cast > -Wformat -g -O2 -I/usr/include/freetype2 -rdynamic \ > ??????? -L..? -fPIC? -o octave \ > ??????? main.o? \ > ??????? -L../liboctave -L../libcruft -L../src -Wl,-rpath > -Wl,/usr/local/lib/octave-3.2.2 \ > ??????? -loctinterp -loctave? -lcruft?? \ > ???????????? \ > ??????????? \ > ?????????? -L/usr/X11R6/lib -lGL -lGLU \ > ??????? -L/usr/lib64 -lX11? -lreadline? -lncurses -ldl -lz -lm? -lfreetype > -L/usr/X11R6/lib -lGL -lGLU -L/usr/X11R6/lib -L./../lib64 -L. > -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6 > -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64 > -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../.. -L/lib/../lib64 > -L/usr/lib/../lib64 -lz -lfrtbegin -lg2c -lm -lfreetype -lGL -lGLU > ../src/liboctinterp.so: undefined reference to `std::basic_istream std::char_traits >::ignore()' > ../src/liboctinterp.so: undefined reference to `__cxa_get_exception_ptr' > collect2: ld returned 1 exit status > make[2]: *** [octave] Error 1 > make[2]: Leaving directory `/usr/local/octave-3.2.2/src' > make[1]: *** [src] Error 2 > make[1]: Leaving directory `/usr/local/octave-3.2.2' > make: *** [all] Error 2 > [root at Daisy octave-3.2.2] > > > > Repeat-By: > --------- > > configure > make > > > Configuration (please do not edit this section): > ----------------------------------------------- > > uname output:???? Linux Daisy 2.6.18-128.2.1.el5 #1 SMP Wed Jul 8 11:54:47 > EDT 2009 x86_64 x86_64 x86_64 GNU/Linux > configure opts:?? 'F77=gfortran' > Fortran compiler: gfortran > FFLAGS:?????????? -O > F2C:????????????? @F2C@ > F2CFLAGS:???????? @F2CFLAGS@ > FLIBS:??????????? -L. -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 > -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 > -L/usr/lib/../lib64 -lz -lgfortranbegin -lgfortran -lm > CPPFLAGS:??????? ? > INCFLAGS:???????? -I. -I. -I./liboctave -I./src -I./libcruft/misc > C compiler:?????? gcc, version 4.1.2 20070626 (Red Hat 4.1.2-14) > CFLAGS:?????????? -g -O2 > CPICFLAG:???????? -fPIC > C++ compiler:???? g++, version 4.1.2 > CXXFLAGS:???????? -g -O2 > CXXPICFLAG:?????? -fPIC > LD_CXX:?????????? g++ > LDFLAGS:???????? ? > LIBFLAGS:???????? -L. > RLD_FLAG:???????? -Wl,-rpath -Wl,/usr/local/lib/octave-3.0.1 > BLAS_LIBS:?????? ? > FFTW_LIBS:?????? ? > LIBS:???????????? -lreadline? -lncurses -ldl -lz -lm > LEXLIB:????????? ? > LIBGLOB:???????? ? > SED:????????????? /bin/sed > DEFS: > > ? -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" > ? -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 > ? -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > -DHAVE_SYS_STAT_H=1 > ? -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 > ? -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSEPCHAR=':' > ? -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 > ? -DCXX_ISO_COMPLIANT_LIBRARY=1 -DCXX_ABI=gnu_v3 -DHAVE_LIBM=1 > -DHAVE_PCRE=1 > ? -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 > ? -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_IEEE754_DATA_FORMAT=1 > ? -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name > ? ## _ -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 > ? -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 > ? -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 > ? -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 > ? -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos > ? -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 > ? -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 > ? -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 > ? -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 > ? -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 > ? -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 > ? -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 > ? -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 > ? -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 > ? -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 > ? -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 > ? -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 > ? -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 > ? -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 > ? -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 > ? -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 > ? -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 > ? -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 > ? -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 > ? -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 > ? -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 > ? -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 > ? -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 > ? -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUND=1 > ? -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 > ? -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 > ? -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 > ? -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 > ? -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 > ? -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMA=1 > ? -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 > ? -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 > ? -DHAVE_WAITPID=1 -DHAVE_STRFTIME=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 > ? -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 > ? -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 > ? -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 > ? -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1 -DHAVE_ERF=1 -DHAVE_ERFC=1 > ? -DHAVE_EXP2=1 -DHAVE_LOG2=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 > ? -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 > ? -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 > ? -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 > ? -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 > ? -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot" > > User-preferences (please do not edit this section): > -------------------------------------------------- > > ? EDITOR = emacs > ? EXEC_PATH = > /usr/local/libexec/octave/3.0.1/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/api-v32/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/3.0.1/exec/x86_64-unknown-linux-gnu:/usr/local/bin:/usr/local/openmpi/bin:./:/home/gbohannon:/usr/local/openmpi/bin:./:/home/gbohannon:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/gbohannon/bin > ? IMAGE_PATH = .:/usr/local/share/octave/3.0.1/imagelib > ? PAGER = less > ? PS1 = \s:\#> > ? PS2 = > > ? PS4 = + > ? beep_on_error = 0 > ? completion_append_char = ? > ? crash_dumps_octave_core = 1 > ? echo_executing_commands = 0 > ? fixed_point_format = 0 > ? gnuplot_binary = gnuplot > ? gnuplot_command_end = > > ? gnuplot_command_plot = pl > ? gnuplot_command_replot = rep > ? gnuplot_command_splot = sp > ? gnuplot_command_title = t > ? gnuplot_command_using = u > ? gnuplot_command_with = w > ? history_file = /home/gbohannon/.octave_hist > ? history_size = 1024 > ? ignore_function_time_stamp = system > ? info_file = /usr/local/share/info/octave.info > ? info_program = info > ? makeinfo_program = makeinfo > ? max_recursion_depth = 256 > ? output_max_field_width = 5 > ? output_precision = 5 > ? page_output_immediately = 0 > ? page_screen_output = 1 > ? print_answer_id_name = 1 > ? print_empty_dimensions = 1 > ? save_precision = 16 > ? saving_history = 1 > ? sighup_dumps_octave_core = 1 > ? sigterm_dumps_octave_core = 1 > ? silent_functions = 0 > ? split_long_rows = 1 > ? string_fill_char = ? > ? struct_levels_to_print = 2 > ? suppress_verbose_help_message = 0 > > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > > I had the same problem and found that configure was latching on to an old fortran compiler that was on my system. I got rid of it and set the F77 environment variable to fgortran (my current fortran compiler) and the problem went away. -- View this message in context: http://www.nabble.com/Cannot-compile-octave-3.2.2-on-RHEL5-tp25118156p25931779.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From tmacchant at yahoo.co.jp Sat Oct 17 01:54:43 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sat, 17 Oct 2009 15:54:43 +0900 (JST) Subject: bug? of gnuplot_drawnow.m (unknown property "__pixels_per_inch__") In-Reply-To: <23A80539-6005-4C34-8D5A-E425C23E4063@mac.com> Message-ID: <20091017065447.95912.qmail@web3805.mail.bbt.yahoo.co.jp> Hello --- Ben Abbott wrote: > I already responded to the other thread, so I apologize for the > duplication here. I think it is a bug (one of mine actually). > > For me, the changeset produces an output equivalent the size specified > by papersize, with the contents of the figure placed in the area > specified by paperposition. > > Tatsuro, do you see the same thing (my sources are a bit out of date). Yes, I saw the same thing. And patch I proposed has a serious problem. Only the error will not occur is easy. However, it will be laborious work if one want the graph output is equal to that by print command of 'default' setting. In the help of drawnow, calling form 'drawnow (TERM, FILE, MONO, DEBUG_FILE)' is for debugging. Should the difference of output between drawnow (TERM, FILE, MONO, DEBUG_FILE) and print(filename, -dDEVICE) at default condition be eliminated? If it should be eliminated, I do not enough time to to do it at present. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From lukas.reichlin at swissonline.ch Sun Oct 18 07:44:01 2009 From: lukas.reichlin at swissonline.ch (Lukas Reichlin) Date: Sun, 18 Oct 2009 14:44:01 +0200 Subject: octave-3.2.3: krylov.m: missing function "swap" Message-ID: <8F05F4F1-5685-48B6-90B3-E4B51180E5B9@swissonline.ch> Dear Octave Community I noticed that the file krylov.m http://hg.savannah.gnu.org/hgweb/octave/file/9bc642ea9006/scripts/linear-algebra/krylov.m uses a trivial function called swap.m. This function has been moved to the control package. Therefore, krylov won't work unless the control package is installed. As a fix, I added the swap routine at the end of the krylov m-file. Could someone with the necessary rights please commit the change? The new file is attached to this mail. Regards, Lukas -------------- next part -------------- A non-text attachment was scrubbed... Name: krylov.m Type: application/octet-stream Size: 6673 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091018/c6eca195/attachment.obj From tantumquantum+gnuoctave at gmail.com Sun Oct 18 15:15:41 2009 From: tantumquantum+gnuoctave at gmail.com (Carsten Clark) Date: Sun, 18 Oct 2009 16:15:41 -0400 Subject: Cannot compile octave-3.2.2 on RHEL5 In-Reply-To: <25931779.post@talk.nabble.com> References: <8CBF24EA3805A88-1068-8F46@webmail-dh24.sysops.aol.com> <25931779.post@talk.nabble.com> Message-ID: <296b57e10910181315s777c03k8afc01f0a9166f24@mail.gmail.com> 2009/10/16 pgr : > > gbohannon wrote: >> >> To: bug at octave.org >> Cc: gbohannon >> Subject: Cannot compile octave-3.2.2 on RHEL5 >> -------- >> Bug report for Octave 3.0.1 configured for x86_64-unknown-linux-gnu >> >> Description: >> ----------- >> >> I have octave 3.0.1 installed and it works fine. I am trying to install >> 3.2.2 from source. >> This is a Red Hat Enterprise Linux 5 system, and I believe it is up to >> date. >> >> I first run configure, then make. After compiling for a while, it stops >> with this message: >> >> gcc -c -I/usr/include/freetype2 -I. -I.. -I../liboctave -I../src >> -I../libcruft/misc? -DHAVE_CONFIG_H? -Wall -W -Wshadow -Wformat -g -O2 >> main.c -o main.o >> g++ -I/usr/include/freetype2 -I. -I.. -I../liboctave -I../src >> -I../libcruft/misc? -DHAVE_CONFIG_H? -Wall -W -Wshadow -Wold-style-cast >> -Wformat -g -O2 -I/usr/include/freetype2 -rdynamic \ >> ??????? -L..? -fPIC? -o octave \ >> ??????? main.o? \ >> ??????? -L../liboctave -L../libcruft -L../src -Wl,-rpath >> -Wl,/usr/local/lib/octave-3.2.2 \ >> ??????? -loctinterp -loctave? -lcruft?? \ >> ???????????? \ >> ??????????? \ >> ?????????? -L/usr/X11R6/lib -lGL -lGLU \ >> ??????? -L/usr/lib64 -lX11? -lreadline? -lncurses -ldl -lz -lm? -lfreetype >> -L/usr/X11R6/lib -lGL -lGLU -L/usr/X11R6/lib -L./../lib64 -L. >> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6 >> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64 >> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../.. -L/lib/../lib64 >> -L/usr/lib/../lib64 -lz -lfrtbegin -lg2c -lm -lfreetype -lGL -lGLU >> ../src/liboctinterp.so: undefined reference to `std::basic_istream> std::char_traits >::ignore()' >> ../src/liboctinterp.so: undefined reference to `__cxa_get_exception_ptr' >> collect2: ld returned 1 exit status >> make[2]: *** [octave] Error 1 >> make[2]: Leaving directory `/usr/local/octave-3.2.2/src' >> make[1]: *** [src] Error 2 >> make[1]: Leaving directory `/usr/local/octave-3.2.2' >> make: *** [all] Error 2 >> [root at Daisy octave-3.2.2] >> >> >> >> Repeat-By: >> --------- >> >> configure >> make >> >> >> Configuration (please do not edit this section): >> ----------------------------------------------- >> >> uname output:???? Linux Daisy 2.6.18-128.2.1.el5 #1 SMP Wed Jul 8 11:54:47 >> EDT 2009 x86_64 x86_64 x86_64 GNU/Linux >> configure opts:?? 'F77=gfortran' >> Fortran compiler: gfortran >> FFLAGS:?????????? -O >> F2C:????????????? @F2C@ >> F2CFLAGS:???????? @F2CFLAGS@ >> FLIBS:??????????? -L. -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 >> -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 >> -L/usr/lib/../lib64 -lz -lgfortranbegin -lgfortran -lm >> CPPFLAGS:??????? ? >> INCFLAGS:???????? -I. -I. -I./liboctave -I./src -I./libcruft/misc >> C compiler:?????? gcc, version 4.1.2 20070626 (Red Hat 4.1.2-14) >> CFLAGS:?????????? -g -O2 >> CPICFLAG:???????? -fPIC >> C++ compiler:???? g++, version 4.1.2 >> CXXFLAGS:???????? -g -O2 >> CXXPICFLAG:?????? -fPIC >> LD_CXX:?????????? g++ >> LDFLAGS:???????? ? >> LIBFLAGS:???????? -L. >> RLD_FLAG:???????? -Wl,-rpath -Wl,/usr/local/lib/octave-3.0.1 >> BLAS_LIBS:?????? ? >> FFTW_LIBS:?????? ? >> LIBS:???????????? -lreadline? -lncurses -ldl -lz -lm >> LEXLIB:????????? ? >> LIBGLOB:???????? ? >> SED:????????????? /bin/sed >> DEFS: >> >> ? -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" >> ? -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 >> ? -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 >> -DHAVE_SYS_STAT_H=1 >> ? -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 >> ? -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSEPCHAR=':' >> ? -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 >> ? -DCXX_ISO_COMPLIANT_LIBRARY=1 -DCXX_ABI=gnu_v3 -DHAVE_LIBM=1 >> -DHAVE_PCRE=1 >> ? -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 >> ? -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_IEEE754_DATA_FORMAT=1 >> ? -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name >> ? ## _ -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 >> ? -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 >> ? -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 >> ? -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 >> ? -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos >> ? -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 >> ? -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 >> ? -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 >> ? -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 >> ? -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 >> ? -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 >> ? -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 >> ? -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 >> ? -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 >> ? -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 >> ? -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 >> ? -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 >> ? -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 >> ? -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 >> ? -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 >> ? -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 >> ? -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 >> ? -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 >> ? -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 >> ? -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 >> ? -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 >> ? -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 >> ? -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 >> ? -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUND=1 >> ? -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 >> ? -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 >> ? -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 >> ? -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 >> ? -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 >> ? -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMA=1 >> ? -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 >> ? -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 >> ? -DHAVE_WAITPID=1 -DHAVE_STRFTIME=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 >> ? -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 >> ? -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 >> ? -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 >> ? -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1 -DHAVE_ERF=1 -DHAVE_ERFC=1 >> ? -DHAVE_EXP2=1 -DHAVE_LOG2=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 >> ? -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 >> ? -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 >> ? -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 >> ? -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 >> ? -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot" >> >> User-preferences (please do not edit this section): >> -------------------------------------------------- >> >> ? EDITOR = emacs >> ? EXEC_PATH = >> /usr/local/libexec/octave/3.0.1/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/api-v32/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/3.0.1/exec/x86_64-unknown-linux-gnu:/usr/local/bin:/usr/local/openmpi/bin:./:/home/gbohannon:/usr/local/openmpi/bin:./:/home/gbohannon:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/gbohannon/bin >> ? IMAGE_PATH = .:/usr/local/share/octave/3.0.1/imagelib >> ? PAGER = less >> ? PS1 = \s:\#> >> ? PS2 = > >> ? PS4 = + >> ? beep_on_error = 0 >> ? completion_append_char = ? >> ? crash_dumps_octave_core = 1 >> ? echo_executing_commands = 0 >> ? fixed_point_format = 0 >> ? gnuplot_binary = gnuplot >> ? gnuplot_command_end = >> >> ? gnuplot_command_plot = pl >> ? gnuplot_command_replot = rep >> ? gnuplot_command_splot = sp >> ? gnuplot_command_title = t >> ? gnuplot_command_using = u >> ? gnuplot_command_with = w >> ? history_file = /home/gbohannon/.octave_hist >> ? history_size = 1024 >> ? ignore_function_time_stamp = system >> ? info_file = /usr/local/share/info/octave.info >> ? info_program = info >> ? makeinfo_program = makeinfo >> ? max_recursion_depth = 256 >> ? output_max_field_width = 5 >> ? output_precision = 5 >> ? page_output_immediately = 0 >> ? page_screen_output = 1 >> ? print_answer_id_name = 1 >> ? print_empty_dimensions = 1 >> ? save_precision = 16 >> ? saving_history = 1 >> ? sighup_dumps_octave_core = 1 >> ? sigterm_dumps_octave_core = 1 >> ? silent_functions = 0 >> ? split_long_rows = 1 >> ? string_fill_char = ? >> ? struct_levels_to_print = 2 >> ? suppress_verbose_help_message = 0 >> >> >> _______________________________________________ >> Bug-octave mailing list >> Bug-octave at octave.org >> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave >> >> > > > I had the same problem and found that configure was latching on to an old > fortran compiler that was on my system. I got rid of it and set the F77 > environment variable to fgortran (my current fortran compiler) and the > problem went away. Ditto pgr. Early this May, I had GCC 3 and GCC 4 installed on Solaris, with GCC 4 first in my PATH. When I ran configure without arguments, configure found g77, part of my GCC 3 installation, rather than gfortran, which is present in GCC 4. This led to a failure to link the octave executable because the FLIBS set in response to finding g77 included -L paths that pointed GCC 4's linker to GCC 3's libstdc++.so. I managed to work around this in three ways: 1. Configure with F77 set to gfortran or Sun f77 2. Configure with LDFLAGS=-L/usr/local/gcc4/lib 3. Manually prepend -L/usr/local/gcc4/lib to FLIBS in $(TOPDIR)/Makeconf I was looking for a fix and then ran out of time and forgot about this -- sorry! I no longer have GCC 3, so I can't check if this problem still exists in the development sources. Carsten Clark From tantumquantum at gmail.com Sun Oct 18 14:34:45 2009 From: tantumquantum at gmail.com (Carsten Clark) Date: Sun, 18 Oct 2009 15:34:45 -0400 Subject: Changeset to remove ArrayN.cc from liboctave/Makefile.in Message-ID: <296b57e10910181234x655ea658u9bb5541e6285db84@mail.gmail.com> Hello, ArrayN.cc was deleted on Oct 16 but was still mentioned in liboctave/Makefile.in. This seemed to break my build immediately after I updated, but on trying again all I got was a harmless error message during "make install" about ArrayN.cc not existing. At any rate, I've attached a changeset that removes the mention of ArrayN.cc in liboctave/Makefile.in. Regards, Carsten Clark -------------- next part -------------- # HG changeset patch # User Carsten Clark # Date 1255881684 14400 # Node ID a141154ee825343b4a0fc3dd7a56e97c9be0a8c3 # Parent 9bc642ea9006ca86fe502e02e65568535169f807 Remove ArrayN.cc from Makefile.in diff -r 9bc642ea9006 -r a141154ee825 liboctave/ChangeLog --- a/liboctave/ChangeLog Sun Oct 18 11:38:33 2009 +0200 +++ b/liboctave/ChangeLog Sun Oct 18 12:01:24 2009 -0400 @@ -1,3 +1,7 @@ +2009-10-18 Carsten Clark + + * Makefile.in: Remove ArrayN.cc. + 2009-10-18 Jaroslav Hajek * Makefile.in: Include base-qr.h and base-qr.cc. diff -r 9bc642ea9006 -r a141154ee825 liboctave/Makefile.in --- a/liboctave/Makefile.in Sun Oct 18 11:38:33 2009 +0200 +++ b/liboctave/Makefile.in Sun Oct 18 12:01:24 2009 -0400 @@ -110,7 +110,7 @@ $(VX_OP_INC) \ $(SPARSE_MX_OP_INC) -TEMPLATE_SRC := Array.cc ArrayN.cc eigs-base.cc DiagArray2.cc \ +TEMPLATE_SRC := Array.cc eigs-base.cc DiagArray2.cc \ MArray.cc MArray2.cc MArrayN.cc MDiagArray2.cc \ base-lu.cc base-qr.cc oct-sort.cc sparse-base-lu.cc \ sparse-base-chol.cc sparse-dmsolve.cc From highegg at gmail.com Mon Oct 19 00:27:00 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 19 Oct 2009 07:27:00 +0200 Subject: Changeset to remove ArrayN.cc from liboctave/Makefile.in In-Reply-To: <296b57e10910181234x655ea658u9bb5541e6285db84@mail.gmail.com> References: <296b57e10910181234x655ea658u9bb5541e6285db84@mail.gmail.com> Message-ID: <69d8d540910182227m3b159876v4d183fb48a67d915@mail.gmail.com> On Sun, Oct 18, 2009 at 9:34 PM, Carsten Clark wrote: > Hello, > > ArrayN.cc was deleted on Oct 16 but was still mentioned in > liboctave/Makefile.in. ?This seemed to break my build immediately > after I updated, but on trying again all I got was a harmless error > message during "make install" about ArrayN.cc not existing. ?At any > rate, I've attached a changeset that removes the mention of ArrayN.cc > in liboctave/Makefile.in. > > Regards, > Carsten Clark > Oops. Apparently I deleted it from Makefile instead of Makefile.in. Patch applied. thanks -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From soren at hauberg.org Mon Oct 19 15:47:06 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Mon, 19 Oct 2009 22:47:06 +0200 Subject: 'interp2' isn't doing anything when called with 'cubic' or 'spline' Message-ID: <1255985226.4518.31.camel@sh-t400> Hi All The following code generates a synthetic image and rotates it: ## Generate a synthetic image and show it I = tril(ones(100)) + abs(rand(100)); I(I>1) = 1; I(20:30, 20:30) = !I(20:30, 20:30); I(70:80, 70:80) = !I(70:80, 70:80); ## Rotate the image around (0, 0) by -0.4 radians and show it [XI, YI] = meshgrid(1:100); R = [cos(-0.4) sin(-0.4); -sin(-0.4) cos(-0.4)]; RXY = [XI(:), YI(:)] * R; XI = reshape(RXY(:,1), [100, 100]); YI = reshape(RXY(:,2), [100, 100]); warped = interp2(I, XI, YI, "linear"); The result can be visualised using imshow (warped); However, if I change the interpolation method in the last line from "linear" to "cubic" or "spline", the resulting image is not rotated. S?ren From highegg at gmail.com Tue Oct 20 05:52:37 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 20 Oct 2009 12:52:37 +0200 Subject: 'interp2' isn't doing anything when called with 'cubic' or 'spline' In-Reply-To: <1255985226.4518.31.camel@sh-t400> References: <1255985226.4518.31.camel@sh-t400> Message-ID: <69d8d540910200352qb0e8920v52eceaa7ff30f6ce@mail.gmail.com> On Mon, Oct 19, 2009 at 10:47 PM, S?ren Hauberg wrote: > Hi All > > The following code generates a synthetic image and rotates it: > > ? ? ? ? ## Generate a synthetic image and show it > ? ? ? ? I = tril(ones(100)) + abs(rand(100)); I(I>1) = 1; > ? ? ? ? I(20:30, 20:30) = !I(20:30, 20:30); > ? ? ? ? I(70:80, 70:80) = !I(70:80, 70:80); > > ? ? ? ? ## Rotate the image around (0, 0) by -0.4 radians and show it > ? ? ? ? [XI, YI] = meshgrid(1:100); > ? ? ? ? R = [cos(-0.4) sin(-0.4); -sin(-0.4) cos(-0.4)]; > ? ? ? ? RXY = [XI(:), YI(:)] * R; > ? ? ? ? XI = reshape(RXY(:,1), [100, 100]); > ? ? ? ? YI = reshape(RXY(:,2), [100, 100]); > ? ? ? ? warped = interp2(I, XI, YI, "linear"); > > The result can be visualised using > > ? ? imshow (warped); > > However, if I change the interpolation method in the last line from > "linear" to "cubic" or "spline", the resulting image is not rotated. > > S?ren > Line 345 in interp2.m says it all: ## FIXME bicubic/__splinen__ don't handle arbitrary XI, YI apparently bicubic/__splinen__ only handle XI, YI in a meshgrid format (i.e. axes-algned cartesian grid). It would be nice to add a check here (or implement the missing functionality). Note that the "pchip" method doesn't have this limitation, so you may use that if you're in need of a cubic interpolation. hth -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From amitsaha.in at gmail.com Tue Oct 20 07:46:54 2009 From: amitsaha.in at gmail.com (Amit Saha) Date: Tue, 20 Oct 2009 18:16:54 +0530 Subject: Missing Title in User Guide Message-ID: <547db2260910200546x67f69135o4406f6ab757fd93a@mail.gmail.com> Hello, The page: http://www.gnu.org/software/octave/doc/interpreter/ has got "Untitled" as its title. Pls. note it for a future fix. -Amit -- Journal: http://amitksaha.wordpress.com, ?-blog: http://twitter.com/amitsaha Freenode: cornucopic in #scheme, #lisp, #math,#linux, #python From thomas.weber.mail at gmail.com Tue Oct 20 13:14:57 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Tue, 20 Oct 2009 20:14:57 +0200 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <1255615770.20678.21.camel@karaba.cepremap.org> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> Message-ID: <20091020181457.GA11996@atlan> Hi, On Thu, Oct 15, 2009 at 02:09:30PM +0000, S?bastien Villemot wrote: > Hi, > > I think I found the culprit for what I thought was a race condition in > Octave. > > The problem has to do with the way Octave 3.2 updates its load-path: it > only updates its cache of the current directory if the modification time > of the directory changes (see load_path::dir_info::update() in > src/load-path.cc). In case it's not clear: this is a real problem and not some artificially found issue. It makes software using Octave randomly fail at build time. Thomas From soren at hauberg.org Tue Oct 20 13:27:01 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Tue, 20 Oct 2009 20:27:01 +0200 Subject: 'interp2' isn't doing anything when called with 'cubic' or 'spline' In-Reply-To: <69d8d540910200352qb0e8920v52eceaa7ff30f6ce@mail.gmail.com> References: <1255985226.4518.31.camel@sh-t400> <69d8d540910200352qb0e8920v52eceaa7ff30f6ce@mail.gmail.com> Message-ID: <1256063221.4500.5.camel@sh-t400> tir, 20 10 2009 kl. 12:52 +0200, skrev Jaroslav Hajek: > Line 345 in interp2.m says it all: > ## FIXME bicubic/__splinen__ don't handle arbitrary XI, YI > apparently bicubic/__splinen__ only handle XI, YI in a meshgrid format > (i.e. axes-algned cartesian grid). > > It would be nice to add a check here (or implement the missing functionality). I have a function in the 'image' package for doing bicubic interpolation when X and Y have meshgrid format. The attached changeset moves this code into 'interp2' such that we also support this case. I also added the checks you mentioned. > Note that the "pchip" method doesn't have this limitation, so you may > use that if you're in need of a cubic interpolation. Oh, I didn't know that was implemented; the documentation explicitly states the opposite. The attached changeset also removes this comment in the help text. S?ren P.S. Shouldn't the 'bicubic' function be private or part of 'interp2'? I think the actual user interface for this code should be 'interp2'. -------------- next part -------------- # HG changeset patch # User Soren Hauberg # Date 1256062930 -7200 # Node ID 584ca012b9e84ea469447e43650b48c4ca315ce5 # Parent 7bda650b691a21434cddb2452a0fbc77c558a9ca general/interp2.m: improved error checking and support for bicubic interpolation when X and Y are meshgrid format diff -r 7bda650b691a -r 584ca012b9e8 scripts/ChangeLog --- a/scripts/ChangeLog Tue Oct 20 15:45:09 2009 +0200 +++ b/scripts/ChangeLog Tue Oct 20 20:22:10 2009 +0200 @@ -1,3 +1,8 @@ +2009-10-20 Soren Hauberg + + * general/interp2.m: improved error checking and support for bicubic + interpolation when X and Y are meshgrid format. + 2009-10-19 Soren Hauberg * io/strread.m, io/textread.m: New functions. diff -r 7bda650b691a -r 584ca012b9e8 scripts/general/interp2.m --- a/scripts/general/interp2.m Tue Oct 20 15:45:09 2009 +0200 +++ b/scripts/general/interp2.m Tue Oct 20 20:22:10 2009 +0200 @@ -57,7 +57,7 @@ ## @item 'linear' ## Linear interpolation from nearest neighbors. ## @item 'pchip' -## Piece-wise cubic hermite interpolating polynomial (not implemented yet). +## Piece-wise cubic hermite interpolating polynomial. ## @item 'cubic' ## Cubic interpolation from four nearest neighbors. ## @item 'spline' @@ -344,11 +344,64 @@ ## FIXME bicubic/__splinen__ don't handle arbitrary XI, YI if (strcmp (method, "cubic")) - ZI = bicubic (X, Y, Z, XI(1,:), YI(:,1), extrapval); + if (isgriddata (XI) && isgriddata (YI')) + ZI = bicubic (X, Y, Z, XI (1, :), YI (:, 1), extrapval); + elseif (isgriddata (X) && isgriddata (Y')) + ## Allocate output + ZI = zeros (size (X)); + + ## Find inliers + inside = !(XI < X (1) | XI > X (end) | YI < Y (1) | YI > Y (end)); + + ## Scale XI and YI to match indices of Z + XI = (columns (Z) - 1) * (XI - X (1)) / (X (end) - X (1)) + 1; + YI = (rows (Z) - 1) * (YI - Y (1)) / (Y (end) - Y (1)) + 1; + + ## Start the real work + K = floor (XI); + L = floor (YI); + + ## Coefficients + AY1 = bc ((YI - L + 1)); + AX1 = bc ((XI - K + 1)); + AY0 = bc ((YI - L + 0)); + AX0 = bc ((XI - K + 0)); + AY_1 = bc ((YI - L - 1)); + AX_1 = bc ((XI - K - 1)); + AY_2 = bc ((YI - L - 2)); + AX_2 = bc ((XI - K - 2)); + + ## Perform interpolation + sz = size(Z); + ZI = AY_2 .* AX_2 .* Z (sym_sub2ind (sz, L+2, K+2)) ... + + AY_2 .* AX_1 .* Z (sym_sub2ind (sz, L+2, K+1)) ... + + AY_2 .* AX0 .* Z (sym_sub2ind (sz, L+2, K)) ... + + AY_2 .* AX1 .* Z (sym_sub2ind (sz, L+2, K-1)) ... + + AY_1 .* AX_2 .* Z (sym_sub2ind (sz, L+1, K+2)) ... + + AY_1 .* AX_1 .* Z (sym_sub2ind (sz, L+1, K+1)) ... + + AY_1 .* AX0 .* Z (sym_sub2ind (sz, L+1, K)) ... + + AY_1 .* AX1 .* Z (sym_sub2ind (sz, L+1, K-1)) ... + + AY0 .* AX_2 .* Z (sym_sub2ind (sz, L, K+2)) ... + + AY0 .* AX_1 .* Z (sym_sub2ind (sz, L, K+1)) ... + + AY0 .* AX0 .* Z (sym_sub2ind (sz, L, K)) ... + + AY0 .* AX1 .* Z (sym_sub2ind (sz, L, K-1)) ... + + AY1 .* AX_2 .* Z (sym_sub2ind (sz, L-1, K+2)) ... + + AY1 .* AX_1 .* Z (sym_sub2ind (sz, L-1, K+1)) ... + + AY1 .* AX0 .* Z (sym_sub2ind (sz, L-1, K)) ... + + AY1 .* AX1 .* Z (sym_sub2ind (sz, L-1, K-1)); + ZI (!inside) = extrapval; + + else + error ("interp2: input data must have `meshgrid' format"); + endif elseif (strcmp (method, "spline")) - ZI = __splinen__ ({Y(:,1).', X(1,:)}, Z, {YI(:,1), XI(1,:)}, extrapval, + if (isgriddata (XI) && isgriddata (YI')) + ZI = __splinen__ ({Y(:,1).', X(1,:)}, Z, {YI(:,1), XI(1,:)}, extrapval, "spline"); + else + error ("interp2: input data must have `meshgrid' format"); + endif else error ("interpolation method not recognized"); endif @@ -356,6 +409,38 @@ endif endfunction +function b = isgriddata (X) + d1 = diff (X, 1, 1); + d2 = diff (X, 1, 2); + b = all (d1 (:) == 0) & all (d2 (:) == d2 (1)); +endfunction + +## Compute the bicubic interpolation coefficients +function o = bc(x) + x = abs(x); + o = zeros(size(x)); + idx1 = (x < 1); + idx2 = !idx1 & (x < 2); + o(idx1) = 1 - 2.*x(idx1).^2 + x(idx1).^3; + o(idx2) = 4 - 8.*x(idx2) + 5.*x(idx2).^2 - x(idx2).^3; +endfunction + +## This version of sub2ind behaves as if the data was symmetrically padded +function ind = sym_sub2ind(sz, Y, X) + Y (Y < 1) = 1 - Y (Y < 1); + while (any (Y (:) > 2 * sz (1))) + Y (Y > 2 * sz (1)) = round (Y (Y > 2 * sz (1)) / 2); + endwhile + Y (Y > sz (1)) = 1 + 2 * sz (1) - Y (Y > sz (1)); + X (X < 1) = 1 - X (X < 1); + while (any (X (:) > 2 * sz (2))) + X (X > 2 * sz (2)) = round (X (X > 2 * sz (2)) / 2); + endwhile + X (X > sz (2)) = 1 + 2 * sz (2) - X (X > sz (2)); + ind = sub2ind(sz, Y, X); +endfunction + + %!demo %! A=[13,-1,12;5,4,3;1,6,2]; %! x=[0,1,4]; y=[10,11,12]; From highegg at gmail.com Tue Oct 20 15:00:52 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 20 Oct 2009 22:00:52 +0200 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <20091020181457.GA11996@atlan> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> Message-ID: <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> 2009/10/20 Thomas Weber : > Hi, > > On Thu, Oct 15, 2009 at 02:09:30PM +0000, S?bastien Villemot wrote: >> Hi, >> >> I think I found the culprit for what I thought was a race condition in >> Octave. >> >> The problem has to do with the way Octave 3.2 updates its load-path: it >> only updates its cache of the current directory if the modification time >> of the directory changes (see load_path::dir_info::update() in >> src/load-path.cc). > > In case it's not clear: this is a real problem and not some artificially > found issue. It makes software using Octave randomly fail at build time. > > ? ? ? ?Thomas > I don't understand - what you mean by "build time"? Most software using Octave is not dynamically creating m-files, so is not affected. The problem is in load_path::update, which checks the directory's modification time to decide on whether to rescan it. The resolution is only in seconds, though. But some check is surely wanted because you want to avoid useless rescans. I don't have a better idea. One could even say this is a limitation of the system, which provides no way to tell whether the directory has changed during the last second. Maybe rehash() could ignore the stamp for some directories? But which ones? -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From soren at hauberg.org Tue Oct 20 15:34:12 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Tue, 20 Oct 2009 22:34:12 +0200 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> Message-ID: <1256070852.4500.24.camel@sh-t400> tir, 20 10 2009 kl. 22:00 +0200, skrev Jaroslav Hajek: > The problem is in load_path::update, which checks the directory's > modification time to decide on whether to rescan it. The resolution is > only in seconds, though. But some check is surely wanted because you > want to avoid useless rescans. I don't have a better idea. One could > even say this is a limitation of the system, which provides no way to > tell whether the directory has changed during the last second. Maybe > rehash() could ignore the stamp for some directories? But which ones? Perhaps it would be better to use a notification system instead of checking for file changes? Specifically, I'm thinking that we should be able to use, say, 'inotify' to notify us that a file has changed. When such a notification is sent Octave could then re-read the file. This would probably also be faster than the current approach of scanning for file changes. S?ren From jwe at octave.org Tue Oct 20 17:07:36 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 20 Oct 2009 18:07:36 -0400 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <1256070852.4500.24.camel@sh-t400> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> Message-ID: <19166.13480.894482.630735@segfault.lan> On 20-Oct-2009, S?ren Hauberg wrote: | tir, 20 10 2009 kl. 22:00 +0200, skrev Jaroslav Hajek: | > The problem is in load_path::update, which checks the directory's | > modification time to decide on whether to rescan it. The resolution is | > only in seconds, though. It is possible to get better resolution, but only for filesystems that support it. Currently, I'd guess that the most widely used filesystem on Linux systems is probably ext3, and that only has one second resolution for file time stamps. | But some check is surely wanted because you | > want to avoid useless rescans. I don't have a better idea. One could | > even say this is a limitation of the system, which provides no way to | > tell whether the directory has changed during the last second. Maybe | > rehash() could ignore the stamp for some directories? But which ones? | | Perhaps it would be better to use a notification system instead of | checking for file changes? Specifically, I'm thinking that we should be | able to use, say, 'inotify' to notify us that a file has changed. When | such a notification is sent Octave could then re-read the file. This | would probably also be faster than the current approach of scanning for | file changes. I agree that being notified of changes would be better than checking timestamps, but I don't think there is any portable way to be notified when a file changes. If possible, I'd rather avoid solutions that only work on some systems. The symbol table code already includes the following: octave_value symbol_table::fcn_info::fcn_info_rep::find (const octave_value_list& args, bool local_funcs) { octave_value retval = xfind (args, local_funcs); if (! retval.is_defined ()) { // It is possible that the user created a file on the fly since // the last prompt or chdir, so try updating the load path and // searching again. load_path::update (); retval = xfind (args, local_funcs); } return retval; } So if this is not sufficient, why not? Is it because update always checks the time stamp? In that case, maybe we need to have a "force" parameter to tell load_path::update to ignore the time stamp? That would make this update operation slow, but it would only happen when a symbol is not found the first time around, so I wouldn't expect it to be a big problem. jwe From storrsjm at email.uc.edu Tue Oct 20 18:49:39 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Tue, 20 Oct 2009 19:49:39 -0400 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <19166.13480.894482.630735@segfault.lan> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> <19166.13480.894482.630735@segfault.lan> Message-ID: If we're already keeping track of when we last read a directory/file, wouldn't it be easiest to make the comparison know about the tolerance? i.e. use something equivalent to if modtime + tolerance > cachetime reparse endif Then when the file/directory is older than the tolerance full caching would kick in? --judd -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091020/ea6e2baa/attachment.html From efrios at yahoo.com Tue Oct 20 12:58:31 2009 From: efrios at yahoo.com (Hielos) Date: Tue, 20 Oct 2009 10:58:31 -0700 (PDT) Subject: zenity_list: can't handle ( nor = Message-ID: <25979688.post@talk.nabble.com> Hello. I searched for "zenity_list" in the bugs' forum, but I didn't find anything. I am not looking for a solution. I just want to say that there is a bug in 'zenity_list': octave> zmsg = "Hello"; octave> zcols = {"Choice", " ", "Description"}; octave> zopts = {"TRUE", "FALSE";"1", "2";"f", "df/dx"}; octave> zenity_list(zmsg, zcols, zopts, "checklist", "all"); WORKS DOESN'T WORK: octave> zmsg = "Hello"; octave> zcols = {"Choice", " ", "Description"}; octave> zopts = {"TRUE", "FALSE";"1", "2";"f(x)", "df(x)/dx"}; octave> zenity_list(zmsg, zcols, zopts, "checklist", "all"); sh: Syntax error: "(" unexpected error: zenity_list: error: called from: error: /home/user/octave/zenity-0.5.7/zenity_list.m at line 103, column 5 DOESN'T WORK: octave> zmsg = "Hello"; octave> zcols = {"Choice", " ", "Description"}; octave> zopts = {"TRUE", "FALSE";"1", "2";"f=k", "df/dx"}; octave> zenity_list(zmsg, zcols, zopts, "checklist", "all"); (This one creates a very odd pop-up list) I hope this helps -- View this message in context: http://www.nabble.com/zenity_list%3A-can%27t-handle-%28-nor-%3D-tp25979688p25979688.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From walters at nps.edu Tue Oct 20 18:12:12 2009 From: walters at nps.edu (walters) Date: Tue, 20 Oct 2009 16:12:12 -0700 Subject: invalid use of script in index expression: plot X86-64 Message-ID: <4ADE43CC.2040400@nps.edu> Bug report for Octave 3.2.3 configured for x86_64-unknown-linux-gnu Description: ----------- octave-3.2.3:1> x=1:100; octave-3.2.3:2> plot(x) error: invalid use of script in index expression error: called from: error: /usr/local/share/octave/3.2.3/m/plot/__plt_get_axis_arg__.m at line 53, column 7 error: /usr/local/share/octave/3.2.3/m/plot/plot.m at line 178, column 18 octave-3.2.3:2> but using octave 3.0.5: octave:1> x=1:100; octave:2> plot(x) octave:3> Repeat-By: --------- * Please replace this item with a description of the sequence of events that causes the problem to occur. Fix: --- * If possible, replace this item with a description of how to fix the problem (if you don't have a fix for the problem, don't include this section, but please do submit your report anyway). Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux kbuntu 2.6.24-24-generic #1 SMP Fri Sep 18 16:16:18 UTC 2009 x86_64 GNU/Linux configure opts: Fortran compiler: g77 FFLAGS: -O FLIBS: -L/usr/X11R6/lib -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6 -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6/../../../../lib -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6/../../.. -L/lib/../lib -L/usr/lib/../lib -lhdf5 -lz -lfrtbegin -lg2c -lm -lfreetype -lGL -lGLU CPPFLAGS: -I/usr/local/include -I/usr/include/freetype2 INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.2.4 (Ubuntu 4.2.4-1ubuntu4) CFLAGS: -g -O2 CPICFLAG: -fPIC C++ compiler: g++, version 4.2.4 CXXFLAGS: -g -O2 -I/usr/include/freetype2 CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/local/lib/octave-3.2.3 BLAS_LIBS: -llapack -lblas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm -lfreetype -lz -L/usr/X11R6/lib -lGL -lGLU LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DHAVE_OPENGL=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __ -DHAVE_BLAS=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /usr/local/libexec/octave/3.2.3/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/api-v37/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/3.2.3/exec/x86_64-unknown-linux-gnu:/usr/local/bin:/usr/local/texlive/2008/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games IMAGE_PATH = .:/usr/local/share/octave/3.2.3/imagelib PAGER = less PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /home/walters/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/local/share/info/octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From highegg at gmail.com Tue Oct 20 23:53:08 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 21 Oct 2009 06:53:08 +0200 Subject: invalid use of script in index expression: plot X86-64 In-Reply-To: <4ADE43CC.2040400@nps.edu> References: <4ADE43CC.2040400@nps.edu> Message-ID: <69d8d540910202153l198cfebbod5908aa9c00adafb@mail.gmail.com> On Wed, Oct 21, 2009 at 1:12 AM, walters wrote: > Bug report for Octave 3.2.3 configured for x86_64-unknown-linux-gnu > > Description: > ----------- > octave-3.2.3:1> x=1:100; > octave-3.2.3:2> plot(x) > error: invalid use of script in index expression > error: called from: > error: ? /usr/local/share/octave/3.2.3/m/plot/__plt_get_axis_arg__.m at > line 53, column 7 > error: ? /usr/local/share/octave/3.2.3/m/plot/plot.m at line 178, column 18 > octave-3.2.3:2> > > but using octave 3.0.5: > > octave:1> x=1:100; > octave:2> plot(x) > octave:3> > > works for me. what does "which get" tell you? -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From sebastien.villemot at ens.fr Wed Oct 21 03:40:31 2009 From: sebastien.villemot at ens.fr (=?ISO-8859-1?Q?S=E9bastien?= Villemot) Date: Wed, 21 Oct 2009 10:40:31 +0200 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <19166.13480.894482.630735@segfault.lan> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> <19166.13480.894482.630735@segfault.lan> Message-ID: <1256114431.21402.2.camel@karaba.cepremap.org> Le mardi 20 octobre 2009 ? 18:07 -0400, John W. Eaton a ?crit : > The symbol table code already includes the following: > > octave_value > symbol_table::fcn_info::fcn_info_rep::find (const octave_value_list& args, > bool local_funcs) > { > octave_value retval = xfind (args, local_funcs); > > if (! retval.is_defined ()) > { > // It is possible that the user created a file on the fly since > // the last prompt or chdir, so try updating the load path and > // searching again. > > load_path::update (); > > retval = xfind (args, local_funcs); > } > > return retval; > } > > So if this is not sufficient, why not? Is it because update always > checks the time stamp? In that case, maybe we need to have a "force" > parameter to tell load_path::update to ignore the time stamp? That > would make this update operation slow, but it would only happen when a > symbol is not found the first time around, so I wouldn't expect it to > be a big problem. This solution sounds good to me. It should fix the problem I encounter with Dynare. Also note that this granularity problem doesn't occur with Octave 3.0. Something must have changed between the two releases, but I don't know what since I haven't gone through Octave 3.0 source code. Thanks, -- S?bastien Villemot From plonchampt at sonomat.com Tue Oct 20 23:49:51 2009 From: plonchampt at sonomat.com (Pierre Lonchampt) Date: Wed, 21 Oct 2009 15:49:51 +1100 Subject: Incompatibility MATLAB-OCTAVE : xcorr.m Message-ID: <4ADE92EF.3070002@sonomat.com> Hi I am currently trying to port an algorithm written for Matlab into Octave. On top of the usual and already documented discrepancies, I stumbled against the following one which took me a while to identify: When calling function [R, lags] = xcorr (X, Y, maxlag, scale) In octave, having maxlag longer than X returns an error message. In Matlab, that is perfectly OK and zeros are padded around of the correlation "center" when that is the case (and which is true mathematically-wise). I quickly tweaked the octave script in a ugly way to work "FOR MY APPLICATION ONLY". I attach it nevertheless as it may illustrate my point better than my words above. The tweak is between the comments starting with %PL. I am not sure whether you guys will consider this discrepancy to be a bug in either side, but in all cases it could be documented better somewhere. Regards and congrats for the great tool octave is! PS: this is true in both versions 3.0.1 and 3.2.3 compared with both matlab R11 and R12 (I don't know about more recent releases, nevertheless Mathworks documentation does not refer to Maxlag needing to be shorter than the input vetcor(s)... Hope it helps -- Pierre Lonchampt Product Development Manager Sonomedical Pty Ltd 10 Evans Street NSW 2041 Australia +61 2 8755 2626 (t) +61 2 8755 2699 (f) -------------- next part -------------- A non-text attachment was scrubbed... Name: xcorr.m Type: text/x-objcsrc Size: 9295 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091021/577acbbb/attachment-0001.bin From jwe at octave.org Wed Oct 21 09:01:53 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 21 Oct 2009 10:01:53 -0400 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> <19166.13480.894482.630735@segfault.lan> Message-ID: <19167.5201.437449.784544@segfault.lan> On 20-Oct-2009, Judd Storrs wrote: | If we're already keeping track of when we last read a | directory/file, No, we were keeping track of the timestamp on the directory, and then re-reading the list of files if the timestamp changed. But that fails for a sequence like system ("echo 1+1 > foo.m"); foo system ("echo 2+2 > bar.m"); bar if the second call to system doesn't change the time stamp due to limited resolution. | wouldn't it be easiest to make the comparison know about the tolerance? i.e. | use something equivalent to | | if modtime + tolerance > cachetime | reparse | endif | | Then when the file/directory is older than the tolerance full caching would | kick in? OK, this seems better than forcing all of the directories in the load path to be read again. So how about the following change? It seems to work for me. http://hg.savannah.gnu.org/hgweb/octave/rev/d6b2b708b6b0 jwe From storrsjm at email.uc.edu Wed Oct 21 10:49:44 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Wed, 21 Oct 2009 11:49:44 -0400 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <19167.5201.437449.784544@segfault.lan> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> <19166.13480.894482.630735@segfault.lan> <19167.5201.437449.784544@segfault.lan> Message-ID: I'm still looking to see if there's a generic way to determine the file-system time resolution. I have seen stated multiple places that FAT/FAT32 is limited to a time resolution of 2 seconds. For example http://docs.python.org/library/os.html#os.stat says: Note The exact meaning and resolution of the st_atime, st_mtime, and st_ctimemembers depends on the operating system and the file system. For example, on Windows systems using the FAT or FAT32 file systems, st_mtime has 2-second resolution, and st_atime has only 1-day resolution. See your operating system documentation for details. I'm not sure about the "on Windows" part--whether they mean that for example linux provides 1sec emulation for FAT drives? I haven't found any support for that yet. Because removable media often uses FAT, perhaps the default should be 2 sec? --judd -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091021/a6fc5659/attachment.html From kai.habel at gmx.de Thu Oct 22 07:12:35 2009 From: kai.habel at gmx.de (Kai Habel) Date: Thu, 22 Oct 2009 14:12:35 +0200 Subject: octave crash with repetitive 'clear functions' Message-ID: <4AE04C33.1050001@gmx.de> While playing with optiplux (optilux.sf.net) again, which is written for octave and matlab, I ran into problems. I could reduce the problem to the following example. When running myscript.m, which calls myfun.m octave dies with a segmentation fault at the second 'clear functions'. kai at LxLap:~/hg-octave/octave> cat myscript.m clear functions myfun clear functions kai at LxLap:~/hg-octave/octave> cat myfun.m function myfun function f1 function f2 kai at LxLap:~/hg-octave/octave> ./run-octave --silent adding ssprop to path adding optilux to path octave:1> myscript panic: Segmentation fault -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete Speicherzugriffsfehler kai at LxLap:~/hg-octave/octave> I have observed this with a recent tip (yesterday), but not with the mingw octave3.2.2 binary. Can someone confirm this crash? Attached is a backtrace of the crash: octave:1> myscript Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb577f9e0 (LWP 5227)] 0x00000004 in ?? () (gdb) bt #0 0x00000004 in ?? () #1 0xb692345c in do_clear_functions (argv=@0xbfaafac0, argc=2, idx=2, exclusive=192) at variables.cc:1936 #2 0xb6927ca8 in Fclear (args=@0x83cd200) at variables.cc:2073 #3 0xb6a1c2c7 in octave_builtin::do_multi_index_op (this=0x8110ae0, nargout=0, args=@0x83cd200) at ov-builtin.cc:107 #4 0xb6a1b2db in octave_builtin::subsref (this=0x8110ae0, type=@0xbfaafe08, idx=@0xbfaafdfc, nargout=0) at ov-builtin.cc:55 #5 0xb69d4ec8 in octave_value::subsref (this=0xbfaafe1c, type=@0xbfaafe08, idx=@0xbfaafdfc, nargout=0) at ov.cc:1173 #6 0xb6b00dfb in tree_index_expression::rvalue (this=0x843acc0, nargout=0) at pt-idx.cc:398 #7 0xb6b017f4 in tree_index_expression::rvalue1 (this=0x843acc0, nargout=0) at pt-idx.cc:409 #8 0xb6af2c21 in tree_evaluator::visit_statement (this=0xb71612cc, stmt=@0x843d0b0) at pt-eval.cc:695 #9 0xb6b186bb in tree_statement::accept (this=0x843d0b0, tw=@0xb71612cc) at pt-stmt.cc:152 #10 0xb6af1e6b in tree_evaluator::visit_statement_list (this=0xb71612cc, lst=@0x8419200) at pt-eval.cc:731 #11 0xb6b186db in tree_statement_list::accept (this=0x8419200, tw=@0xb71612cc) at pt-stmt.cc:216 #12 0xb6a24606 in octave_user_script::do_multi_index_op (this=0x81d6d18, nargout=0, args=@0xbfab0048) at ov-usr-fcn.cc:137 From chibaf at mac.com Thu Oct 22 07:52:44 2009 From: chibaf at mac.com (Fumihiro Chiba) Date: Thu, 22 Oct 2009 21:52:44 +0900 Subject: fzero BUG? on Octave 3.2.3 for ppc mac Message-ID: Hello, I use Octave.app 3.2.3 on Mac OS X 10.5.8 with a PowerPC machine. I try find a function of zeros using fzero. It seems that fzero does not work with the following function and initial data 1.0 or greater. Description: ---------------------------- The function is defined as follows: fun=inline('x^2 - 1 + exp(x)','x') I executed the following commands. octave-3.2.3:1> fun=inline('x^2 - 1 + exp(x)','x') fun = f(x) = x^2 - 1 + exp(x) octave-3.2.3:2> fzero(fun,1) error: fzero: zero point is not bracketed error: called from: error: /Applications/Octave.app/Contents/Resources/share/octave/ 3.2.3/m/optimization/fzero.m at line 255, column 1 octave-3.2.3:2> fzero(fun,-1) ans = -0.71456 octave-3.2.3:3> fzero(fun,[-0.2 1]) ans = 4.3520e-17 octave-3.2.3:4> fzero(fun,[-1 -0.2]) ans = -0.71456 octave-3.2.3:5> fzero(fun,0.1) ans = -2.9412e-18 octave-3.2.3:6> fzero(fun,0.5) ans = 4.2345e-17 octave-3.2.3:7> fzero(fun,0.8) ans = 6.1864e-17 octave-3.2.3:8> fzero(fun,0.999) ans = -1.4453e-17 octave-3.2.3:9> fzero(fun,1) error: fzero: zero point is not bracketed error: called from: error: /Applications/Octave.app/Contents/Resources/share/octave/ 3.2.3/m/optimization/fzero.m at line 255, column 1 octave-3.2.3:9> fzero(fun,1.1) error: fzero: not a valid initial bracketing error: called from: error: /Applications/Octave.app/Contents/Resources/share/octave/ 3.2.3/m/optimization/fzero.m at line 137, column 5 It seems that fzero does not work with initial data 1.0 or greater. Thanks, ----------------------- Fumihiro CHIBA From sebastien.villemot at ens.fr Thu Oct 22 09:18:31 2009 From: sebastien.villemot at ens.fr (=?ISO-8859-1?Q?S=E9bastien?= Villemot) Date: Thu, 22 Oct 2009 14:18:31 +0000 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <19167.5201.437449.784544@segfault.lan> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> <19166.13480.894482.630735@segfault.lan> <19167.5201.437449.784544@segfault.lan> Message-ID: <1256221111.21402.15.camel@karaba.cepremap.org> Le mercredi 21 octobre 2009 ? 10:01 -0400, John W. Eaton a ?crit : > OK, this seems better than forcing all of the directories in the load > path to be read again. So how about the following change? It seems > to work for me. > > http://hg.savannah.gnu.org/hgweb/octave/rev/d6b2b708b6b0 Applied on Octave 3.2.3, this patch solves the problem, in particular with Dynare. Many thanks, -- S?bastien Villemot From st.antons.hideout at gmail.com Thu Oct 22 05:30:57 2009 From: st.antons.hideout at gmail.com (=?ISO-8859-2?Q?Piotr_Sok=F3=B3?=) Date: Thu, 22 Oct 2009 12:30:57 +0200 Subject: wavread function bug Message-ID: <4AE03461.5070504@10g.pl> Hello, I found a bug in waveread function from audio toolbox: in line 172 there is variable "ck_size" and I suppose it should be "data_size". Best regards, Piotrek From jwe at octave.org Thu Oct 22 10:30:43 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 22 Oct 2009 11:30:43 -0400 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <1256221111.21402.15.camel@karaba.cepremap.org> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> <19166.13480.894482.630735@segfault.lan> <19167.5201.437449.784544@segfault.lan> <1256221111.21402.15.camel@karaba.cepremap.org> Message-ID: <19168.31395.338418.761998@segfault.lan> On 22-Oct-2009, S,Ai(Bbastien Villemot wrote: | Le mercredi 21 octobre 2009 ,b`(B 10:01 -0400, John W. Eaton a ,bi(Bcrit : | > OK, this seems better than forcing all of the directories in the load | > path to be read again. So how about the following change? It seems | > to work for me. | > | > http://hg.savannah.gnu.org/hgweb/octave/rev/d6b2b708b6b0 | | Applied on Octave 3.2.3, this patch solves the problem, in particular | with Dynare. The patch modifies the interfaces of some classes, so I'm not sure whether it is OK for a future 3.2.x release. jwe From soren at hauberg.org Thu Oct 22 13:27:58 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Thu, 22 Oct 2009 20:27:58 +0200 Subject: zenity_list: can't handle ( nor = In-Reply-To: <25979688.post@talk.nabble.com> References: <25979688.post@talk.nabble.com> Message-ID: <1256236078.4523.3.camel@sh-t400> Hi, tir, 20 10 2009 kl. 10:58 -0700, skrev Hielos: > Hello. I searched for "zenity_list" in the bugs' forum, but I didn't find > anything. I am not looking for a solution. I just want to say that there is > a bug in 'zenity_list': Thanks for bringing this up. For future reference, please file bugs against packages at the octave-forge mailing list: octave-dev at lists.sourceforge.net > DOESN'T WORK: > octave> zmsg = "Hello"; > octave> zcols = {"Choice", " ", "Description"}; > octave> zopts = {"TRUE", "FALSE";"1", "2";"f(x)", "df(x)/dx"}; > octave> zenity_list(zmsg, zcols, zopts, "checklist", "all"); > sh: Syntax error: "(" unexpected > error: zenity_list: > error: called from: > error: /home/user/octave/zenity-0.5.7/zenity_list.m at line 103, column 5 The attached patch seems to fix this. > DOESN'T WORK: > octave> zmsg = "Hello"; > octave> zcols = {"Choice", " ", "Description"}; > octave> zopts = {"TRUE", "FALSE";"1", "2";"f=k", "df/dx"}; > octave> zenity_list(zmsg, zcols, zopts, "checklist", "all"); > (This one creates a very odd pop-up list) You'll need to explain why this one is odd. It looks quite fine to me, but perhaps I'm not looking the right places? It could also relate to the choice of shell as the 'zenity' package just calls the shell. I'm using bash. Do you use something else? S?ren -------------- next part -------------- A non-text attachment was scrubbed... Name: zenity.patch Type: text/x-patch Size: 604 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091022/2d11872e/attachment.bin From jwe at octave.org Thu Oct 22 14:50:10 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 22 Oct 2009 15:50:10 -0400 Subject: wavread function bug In-Reply-To: <4AE03461.5070504@10g.pl> References: <4AE03461.5070504@10g.pl> Message-ID: <19168.46962.94257.96289@segfault.lan> On 22-Oct-2009, Piotr Sok,Bs3(B wrote: | I found a bug in waveread function from audio toolbox: in line 172 there | is variable "ck_size" and I suppose it should be "data_size". This problem seems to be fixed in the current sources, but not in the 3.2.x release branch. Jaroslav, the changeset is here: http://hg.savannah.gnu.org/hgweb/octave/rev/70de69177370 Thanks, jwe From thomas.weber.mail at gmail.com Fri Oct 23 02:19:39 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Fri, 23 Oct 2009 09:19:39 +0200 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> Message-ID: <20091023071939.GA16352@atlan> On Tue, Oct 20, 2009 at 10:00:52PM +0200, Jaroslav Hajek wrote: > 2009/10/20 Thomas Weber : > > Hi, > > > > On Thu, Oct 15, 2009 at 02:09:30PM +0000, S?bastien Villemot wrote: > >> Hi, > >> > >> I think I found the culprit for what I thought was a race condition in > >> Octave. > >> > >> The problem has to do with the way Octave 3.2 updates its load-path: it > >> only updates its cache of the current directory if the modification time > >> of the directory changes (see load_path::dir_info::update() in > >> src/load-path.cc). > > > > In case it's not clear: this is a real problem and not some artificially > > found issue. It makes software using Octave randomly fail at build time. > > > > ? ? ? ?Thomas > > > > I don't understand - what you mean by "build time"? The build of dynare[1] fails when running its test suite. [1] http://www.cepremap.cnrs.fr/dynare/ Thomas From sebastien.villemot at ens.fr Fri Oct 23 04:52:53 2009 From: sebastien.villemot at ens.fr (=?ISO-8859-1?Q?S=E9bastien?= Villemot) Date: Fri, 23 Oct 2009 09:52:53 +0000 Subject: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink()) In-Reply-To: <1256221111.21402.15.camel@karaba.cepremap.org> References: <1255426110.31610.13.camel@karaba.cepremap.org> <1255615770.20678.21.camel@karaba.cepremap.org> <20091020181457.GA11996@atlan> <69d8d540910201300r3188a0e4naf99f2b3a6b1a94@mail.gmail.com> <1256070852.4500.24.camel@sh-t400> <19166.13480.894482.630735@segfault.lan> <19167.5201.437449.784544@segfault.lan> <1256221111.21402.15.camel@karaba.cepremap.org> Message-ID: <1256291573.5509.46.camel@karaba.cepremap.org> Le jeudi 22 octobre 2009 ? 14:18 +0000, S?bastien Villemot a ?crit : > Le mercredi 21 octobre 2009 ? 10:01 -0400, John W. Eaton a ?crit : > > OK, this seems better than forcing all of the directories in the load > > path to be read again. So how about the following change? It seems > > to work for me. > > > > http://hg.savannah.gnu.org/hgweb/octave/rev/d6b2b708b6b0 > > Applied on Octave 3.2.3, this patch solves the problem, in particular > with Dynare. Actually when applied to Octave 3.2.3 this patch creates another bug: * suppose you have some M-file in /tmp/foo.m * launch Octave from another directory (say /home/user) * At the Octave prompt type "cd /tmp" then "foo": you get an "undefined" error... Does this bug also occur with the development branch of Octave ? Or is it simply that the above patch is not suited for Octave 3.2.3 ? Best, -- S?bastien Villemot From marco_atzeri at yahoo.it Fri Oct 23 08:46:03 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Fri, 23 Oct 2009 13:46:03 +0000 (GMT) Subject: no match operator on mx-inlines.cc Message-ID: <919227.17626.qm@web25502.mail.ukl.yahoo.com> Hi, on latest $ hg tip changeset: 9757:95ad9c2a27e2 tag: tip user: Jaroslav Hajek date: Fri Oct 23 10:35:59 2009 +0200 summary: fix idx_vector construction checks building with gcc-4.3.4-1 on cygwin 1.7 g++ -c -I. -I../../octave/liboctave -I.. -I../liboctave -I../src -I../libcruft/misc -I../../octave -I../../octave/liboctave -I../../octave/src -I../../octave/libcruft/misc -DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2 ../../octave/liboctave/CNDArray.cc -o CNDArray.o ../../octave/liboctave/mx-inlines.cc: In function ?void twosum_accum(T&, T&, const T&) [with T = std::complex]?: ../../octave/liboctave/mx-inlines.cc:1263: instantiated from ?T mx_inline_xsum(const T*, octave_idx_type) [with T = std::complex]? ../../octave/liboctave/mx-inlines.cc:1289: instantiated from ?void mx_inline_xsum(const T*, T*, octave_idx_type, octave_idx_type, octave_idx_type) [with T = std::complex]? ../../octave/liboctave/CNDArray.cc:669: instantiated from here ../../octave/liboctave/mx-inlines.cc:1252: error: no match for ?operator-? in ?s1 - s? ../../octave/liboctave/CMatrix.h:439: note: candidates are: ComplexMatrix operator-(const ComplexMatrix&) ../../octave/liboctave/CMatrix.h:439: note: ComplexMatrix operator-(const ComplexMatrix&, const Complex&) ../../octave/liboctave/CMatrix.h:439: note: ComplexMatrix operator-(const Complex&, const ComplexMatrix&) ../../octave/liboctave/CMatrix.h:439: note: ComplexMatrix operator-(const ComplexMatrix&, const ComplexMatrix&) Regards Marco From marco_atzeri at yahoo.it Sat Oct 24 14:14:08 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Sat, 24 Oct 2009 19:14:08 +0000 (GMT) Subject: R: system() returning the wrong process return code under windows In-Reply-To: <4AE3450B.50104@gmx.net> Message-ID: <95020.41826.qm@web25508.mail.ukl.yahoo.com> --- Sab 24/10/09, Benjamin Lindner ha scritto: > Hello, > > using system() with two output arguments currently returns > the wrong process exit code. > > > [a,b]=system("echo foo & exit 2") > a =? 127 > b = foo > > Under windows, pclose() returns the process exit code > directly, but the WIFEXITED and WEXITSTATUS macros currently > do something different. > > the attached chanegset fixes this and > > > [a,b]=system("echo foo & exit 2") > a =? 2 > b = foo > > now works correctly. > > I don't know whether this is also an issue under cygwin, > the changeset currently only checks for mingw platform. on cygwin and ctave 3.2.3 [a,b]=system("echo foo & exit 2") a = 2 b = foo so no need of such changeset > > Changeset applies to both 3.2.x branch as the development > sources. > > benjamin > Regards Marco From tmacchant at yahoo.co.jp Sat Oct 24 15:53:55 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 25 Oct 2009 05:53:55 +0900 (JST) Subject: ginput bug ? for development branch Message-ID: <20091024205355.87440.qmail@web3807.mail.bbt.yahoo.co.jp> Hello I found that 'ginput(1)' does not work on binaries from the very recent source trees on http://www.octave.org/hg/octave. description GNU Octave (development branch) owner John W. Eaton last change Fri, 23 Oct 2009 09:28:14 -0700 project home http://savannah.gnu.org/projects/octave Windows XP home Complier gcc 4.4.0/mingw (Official but not TDM) For octave 3.2.3, 'ginput(1)' works correct as, octave.exe:1fplot ("cos", [0, 2*pi]) octave.exe:2ginput(1) octave.exe:3> After mouse click once on the gnuplot graph window, a new octave prompt appear. However, for octave 3.3.50+ octave.exe:1fplot ("cos", [0, 2*pi]) octave.exe:2ginput(1) No response happens ever after mouse click on gnuplot graphic window. octave seem to fall into an infinite loop. I have not yet see the difference code difference between those of 3.2.3 and those of 3.3.50+. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From michael.goffioul at gmail.com Sat Oct 24 15:59:26 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sat, 24 Oct 2009 21:59:26 +0100 Subject: system() returning the wrong process return code under windows In-Reply-To: <4AE3450B.50104@gmx.net> References: <4AE3450B.50104@gmx.net> Message-ID: <128f38bd0910241359m63b5a189re5ba0480c6bf54e@mail.gmail.com> You can probably also include _MSC_VER in your patch, as they use the same runtime code library. Michael. On Sat, Oct 24, 2009 at 7:18 PM, Benjamin Lindner wrote: > Hello, > > using system() with two output arguments currently returns the wrong process > exit code. > >> [a,b]=system("echo foo & exit 2") > a = ?127 > b = foo > > Under windows, pclose() returns the process exit code directly, but the > WIFEXITED and WEXITSTATUS macros currently do something different. > > the attached chanegset fixes this and > >> [a,b]=system("echo foo & exit 2") > a = ?2 > b = foo > > now works correctly. > > I don't know whether this is also an issue under cygwin, the changeset > currently only checks for mingw platform. > > Changeset applies to both 3.2.x branch as the development sources. > > benjamin > > # HG changeset patch > # User Benjamin Lindner > # Date 1256408153 -7200 > # Node ID 9202865ea0264a989fc30fd9a927147e5ea3b35e > # Parent ?fed605a33cb5f261f55f9390c1392f7e7fe2dbf8 > define WIFEXITED and WEXITSTATUS for windows platform > > diff -r fed605a33cb5 -r 9202865ea026 liboctave/ChangeLog > --- a/liboctave/ChangeLog ? ? ? Sat Oct 24 20:15:53 2009 +0200 > +++ b/liboctave/ChangeLog ? ? ? Sat Oct 24 20:15:53 2009 +0200 > @@ -1,3 +1,8 @@ > +2009-10-24 ?Benjamin Lindner ? > + > + ? ? ? * syswait.h: define WIFEXITED and WEXITSTATUS > + ? ? ? for windows platform > + > ?2009-09-06 ?Jaroslav Hajek ? > > ? ? ? ?* dColVector.h (operator *(const Matrix&, const ColumnVector)): > diff -r fed605a33cb5 -r 9202865ea026 liboctave/syswait.h > --- a/liboctave/syswait.h ? ? ? Sat Oct 24 20:15:53 2009 +0200 > +++ b/liboctave/syswait.h ? ? ? Sat Oct 24 20:15:53 2009 +0200 > @@ -41,6 +41,11 @@ > ?#include > ?#endif > > +#if defined (__MINGW32__) > +#define WIFEXITED(stat_val) ( (stat_val) != -1 ) > +#define WEXITSTATUS(stat_val) ((unsigned)(stat_val)) > +#endif > + > ?#if defined (NeXT) > ?#define HAVE_WAITPID 1 > ?#define WAITPID(a, b, c) \ > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > > From lukas.reichlin at swissonline.ch Sun Oct 25 08:42:58 2009 From: lukas.reichlin at swissonline.ch (Lukas Reichlin) Date: Sun, 25 Oct 2009 14:42:58 +0100 Subject: very strange bug Message-ID: Dear Octave Community I'm using Octave.app 3.2.3 on MacOSX 10.6.1 and I noticed a really strange behaviour of Octave/my scripts: When executing the commands at the end of this mail, instance sysc is partially changed where it should stay the same. Am I doing something wrong or is it a nasty bug in Octave? Thanks in advance for every help! Regards, Lukas BTW: The script needs control-oo: http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo.tar.gz?view=tar clear all; close all; clc; % script needs control-oo installed, not the "legacy" control package s = tf ('s'); % this is a simple control-oo-only feature sysc = ss (-1, 1, 1, 0); % create a simple, continuous-time model sysc % everything is fine here sysd = c2d (sysc, 2) % now convert to discrete-time and save as sysd sysc % sysc should stay unaltered/continuous-time, but it is discrete- time now! % Note that matrices a and b are unaltered in sysc, only sampling time changed From soren at hauberg.org Sun Oct 25 12:08:55 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Sun, 25 Oct 2009 18:08:55 +0100 Subject: `__pixels_per_inch__' property already exists Message-ID: <1256490535.4005.12.camel@sh-t400> Hi All I'm having some problems printing with the gnuplot backend after calling 'close all'. The following works for me fplot ("sin (x)", [0, 2*pi]) print ("test.png") but if I do close all fplot ("sin (x)", [0, 2*pi]) print ("test.png") afterwards, then I get the following error: error: addproperty: a `__pixels_per_inch__' property already exists in the graphics object error: called from: error: /home/sh/Programmer/share/octave/3.3.50+/m/plot/print.m at line 707, column 7 This is with a fairly recent checkout of the development sources. S?ren From lukas.reichlin at swissonline.ch Sun Oct 25 12:41:07 2009 From: lukas.reichlin at swissonline.ch (Lukas Reichlin) Date: Sun, 25 Oct 2009 18:41:07 +0100 Subject: very strange bug In-Reply-To: References: Message-ID: I modified my example below to make the bug obvious. It's really a nasty bug ;-) Somehow the objects are not properly "encapsulated", i.e. there is some kind of partial "passing by reference". I'm using Octave.app 3.2.3 on a recent MacBookPro with Intel Core2Duo and MacOSX 10.6.1. Regards, Lukas clear all; close all; clc; % script needs control-oo installed, not the "legacy" control package s = tf ('s'); % this is a simple control-oo-only feature % create a simple, continuous-time model syscont = ss (-1, 1, 1, 0); % make a copy of sysc (!) just to be sure that c2d has % no influence on syscont (but it has) syscopy = syscont % now convert syscopy to discrete-time and save as sysdisc sysdisc = c2d (syscopy, 2) % syscont should stay continuous-time (what else?), % but it is discrete-time now as well! syscont % Note that matrices a and b are unaltered in syscont (which is right), % only sampling time changed to 2 seconds (which is obviously WRONG!). From octave at phaselockedsystems.com Sun Oct 25 13:03:06 2009 From: octave at phaselockedsystems.com (Robert T. Short) Date: Sun, 25 Oct 2009 11:03:06 -0700 Subject: [OctDev] very strange bug In-Reply-To: References: Message-ID: <4AE492DA.9030309@phaselockedsystems.com> Lukas, I found this bug the other day - manifested differently. Worse, I think it is in some code that I contributed. I have no idea what is causing it. I did find a workaround, but will need access to my computer to provide that information. I am traveling right now and have limited email access and no computer access, but when I get home (one week from today) I will provide more information. I did strip the problem down to a very, very simple example. Bob Lukas Reichlin wrote: > I modified my example below to make the bug obvious. It's really a > nasty bug ;-) Somehow the objects are not properly "encapsulated", > i.e. there is some kind of partial "passing by reference". I'm using > Octave.app 3.2.3 on a recent MacBookPro with Intel Core2Duo and MacOSX > 10.6.1. > > Regards, > Lukas > > > > clear all; > close all; > clc; > > % script needs control-oo installed, not the "legacy" control package > s = tf ('s'); % this is a simple control-oo-only feature > > % create a simple, continuous-time model > syscont = ss (-1, 1, 1, 0); > > % make a copy of sysc (!) just to be sure that c2d has > % no influence on syscont (but it has) > syscopy = syscont > > % now convert syscopy to discrete-time and save as sysdisc > sysdisc = c2d (syscopy, 2) > > % syscont should stay continuous-time (what else?), > % but it is discrete-time now as well! > syscont > > % Note that matrices a and b are unaltered in syscont (which is right), > % only sampling time changed to 2 seconds (which is obviously WRONG!). > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Octave-dev mailing list > Octave-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/octave-dev > > > From bpabbott at mac.com Sun Oct 25 19:19:15 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sun, 25 Oct 2009 20:19:15 -0400 Subject: `__pixels_per_inch__' property already exists In-Reply-To: <1256490535.4005.12.camel@sh-t400> References: <1256490535.4005.12.camel@sh-t400> Message-ID: <7BAC5715-6C65-48A7-B0BA-87364D33F02D@mac.com> On Oct 25, 2009, at 1:08 PM, S?ren Hauberg wrote: > Hi All > > I'm having some problems printing with the gnuplot backend after > calling > 'close all'. The following works for me > > fplot ("sin (x)", [0, 2*pi]) > print ("test.png") > > but if I do > > close all > fplot ("sin (x)", [0, 2*pi]) > print ("test.png") > > afterwards, then I get the following error: > > error: addproperty: a `__pixels_per_inch__' property already > exists in the graphics object > error: called from: > error: /home/sh/Programmer/share/octave/3.3.50+/m/plot/ > print.m > at line 707, column 7 > > This is with a fairly recent checkout of the development sources. > > S?ren I see the same problem. After getting the error above, both 'set (gcf, "__pixels_per_inch__", dpi)' and 'get (gcf, "__pixels_per_inch__")' produce errors such as octave:19> get(gcf,"__pixels_per_inch__") error: get: unknown property "__pixels_per_inch__" octave:19> set(gcf,"__pixels_per_inch__", 100) error: set: unknown property "__pixels_per_inch__" and if I then try to add the property ... octave:21> addproperty ("__pixels_per_inch__", gcf, "double", 100) error: addproperty: a `__pixels_per_inch__' property already exists in the graphics object This looks like the problem is with the cpp sources, but I don't recognize any recent change as being to blame. Anyone else? Ben From tmacchant at yahoo.co.jp Mon Oct 26 05:35:15 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 26 Oct 2009 19:35:15 +0900 (JST) Subject: ginput bug ? for development branch In-Reply-To: <20091024205355.87440.qmail@web3807.mail.bbt.yahoo.co.jp> Message-ID: <20091026103515.75802.qmail@web3808.mail.bbt.yahoo.co.jp> Hello It will be grateful for me if anybody inform to the ML whether ginput works correct for development branch or not on his system. Regards Tatsuro --- Tatsuro MATSUOKA wrote: > Hello > > I found that 'ginput(1)' does not work on binaries from the very recent source trees on > http://www.octave.org/hg/octave. > > description GNU Octave (development branch) > owner John W. Eaton > last change Fri, 23 Oct 2009 09:28:14 -0700 > project home http://savannah.gnu.org/projects/octave > > Windows XP home > Complier gcc 4.4.0/mingw (Official but not TDM) > > For octave 3.2.3, 'ginput(1)' works correct as, > octave.exe:1fplot ("cos", [0, 2*pi]) > octave.exe:2ginput(1) > octave.exe:3> > After mouse click once on the gnuplot graph window, a new octave prompt appear. > > However, for octave 3.3.50+ > octave.exe:1fplot ("cos", [0, 2*pi]) > octave.exe:2ginput(1) > > No response happens ever after mouse click on gnuplot graphic window. > octave seem to fall into an infinite loop. > > I have not yet see the difference code difference between those of 3.2.3 and those of 3.3.50+. > > Regards > > Tatsuro > > -------------------------------------- > GyaO! - Anime, Dramas, Movies, and Music videos [FREE] > http://pr.mail.yahoo.co.jp/gyao/ > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From bpabbott at mac.com Mon Oct 26 05:54:24 2009 From: bpabbott at mac.com (Ben Abbott) Date: Mon, 26 Oct 2009 06:54:24 -0400 Subject: ginput bug ? for development branch In-Reply-To: <20091026103515.75802.qmail@web3808.mail.bbt.yahoo.co.jp> References: <20091026103515.75802.qmail@web3808.mail.bbt.yahoo.co.jp> Message-ID: <5C86DA36-3266-4593-90EC-1575B3B7DABA@mac.com> On Oct 26, 2009, at 6:35 AM, Tatsuro MATSUOKA wrote: > Hello > > It will be grateful for me if anybody inform to the ML whether > ginput works correct for development > branch or not on his system. > > Regards > > Tatsuro > > --- Tatsuro MATSUOKA wrote: > >> Hello >> >> I found that 'ginput(1)' does not work on binaries from the very >> recent source trees on >> http://www.octave.org/hg/octave. >> >> description GNU Octave (development branch) >> owner John W. Eaton >> last change Fri, 23 Oct 2009 09:28:14 -0700 >> project home http://savannah.gnu.org/projects/octave >> >> Windows XP home >> Complier gcc 4.4.0/mingw (Official but not TDM) >> >> For octave 3.2.3, 'ginput(1)' works correct as, >> octave.exe:1fplot ("cos", [0, 2*pi]) >> octave.exe:2ginput(1) >> octave.exe:3> >> After mouse click once on the gnuplot graph window, a new octave >> prompt appear. >> >> However, for octave 3.3.50+ >> octave.exe:1fplot ("cos", [0, 2*pi]) >> octave.exe:2ginput(1) >> >> No response happens ever after mouse click on gnuplot graphic >> window. >> octave seem to fall into an infinite loop. >> >> I have not yet see the difference code difference between those of >> 3.2.3 and those of 3.3.50+. >> >> Regards >> >> Tatsuro ginput does work for me on OSX. My gnuplot is also the developers version. Ben From mikulik at physics.muni.cz Mon Oct 26 09:20:19 2009 From: mikulik at physics.muni.cz (Petr Mikulik) Date: Mon, 26 Oct 2009 15:20:19 +0100 (CET) Subject: ginput bug ? for development branch In-Reply-To: <5C86DA36-3266-4593-90EC-1575B3B7DABA@mac.com> References: <20091026103515.75802.qmail@web3808.mail.bbt.yahoo.co.jp> <5C86DA36-3266-4593-90EC-1575B3B7DABA@mac.com> Message-ID: >> It will be grateful for me if anybody inform to the ML whether >> ginput works correct for development >> branch or not on his system. > ginput does work for me on OSX. My gnuplot is also the developers > version. Works OK on Linux in both 3.2.3 and development version. --- PM From jwe at octave.org Mon Oct 26 10:19:53 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 26 Oct 2009 11:19:53 -0400 Subject: system() returning the wrong process return code under windows In-Reply-To: <4AE58672.8060607@gmx.net> References: <4AE3450B.50104@gmx.net> <128f38bd0910241359m63b5a189re5ba0480c6bf54e@mail.gmail.com> <4AE58672.8060607@gmx.net> Message-ID: <19173.48665.115355.211683@segfault.lan> On 26-Oct-2009, Benjamin Lindner wrote: | Michael Goffioul wrote: | > You can probably also include _MSC_VER in your patch, | > as they use the same runtime code library. | > | | thanks for the feedback. | I also included _MSC_VER in the changeset. | | benjamin | | ---------------------------------------------------------------------- | # HG changeset patch | # User Benjamin Lindner | # Date 1256408153 -7200 | # Node ID 9202865ea0264a989fc30fd9a927147e5ea3b35e | # Parent fed605a33cb5f261f55f9390c1392f7e7fe2dbf8 | define WIFEXITED and WEXITSTATUS for windows platform | | diff -r fed605a33cb5 -r 9202865ea026 liboctave/ChangeLog | --- a/liboctave/ChangeLog Sat Oct 24 20:15:53 2009 +0200 | +++ b/liboctave/ChangeLog Sat Oct 24 20:15:53 2009 +0200 | @@ -1,3 +1,8 @@ | +2009-10-24 Benjamin Lindner | + | + * syswait.h: define WIFEXITED and WEXITSTATUS | + for windows platform | + | 2009-09-06 Jaroslav Hajek | | * dColVector.h (operator *(const Matrix&, const ColumnVector)): | diff -r fed605a33cb5 -r 9202865ea026 liboctave/syswait.h | --- a/liboctave/syswait.h Sat Oct 24 20:15:53 2009 +0200 | +++ b/liboctave/syswait.h Sat Oct 24 20:15:53 2009 +0200 | @@ -41,6 +41,11 @@ | #include | #endif | | +#if defined (__MINGW32__) || defined (_MSC_VER) | +#define WIFEXITED(stat_val) ( (stat_val) != -1 ) | +#define WEXITSTATUS(stat_val) ((unsigned)(stat_val)) | +#endif | + I hesitate to add more checks for systems/versions instead of features, so I would prefer it if this check were done with a configure test instaead. Then we would know from the configure test instead of having to enumerate the list of systems, and if the bug is fixed in the future, Octave will not have to change in order to work correctly. Maybe something that defines BROKEN_SYSTEM_EXIT_STATUS or similar? Maybe there is already a test for this in the autoconf macro archive. Or, is there really no bug in Windows here? Are we just using WIFEXITED and WEXITSTATUS incorrectly? jwe From aditya at biomath.ugent.be Mon Oct 26 12:11:50 2009 From: aditya at biomath.ugent.be (Aditya Bhagwat) Date: Mon, 26 Oct 2009 18:11:50 +0100 Subject: octave crases when function is called from within function's comment space Message-ID: <4AE5D856.40204@biomath.ugent.be> Bug report for Octave 3.2.3 configured for i686-pc-linux-gnu Description: ----------- Consider the following function: function myBugreport(a) % myBugreport(1) % Write to temp file [fid,scrName,msg] = mkstemp('proveBugXXXXXX', 1) fprintf(fid, "echo %d", a); fclose(fid); system(sprintf('chmod u+x %s', scrName)); % Execute script system(sprintf("cat %s", scrName)); To test this function, I selected the second line (not including the comment sign). So, I selected the region 'myBugreport(1)'. Then I sent this region to an inferior octave process with the command octave-send-region. This command is normally called with the keybinding C-c i r, but I've redefined the key binding to correspond with 'octave-send-region' in my .emacs file, so i used the f9 key to perform this 'octave-send-region'. When I do this, I get the symbol saying octave is running, my emacs freezes and the only thing I can do is a forced quit! Repeat-By --------- * Please replace this item with a description of the sequence of events that causes the problem to occur. Fix: --- I have noticed this only happens when I try to call the function from within its comment space itself. If I copy the line 'myBugReport(1)' and paste it into the inferior-octave-window, and then press enter, the problem doesn't happen. But nevertheless, it remains a bug. Especially as it makes my entire emacs freeze (with all windows) and crash. So it should not happen. Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux abmb 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20 19:48:24 UTC 2009 i686 GNU/Linux configure opts: Fortran compiler: gfortran FFLAGS: -O -mieee-fp FLIBS: -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.. -lz -lgfortranbegin -lgfortran -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) CFLAGS: -g -O2 CPICFLAG: -fPIC C++ compiler: g++, version 4.3.3 CXXFLAGS: -g -O2 CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/local/lib/octave-3.2.3 BLAS_LIBS: -llapack -lblas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_MAGICK=1 -DHAVE_GL_GL_H=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_SUITESPARSE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /usr/local/libexec/octave/3.2.3/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/api-v37/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/site/exec/i686-pc-linux-gnu:/usr/local/libexec/octave/3.2.3/exec/i686-pc-linux-gnu:/usr/local/bin:/home/abhagwat/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games IMAGE_PATH = .:/usr/local/share/octave/3.2.3/imagelib PAGER = less PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /home/abhagwat/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/local/share/info/octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 # print_answer_id_name = print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From lindnerben at gmx.net Mon Oct 26 15:11:35 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Mon, 26 Oct 2009 21:11:35 +0100 Subject: system() returning the wrong process return code under windows In-Reply-To: <19173.48665.115355.211683@segfault.lan> References: <4AE3450B.50104@gmx.net> <128f38bd0910241359m63b5a189re5ba0480c6bf54e@mail.gmail.com> <4AE58672.8060607@gmx.net> <19173.48665.115355.211683@segfault.lan> Message-ID: <4AE60277.2070809@gmx.net> > I hesitate to add more checks for systems/versions instead of > features, so I would prefer it if this check were done with a > configure test instaead. Then we would know from the configure test > instead of having to enumerate the list of systems, and if the bug is > fixed in the future, Octave will not have to change in order to work > correctly. Maybe something that defines BROKEN_SYSTEM_EXIT_STATUS or > similar? Maybe there is already a test for this in the autoconf macro > archive. > > Or, is there really no bug in Windows here? Are we just using > WIFEXITED and WEXITSTATUS incorrectly? Hmm, as far as I can see, the WIFEXITED and WEXITSTATUS are not available as a standard on a windows system. So one has to define them for windows platform, and the current definition in syswait.h is incorrect for the windows platform. Now maybe my patch is not correct either, it just worked for me. On windows, _cwait (the implementation of the waitpid() macro in syswait.h) stores the return code of the process, without any transformation. And returns -1 if the process did not successfully exit. So does pclose. So the default macro implementation of checking the low-byte as status and returning only the high as exit code does not work on windows. ( http://msdn.microsoft.com/en-us/library/zb9ehy71%28VS.80%29.aspx ) ( http://msdn.microsoft.com/en-us/library/25xdhsd2%28VS.80%29.aspx ) benjamin From kai.habel at gmx.de Mon Oct 26 15:09:54 2009 From: kai.habel at gmx.de (Kai Habel) Date: Mon, 26 Oct 2009 21:09:54 +0100 Subject: octave crash with repetitive 'clear functions' In-Reply-To: <4AE04C33.1050001@gmx.de> References: <4AE04C33.1050001@gmx.de> Message-ID: <20091026200954.229490@gmx.net> -------- Original-Nachricht -------- > Datum: Thu, 22 Oct 2009 14:12:35 +0200 > Von: Kai Habel > An: bug-octave at octave.org > Betreff: octave crash with repetitive \'clear functions\' > While playing with optiplux (optilux.sf.net) again, which is written for > octave and matlab, I ran into problems. > > I could reduce the problem to the following example. When running > myscript.m, which calls myfun.m octave dies with a segmentation fault at > the second 'clear functions'. > > kai at LxLap:~/hg-octave/octave> cat myscript.m > clear functions > myfun > clear functions > kai at LxLap:~/hg-octave/octave> cat myfun.m > function myfun > function f1 > function f2 > kai at LxLap:~/hg-octave/octave> ./run-octave --silent > adding ssprop to path > adding optilux to path > octave:1> myscript > panic: Segmentation fault -- stopping myself... > attempting to save variables to `octave-core'... > save to `octave-core' complete > Speicherzugriffsfehler > kai at LxLap:~/hg-octave/octave> > > I have observed this with a recent tip (yesterday), but not with the > mingw octave3.2.2 binary. Can someone confirm this crash? > Nobody? I had the chance to test it on a second Opensuse system and still see the crash, so I suspect the problem is with octave and not with my local installation(s). To test, create two files: 1.myfun.m function myfun function f1 function f2 2. myscript.m clear functions myfun clear functions If I call myscript octave dies with a segmentation fault. Kai From thomas.weber.mail at gmail.com Mon Oct 26 18:21:18 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Tue, 27 Oct 2009 00:21:18 +0100 Subject: octave crash with repetitive 'clear functions' In-Reply-To: <20091026200954.229490@gmx.net> References: <4AE04C33.1050001@gmx.de> <20091026200954.229490@gmx.net> Message-ID: <20091026232118.GA10907@atlan> Hi Kai, On Mon, Oct 26, 2009 at 09:09:54PM +0100, Kai Habel wrote: > > -------- Original-Nachricht -------- > > Datum: Thu, 22 Oct 2009 14:12:35 +0200 > > Von: Kai Habel > > An: bug-octave at octave.org > > Betreff: octave crash with repetitive \'clear functions\' > > > While playing with optiplux (optilux.sf.net) again, which is written for > > octave and matlab, I ran into problems. > > > > I could reduce the problem to the following example. When running > > myscript.m, which calls myfun.m octave dies with a segmentation fault at > > the second 'clear functions'. > > > > kai at LxLap:~/hg-octave/octave> cat myscript.m > > clear functions > > myfun > > clear functions > > kai at LxLap:~/hg-octave/octave> cat myfun.m > > function myfun > > function f1 > > function f2 > > kai at LxLap:~/hg-octave/octave> ./run-octave --silent > > adding ssprop to path > > adding optilux to path > > octave:1> myscript > > panic: Segmentation fault -- stopping myself... > > attempting to save variables to `octave-core'... > > save to `octave-core' complete > > Speicherzugriffsfehler > > kai at LxLap:~/hg-octave/octave> > > > > I have observed this with a recent tip (yesterday), but not with the > > mingw octave3.2.2 binary. Can someone confirm this crash? > > > > Nobody? I had the chance to test it on a second Opensuse system and > still see the crash, so I suspect the problem is with octave and not > with my local installation(s). I just tested this on Debian (amd64) and it crashes here as well. Sorry, no more info. I need to get some sleep now. Thomas From tmacchant at yahoo.co.jp Mon Oct 26 22:34:48 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Tue, 27 Oct 2009 12:34:48 +0900 (JST) Subject: ginput bug ? for development branch In-Reply-To: Message-ID: <20091027033448.81926.qmail@web3801.mail.bbt.yahoo.co.jp> Hello > >> It will be grateful for me if anybody inform to the ML whether > >> ginput works correct for development > >> branch or not on his system. Ben Wrote > > ginput does work for me on OSX. My gnuplot is also the developers > > version. --- Petr Mikulik wrote: > > Works OK on Linux in both 3.2.3 and development version. This problem seems to be my local problem. Hello Benjamin Did you try ginput in development version on your mingw environment ? Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From carlo.defalco at gmail.com Mon Oct 26 23:45:48 2009 From: carlo.defalco at gmail.com (Carlo de Falco) Date: Tue, 27 Oct 2009 05:45:48 +0100 Subject: lu(sparse(A), thres) ignores threshold parameter? Message-ID: -------- Bug report for Octave 3.2.3 configured for i386-apple-darwin8.11.1 Description: ----------- The "lu" command seems to ignore the optional "threshold" parameter Repeat-By: --------- Octave: >> version, A = [1e-2 1; 1 1]; [L, U] = lu (sparse(A), 1e-3); ans = 3.2.3 >> full(L), full(U) ans = 0.01000 1.00000 1.00000 0.00000 ans = 1.00000 1.00000 0.00000 0.99000 >> For comparison, the behaviour in matlab is the following: matlab: >> version, A = [1e-2 1; 1 1]; [L, U] = lu (sparse(A), 1e-3); ans = 7.9.0.529 (R2009b) >> full(L), full(U) ans = 1 0 100 1 ans = 0.0100 1.0000 0 -99.0000 Fix: --- Sorry, I don't know how to fix this Configuration (please do not edit this section): ----------------------------------------------- uname output: Darwin guglielmo.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386 configure opts: 'CC=gcc -arch i386' 'CPP=gcc -arch i386 -E' 'CXX=g++ -arch i386' 'F77=i386-apple-darwin8.11.1-g95' 'CFLAGS=-O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx - isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include' 'CPPFLAGS=-O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp - msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/ tmp/deps-i386/include' 'CXXFLAGS=-O3 -fforce-addr -march=i686 - mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx -isysroot / Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include' 'FFLAGS=-O3 - fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/ include' 'FLIBS=' 'LDFLAGS=-L/tmp/deps-i386/lib -Wl,- headerpad_max_install_names -Wl,-syslibroot -Wl,/Developer/SDKs/ MacOSX10.4u.sdk' '--prefix=/tmp/deps-i386' '--host=i386-apple- darwin8.11.1' '--without-x' '--enable-shared' '--disable-static' 'host_alias=i386-apple-darwin8.11.1' Fortran compiler: i386-apple-darwin8.11.1-g95 FFLAGS: -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include -mieee-fp FLIBS: -L/tmp/deps-i386/lib -L/private/tmp/deps-i386/bin/../ lib/gcc-lib/i386-apple-darwin8.11.1/4.0.3/ -L/private/tmp/deps-i386/ bin/../lib/gcc-lib/i386-apple-darwin8.11.1/4.0.3 -L/usr/lib/gcc// -L/ private/tmp/deps-i386/bin/../lib/gcc-lib/i386-apple- darwin8.11.1/4.0.3/// -L/usr/lib// -lhdf5 -lz -lf95 -lm -lSystemStubs - lmx CPPFLAGS: -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include -I/tmp/deps-i386/include INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc -arch i386, version 4.0.1 (Apple Computer, Inc. build 5370) CFLAGS: -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include CPICFLAG: -fPIC C++ compiler: g++ -arch i386, version 4.0.1 CXXFLAGS: -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include CXXPICFLAG: -fPIC LD_CXX: g++ -arch i386 LDFLAGS: -L/tmp/deps-i386/lib -Wl,- headerpad_max_install_names -Wl,-syslibroot -Wl,/Developer/SDKs/ MacOSX10.4u.sdk LIBFLAGS: -L. RLD_FLAG: BLAS_LIBS: -Wl,-framework -Wl,vecLib FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /usr/bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 - DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 - D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" - D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_FRAMEWORK_CARBON=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_FRAMEWORK_OPENGL=1 -DHAVE_GLUTESSCALLBACK_THREEDOTS=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_CHOLMOD_H=1 - DHAVE_CHOLMOD=1 -DHAVE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 - DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 - DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 - DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 - DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 - DHAVE_TERMIOS_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 - DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 - DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 - DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 - DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 - DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 - DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 - DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1 -DHAVE_DYLD_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 - DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /Applications/Octave.app/Contents/Resources/libexec/ octave/3.2.3/site/exec/i386-apple-darwin8.11.1:/Applications/ Octave.app/Contents/Resources/libexec/octave/api-v37/site/exec/i386- apple-darwin8.11.1:/Applications/Octave.app/Contents/Resources/libexec/ octave/site/exec/i386-apple-darwin8.11.1:/Applications/Octave.app/ Contents/Resources/libexec/octave/3.2.3/exec/i386-apple-darwin8.11.1:/ Applications/Octave.app/Contents/Resources/bin:/Applications/ Octave.app/Contents/Resources/bin:/Applications/Gnuplot.app/Contents/ Resources/bin:/sw/bin:/sw/sbin:/Applications/GnuPlot.app/Contents/ Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/ texbin:/usr/X11/bin:/usr/local/bin:/opt/dx/current/bin:/Applications/ Octave.app/Contents/Resources/bin:/Applications/gmsh-2.3.1/Gmsh.app/ Contents/MacOS/:/usr/local/gwTeX/bin/i386-apple-darwin-current:/usr/ X11R6/bin IMAGE_PATH = .:/Applications/Octave.app/Contents/Resources/share/ octave/3.2.3/imagelib PAGER = less PS1 = >> PS2 = PS4 = + beep_on_error = 1 completion_append_char = crash_dumps_octave_core = 0 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /Users/carlo/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /Applications/Octave.app/Contents/Resources/share/info/ octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 0 # print_answer_id_name = print_empty_dimensions = 0 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 0 suppress_verbose_help_message = 0 From individ at acc.umu.se Tue Oct 27 03:25:57 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 27 Oct 2009 09:25:57 +0100 Subject: octave crash with repetitive 'clear functions' In-Reply-To: <20091026200954.229490@gmx.net> References: <4AE04C33.1050001@gmx.de> <20091026200954.229490@gmx.net> Message-ID: <4AE6AE95.10803@acc.umu.se> Kai Habel wrote: > -------- Original-Nachricht -------- > >> Datum: Thu, 22 Oct 2009 14:12:35 +0200 >> Von: Kai Habel >> An: bug-octave at octave.org >> Betreff: octave crash with repetitive \'clear functions\' >> > > >> While playing with optiplux (optilux.sf.net) again, which is written for >> octave and matlab, I ran into problems. >> >> I could reduce the problem to the following example. When running >> myscript.m, which calls myfun.m octave dies with a segmentation fault at >> the second 'clear functions'. >> >> kai at LxLap:~/hg-octave/octave> cat myscript.m >> clear functions >> myfun >> clear functions >> kai at LxLap:~/hg-octave/octave> cat myfun.m >> function myfun >> function f1 >> function f2 >> kai at LxLap:~/hg-octave/octave> ./run-octave --silent >> adding ssprop to path >> adding optilux to path >> octave:1> myscript >> panic: Segmentation fault -- stopping myself... >> attempting to save variables to `octave-core'... >> save to `octave-core' complete >> Speicherzugriffsfehler >> kai at LxLap:~/hg-octave/octave> >> >> I have observed this with a recent tip (yesterday), but not with the >> mingw octave3.2.2 binary. Can someone confirm this crash? >> >> > > Nobody? I had the chance to test it on a second Opensuse system and still see the crash, so I suspect the problem is with octave and not with my local installation(s). > > To test, create two files: > > 1.myfun.m > > function myfun > function f1 > function f2 > > 2. myscript.m > > clear functions > myfun > clear functions > > If I call myscript octave dies with a segmentation fault. > > Kai > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > Segfaults in 9747:7bda650b691a. Note that if myfun.m contains no subfunctions, like myfun.m: function myfun then clear functions doesn't crash. David From kai.habel at gmx.de Tue Oct 27 04:44:46 2009 From: kai.habel at gmx.de (Kai Habel) Date: Tue, 27 Oct 2009 10:44:46 +0100 Subject: octave crash with repetitive 'clear functions' In-Reply-To: <4AE6AE95.10803@acc.umu.se> References: <4AE04C33.1050001@gmx.de> <20091026200954.229490@gmx.net> <4AE6AE95.10803@acc.umu.se> Message-ID: <20091027094446.202020@gmx.net> -------- Original-Nachricht -------- > Datum: Tue, 27 Oct 2009 09:25:57 +0100 > Von: David Grundberg > An: Kai Habel > CC: bug at octave.org > Betreff: Re: octave crash with repetitive \'clear functions\' > Kai Habel wrote: > > -------- Original-Nachricht -------- > > > >> Datum: Thu, 22 Oct 2009 14:12:35 +0200 > >> Von: Kai Habel > >> An: bug-octave at octave.org > >> Betreff: octave crash with repetitive \'clear functions\' > >> > > > > > >> While playing with optiplux (optilux.sf.net) again, which is written > for > >> octave and matlab, I ran into problems. > >> > >> I could reduce the problem to the following example. When running > >> myscript.m, which calls myfun.m octave dies with a segmentation fault > at > >> the second 'clear functions'. > >> > >> kai at LxLap:~/hg-octave/octave> cat myscript.m > >> clear functions > >> myfun > >> clear functions > >> kai at LxLap:~/hg-octave/octave> cat myfun.m > >> function myfun > >> function f1 > >> function f2 > >> kai at LxLap:~/hg-octave/octave> ./run-octave --silent > >> adding ssprop to path > >> adding optilux to path > >> octave:1> myscript > >> panic: Segmentation fault -- stopping myself... > >> attempting to save variables to `octave-core'... > >> save to `octave-core' complete > >> Speicherzugriffsfehler > >> kai at LxLap:~/hg-octave/octave> > >> > >> I have observed this with a recent tip (yesterday), but not with the > >> mingw octave3.2.2 binary. Can someone confirm this crash? > >> > >> > > > > Nobody? I had the chance to test it on a second Opensuse system and > still see the crash, so I suspect the problem is with octave and not with my > local installation(s). > > > > To test, create two files: > > > > 1.myfun.m > > > > function myfun > > function f1 > > function f2 > > > > 2. myscript.m > > > > clear functions > > myfun > > clear functions > > > > If I call myscript octave dies with a segmentation fault. > > > > Kai > > _______________________________________________ > > Bug-octave mailing list > > Bug-octave at octave.org > > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > > > > > Segfaults in 9747:7bda650b691a. Note that if myfun.m contains no > subfunctions, like > > myfun.m: > > function myfun > > then clear functions doesn't crash. > > David Thanks for your confirmation. Indeed, if you remove any line of the example above, octave does not crash anymore. Kai From kai.habel at gmx.de Tue Oct 27 04:49:33 2009 From: kai.habel at gmx.de (Kai Habel) Date: Tue, 27 Oct 2009 10:49:33 +0100 Subject: octave crash with repetitive 'clear functions' In-Reply-To: <20091026232118.GA10907@atlan> References: <4AE04C33.1050001@gmx.de> <20091026200954.229490@gmx.net> <20091026232118.GA10907@atlan> Message-ID: <20091027094933.16510@gmx.net> -------- Original-Nachricht -------- > Datum: Tue, 27 Oct 2009 00:21:18 +0100 > Von: Thomas Weber > An: Kai Habel > CC: Octave Bugs > Betreff: Re: octave crash with repetitive \'clear functions\' > Hi Kai, > > On Mon, Oct 26, 2009 at 09:09:54PM +0100, Kai Habel wrote: > > > > -------- Original-Nachricht -------- > > > Datum: Thu, 22 Oct 2009 14:12:35 +0200 > > > Von: Kai Habel > > > An: bug-octave at octave.org > > > Betreff: octave crash with repetitive \'clear functions\' > > > > > While playing with optiplux (optilux.sf.net) again, which is written > for > > > octave and matlab, I ran into problems. > > > > > > I could reduce the problem to the following example. When running > > > myscript.m, which calls myfun.m octave dies with a segmentation fault > at > > > the second 'clear functions'. > > > > > > kai at LxLap:~/hg-octave/octave> cat myscript.m > > > clear functions > > > myfun > > > clear functions > > > kai at LxLap:~/hg-octave/octave> cat myfun.m > > > function myfun > > > function f1 > > > function f2 > > > kai at LxLap:~/hg-octave/octave> ./run-octave --silent > > > adding ssprop to path > > > adding optilux to path > > > octave:1> myscript > > > panic: Segmentation fault -- stopping myself... > > > attempting to save variables to `octave-core'... > > > save to `octave-core' complete > > > Speicherzugriffsfehler > > > kai at LxLap:~/hg-octave/octave> > > > > > > I have observed this with a recent tip (yesterday), but not with the > > > mingw octave3.2.2 binary. Can someone confirm this crash? > > > > > > > Nobody? I had the chance to test it on a second Opensuse system and > > still see the crash, so I suspect the problem is with octave and not > > with my local installation(s). > > I just tested this on Debian (amd64) and it crashes here as well. Sorry, > no more info. I need to get some sleep now. > > Thomas Hello Thomas, thanks for your confirmation. Unfortunatly this beyond my knowledge of octave, so I have to leave the debugging to a core developer. Kai From dbateman at dbateman.org Tue Oct 27 14:13:11 2009 From: dbateman at dbateman.org (David Bateman) Date: Tue, 27 Oct 2009 20:13:11 +0100 Subject: lu(sparse(A), thres) ignores threshold parameter? In-Reply-To: References: Message-ID: <4AE74647.3080405@dbateman.org> Carlo de Falco wrote: > -------- > Bug report for Octave 3.2.3 configured for i386-apple-darwin8.11.1 > > Description: > ----------- > > The "lu" command seems to ignore the optional "threshold" parameter > > Repeat-By: > --------- > > > > Octave: > >> version, A = [1e-2 1; 1 1]; [L, U] = lu (sparse(A), 1e-3); > ans = 3.2.3 > >> full(L), full(U) > ans = > > 0.01000 1.00000 > 1.00000 0.00000 > > ans = > > 1.00000 1.00000 > 0.00000 0.99000 > > >> > > For comparison, the behaviour in matlab is the following: > > > matlab: > > >> version, A = [1e-2 1; 1 1]; [L, U] = lu (sparse(A), 1e-3); > > ans = > > 7.9.0.529 (R2009b) > > >> full(L), full(U) > > ans = > > 1 0 > 100 1 > > > ans = > > 0.0100 1.0000 > 0 -99.0000 > > > Fix: > --- > > > Yes there is a typo in SparsedbleLU.cc and SparseCmplxLU.cc. The code that sets the threshold passed to UMFPACK is if (piv_thres.nelem() != 2) { tmp = (piv_thres (0) > 1. ? 1. : piv_thres (0)); if (!xisnan (tmp)) Control (UMFPACK_PIVOT_TOLERANCE) = tmp; tmp = (piv_thres (1) > 1. ? 1. : piv_thres (1)); if (!xisnan (tmp)) Control (UMFPACK_SYM_PIVOT_TOLERANCE) = tmp; } else { tmp = octave_sparse_params::get_key ("piv_tol"); if (!xisnan (tmp)) Control (UMFPACK_PIVOT_TOLERANCE) = tmp; tmp = octave_sparse_params::get_key ("sym_tol"); if (!xisnan (tmp)) Control (UMFPACK_SYM_PIVOT_TOLERANCE) = tmp; } where piv_thres is a two element vector if it passes a valid pivot tolerance. So the line if (piv_thres.nelem() != 2) should read if (piv_thres.nelem() == 2) Here is a proposed changeset that I pushed. D. -- David Bateman dbateman at dbateman.org 35 rue Gambetta +33 1 46 04 02 18 (Home) 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091027/f3bc1588/attachment.ksh From dbateman at free.fr Wed Oct 28 11:23:12 2009 From: dbateman at free.fr (dbateman) Date: Wed, 28 Oct 2009 09:23:12 -0700 (PDT) Subject: Fixing HDF-1.8 API for octave-3.2.x In-Reply-To: References: <4A905142.8020308@dbateman.org> <19093.59289.539983.77168@segfault.lan> Message-ID: <26097695.post@talk.nabble.com> Kacper Kowalik wrote: > > Attached patches do the following: > > 1) octave-3.2.2-drop-ancient-hdf5.diff - removes now obsolete code > under 'HAVE_H5GGET_NUM_OBJS' > and 'have_h5giterate_bug' since hdf5>=1.6 includes H5GGET_NUM_OBJS and > is free of the h5giterate_bug. > As results it drops compatibility with hdf5-1.2 and hdf5-1.4 > > 2) octave-3.2.2-simplify_and_prep_for_hdf5-18.diff - small changes in > configure.in and config.h.in, > now if HDF5>=1.8 is present on the system, new flag (HAVE_HDF5_18) is > defined. > Unless HDF5-1.8 library was compiled with --with-default-api-version=v16 > > 3) octave-3.2.2-add-hdf5_18.diff - brings HDF5-1.8 API octave while > retaining compatibility with HDF5-1.6 > > Best regards, > Kacper Kowalik > > Were these patches ever applied? It would be nice to have them in the development tree to allow the use of HDF 1.8 natively.. D. -- View this message in context: http://www.nabble.com/Fixing-HDF-1.8-API-for-octave-3.2.x-tp25093743p26097695.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From Alexander.Klein at math.uni-giessen.de Wed Oct 28 06:10:46 2009 From: Alexander.Klein at math.uni-giessen.de (Alexander Klein) Date: Wed, 28 Oct 2009 12:10:46 +0100 Subject: empirical_pdf returns all zeroes Message-ID: <4AE826B6.90506@math.uni-giessen.de> -------- Bug report for Octave 3.2.3 configured for i686-pc-linux-gnu Description: ----------- The function empirical_pdf seems to return only zeroes, no matter what input data is used. empirical_cdf, on the other hand, seems to work as expected. Repeat-By: --------- empirical_pdf ( -10:0.1:10,randn(1000,1)) Fix: --- None, yet. Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux mandelbrot 2.6.24-25-server #1 SMP Tue Oct 20 08:12:40 UTC 2009 i686 GNU/Linux configure opts: '--with-x' Fortran compiler: g77 FFLAGS: -O -mieee-fp FLIBS: -L/usr/lib/gcc/i486-linux-gnu/3.4.6 -L/usr/lib/gcc/i486-linux-gnu/3.4.6/../../../../lib -L/usr/lib/gcc/i486-linux-gnu/3.4.6/../../.. -L/lib/../lib -L/usr/lib/../lib -lhdf5 -lz -lfrtbegin -lg2c -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.2.4 (Ubuntu 4.2.4-1ubuntu4) CFLAGS: -g -O2 CPICFLAG: -fPIC C++ compiler: g++, version 4.2.4 CXXFLAGS: -g -O2 CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/local/lib/octave-3.2.3 BLAS_LIBS: -lblas FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __ -DHAVE_BLAS=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=12 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LGAMMA_R=1 -DHAVE_LGAMMAF_R=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 -DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 From kocbach at gmail.com Thu Oct 29 03:36:56 2009 From: kocbach at gmail.com (Ladislav Kocbach) Date: Thu, 29 Oct 2009 09:36:56 +0100 Subject: Animations; Blinking in octave 3.23; Worked well in 3.03; platform Mac; suspected all platforms Message-ID: <4b77fb140910290136n21e6cddcn8c2581300e2590b5@mail.gmail.com> Problem: Animations; Blinking in octave 3.23 not 3.03: platform Mac; suspected all platforms This problem never occured before, since Octave 2.1 Taking code from "help refreshdata" x = 0:0.1:10; y = sin (x); plot (x, y, "ydatasource", "y"); for i = 1 : 100 pause(0.1) y = sin (x + 0.1 * i); refreshdata(); endfor This code performs horrible animation, since all the graphics is redrawn, with blinking There is nothing like 'erasemode','xor' or similar, the display blinks and is uncomfortable This was not a problem with older versions of octave For example, the equivalent code which works smoothly in octave 3.0.3. ( and another equivalent code in octave 2.99 also works smoothly) x = 0:0.1:10; y = sin (x); PPL=plot (x, y);hold on; for i = 1 : 100 pause(0.1) y = sin (x + 0.1 * i); set(PPL,'ydata',y) endfor also misbehaves in octave 3.2.3. The suggested reason: somebody has been improving the communication with gnuplot and improved it too much (unnecessary "clean figure" inserted probably) My suspicion is that the same problem accurs also for other platforms. Thank you! Ladislav Kocbach Department of Physics and Technology University of Bergen, Norway ladi at ift.uib.no -- Mobile Phone: +47 45 25 80 80 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091029/3689ac2f/attachment.html From carlo.defalco at gmail.com Thu Oct 29 09:07:34 2009 From: carlo.defalco at gmail.com (Carlo de Falco) Date: Thu, 29 Oct 2009 15:07:34 +0100 Subject: issorted incompatibility Message-ID: <536AF70D-EE82-4AF2-B016-B69BF2861ECA@gmail.com> -------- Bug report for Octave 3.2.3 configured for i386-apple-darwin8.11.1 Description: ----------- "issorted" in Octave returns true if the input is sorted in either ascending or descending order while in matlab it returns true only if the order is ascending. Repeat-By: --------- in Octave: >> version ans = 3.2.3 >> issorted([1 2]) ans = 1 >> issorted([2 1]) ans = 1 >> in matlab: >> version ans = 7.7.0.471 (R2008b) >> issorted ([2 1]) ans = 0 >> issorted ([1 2]) ans = 1 Fix: --- * If possible, replace this item with a description of how to fix the problem (if you don't have a fix for the problem, don't include this section, but please do submit your report anyway). Configuration (please do not edit this section): ----------------------------------------------- uname output: Darwin guglielmo.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386 configure opts: 'CC=gcc -arch i386' 'CPP=gcc -arch i386 -E' 'CXX=g++ -arch i386' 'F77=i386-apple-darwin8.11.1-g95' 'CFLAGS=-O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx - isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include' 'CPPFLAGS=-O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp - msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/ tmp/deps-i386/include' 'CXXFLAGS=-O3 -fforce-addr -march=i686 - mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx -isysroot / Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include' 'FFLAGS=-O3 - fforce-addr -march=i686 -mfpmath=sse,387 -mieee-fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/ include' 'FLIBS=' 'LDFLAGS=-L/tmp/deps-i386/lib -Wl,- headerpad_max_install_names -Wl,-syslibroot -Wl,/Developer/SDKs/ MacOSX10.4u.sdk' '--prefix=/tmp/deps-i386' '--host=i386-apple- darwin8.11.1' '--without-x' '--enable-shared' '--disable-static' 'host_alias=i386-apple-darwin8.11.1' Fortran compiler: i386-apple-darwin8.11.1-g95 FFLAGS: -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include -mieee-fp FLIBS: -L/tmp/deps-i386/lib -L/private/tmp/deps-i386/bin/../ lib/gcc-lib/i386-apple-darwin8.11.1/4.0.3/ -L/private/tmp/deps-i386/ bin/../lib/gcc-lib/i386-apple-darwin8.11.1/4.0.3 -L/usr/lib/gcc// -L/ private/tmp/deps-i386/bin/../lib/gcc-lib/i386-apple- darwin8.11.1/4.0.3/// -L/usr/lib// -lhdf5 -lz -lf95 -lm -lSystemStubs - lmx CPPFLAGS: -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include -I/tmp/deps-i386/include INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc -arch i386, version 4.0.1 (Apple Computer, Inc. build 5370) CFLAGS: -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include CPICFLAG: -fPIC C++ compiler: g++ -arch i386, version 4.0.1 CXXFLAGS: -O3 -fforce-addr -march=i686 -mfpmath=sse,387 -mieee- fp -msse3 -msse2 -msse -mmmx -isysroot /Developer/SDKs/MacOSX10.4u.sdk -I/tmp/deps-i386/include CXXPICFLAG: -fPIC LD_CXX: g++ -arch i386 LDFLAGS: -L/tmp/deps-i386/lib -Wl,- headerpad_max_install_names -Wl,-syslibroot -Wl,/Developer/SDKs/ MacOSX10.4u.sdk LIBFLAGS: -L. RLD_FLAG: BLAS_LIBS: -Wl,-framework -Wl,vecLib FFTW_LIBS: -lfftw3 -lfftw3f LIBS: -lreadline -lncurses -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /usr/bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DOCTAVE_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 - DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 - D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" - D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DHAVE_X_WINDOWS=1 -DHAVE_FRAMEWORK_CARBON=1 -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE_COMPILE=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_FRAMEWORK_OPENGL=1 -DHAVE_GLUTESSCALLBACK_THREEDOTS=1 -DHAVE_OPENGL=1 -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL=1 -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __ -DHAVE_BLAS=1 -DHAVE_QRUPDATE=1 -DHAVE_AMD_H=1 -DHAVE_AMD=1 -DHAVE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_CHOLMOD_H=1 - DHAVE_CHOLMOD=1 -DHAVE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_ARPACK=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 - DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 - DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 - DHAVE_ALLOCA=1 -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DHAVE_FAST_INT_OPS=1 -DSIZEOF_LONG_DOUBLE=16 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 - DHAVE_POLL_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 - DHAVE_TERMIOS_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 - DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 - DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 - DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 - DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 - DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 - DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 - DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1 -DHAVE_DYLD_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_CMATH_ISNAN=1 -DHAVE_CMATH_ISNANF=1 -DHAVE_CMATH_ISINF=1 -DHAVE_CMATH_ISINFF=1 -DHAVE_CMATH_ISFINITE=1 -DHAVE_CMATH_ISFINITEF=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ACOSHF=1 -DHAVE_ASINH=1 -DHAVE_ASINHF=1 -DHAVE_ATANH=1 -DHAVE_ATANHF=1 -DHAVE_ERF=1 -DHAVE_ERFF=1 - DHAVE_ERFC=1 -DHAVE_ERFCF=1 -DHAVE_EXP2F=1 -DHAVE_LOG2=1 -DHAVE_LOG2F=1 -DHAVE_HYPOTF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = emacs EXEC_PATH = /Applications/Octave.app/Contents/Resources/libexec/ octave/3.2.3/site/exec/i386-apple-darwin8.11.1:/Applications/ Octave.app/Contents/Resources/libexec/octave/api-v37/site/exec/i386- apple-darwin8.11.1:/Applications/Octave.app/Contents/Resources/libexec/ octave/site/exec/i386-apple-darwin8.11.1:/Applications/Octave.app/ Contents/Resources/libexec/octave/3.2.3/exec/i386-apple-darwin8.11.1:/ Applications/Octave.app/Contents/Resources/bin:/Applications/ Octave.app/Contents/Resources/bin:/Applications/Gnuplot.app/Contents/ Resources/bin:/sw/bin:/sw/sbin:/Applications/GnuPlot.app/Contents/ Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/ texbin:/usr/X11/bin:/usr/local/bin:/opt/dx/current/bin:/Applications/ Octave.app/Contents/Resources/bin:/Applications/gmsh-2.3.1/Gmsh.app/ Contents/MacOS/:/usr/local/gwTeX/bin/i386-apple-darwin-current:/usr/ X11R6/bin IMAGE_PATH = .:/Applications/Octave.app/Contents/Resources/share/ octave/3.2.3/imagelib PAGER = less PS1 = >> PS2 = PS4 = + beep_on_error = 1 completion_append_char = crash_dumps_octave_core = 0 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot # gnuplot_command_end = # gnuplot_command_plot = # gnuplot_command_replot = # gnuplot_command_splot = # gnuplot_command_title = # gnuplot_command_using = # gnuplot_command_with = history_file = /Users/carlo/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /Applications/Octave.app/Contents/Resources/share/info/ octave.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 0 # print_answer_id_name = print_empty_dimensions = 0 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 0 suppress_verbose_help_message = 0 From tmacchant at yahoo.co.jp Thu Oct 29 09:42:52 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Thu, 29 Oct 2009 23:42:52 +0900 (JST) Subject: Animations; Blinking in octave 3.23; Worked well in 3.03; platform Mac; suspected all platforms In-Reply-To: <4b77fb140910290136n21e6cddcn8c2581300e2590b5@mail.gmail.com> Message-ID: <20091029144252.94032.qmail@web3813.mail.bbt.yahoo.co.jp> Hello For Octave 3.2.3/MinGW for windows and octave 3.2.3 on cygwin, > x = 0:0.1:10; > y = sin (x); > plot (x, y, "ydatasource", "y"); > for i = 1 : 100 > pause(0.1) > y = sin (x + 0.1 * i); > refreshdata(); > endfor worked without blinking. This problem was discussed before 3.2.3 release. Please see, http://www.nabble.com/changeset-9395-(3.2.%EF%BD%98-branch)-should-be-applied-not-only-x11-term-but-on-windows,-wxt,-(-and-aqua)-term-td25326547.html Which terminal are you using ? Aqua term or X11 term ? I do not have Mac so that I cannot confirm the blinking at least on windows ( MinGW / Cygwin) Please wait Mac users' replies. Regards Tatsuro --- Ladislav Kocbach wrote: > Problem: Animations; Blinking in octave 3.23 not 3.03: platform Mac; > suspected all platforms > This problem never occured before, since Octave 2.1 > > Taking code from "help refreshdata" > x = 0:0.1:10; > y = sin (x); > plot (x, y, "ydatasource", "y"); > for i = 1 : 100 > pause(0.1) > y = sin (x + 0.1 * i); > refreshdata(); > endfor > This code performs horrible animation, since all the graphics is redrawn, > with blinking > There is nothing like 'erasemode','xor' or similar, the display blinks and > is uncomfortable > > This was not a problem with older versions of octave > For example, > the equivalent code which works smoothly in octave 3.0.3. > ( and another equivalent code in octave 2.99 also works smoothly) > x = 0:0.1:10; > y = sin (x); > PPL=plot (x, y);hold on; > for i = 1 : 100 > pause(0.1) > y = sin (x + 0.1 * i); > set(PPL,'ydata',y) > endfor > also misbehaves in octave 3.2.3. > > The suggested reason: > somebody has been improving the communication with gnuplot and improved it > too much > (unnecessary "clean figure" inserted probably) > > My suspicion is that the same problem accurs also for other platforms. > > Thank you! > > Ladislav Kocbach > Department of Physics and Technology > University of Bergen, Norway > ladi at ift.uib.no -- Mobile Phone: +47 45 25 80 80 > > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From gdsotirov at dir.bg Thu Oct 29 09:40:24 2009 From: gdsotirov at dir.bg (Georgi D. Sotirov) Date: Thu, 29 Oct 2009 07:40:24 -0700 (PDT) Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so Message-ID: <26114361.post@talk.nabble.com> Hello, I encounter the following problem on Slackware Linux 13.0 with LAPACK 3.2.1 and Octave 3.2.3. When I run octave it uses almost the whole CPU time on the machine, without being able to finish. I've traced the problem to the following: # gdb /usr/bin/octave GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-slackware-linux"... (no debugging symbols found) (gdb) r Starting program: /usr/bin/octave (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) [New Thread 0xb599e8e0 (LWP 3266)] (no debugging symbols found) ^C Program received signal SIGINT, Interrupt. [Switching to Thread 0xb599e8e0 (LWP 3266)] 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1 (gdb) bt #0 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1 #1 0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1 #2 0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1 #3 0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1 #4 0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so #5 0xb69f158d in oct_mach_info::init_float_format () from /usr/lib/octave-3.2.3/liboctave.so #6 0xb69f1682 in oct_mach_info::oct_mach_info () from /usr/lib/octave-3.2.3/liboctave.so #7 0xb69f16ee in oct_mach_info::instance_ok () from /usr/lib/octave-3.2.3/liboctave.so #8 0xb69f17b7 in oct_mach_info::native_float_format () from /usr/lib/octave-3.2.3/liboctave.so #9 0xb69de464 in octave_ieee_init () from /usr/lib/octave-3.2.3/liboctave.so #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so #12 0x080486da in main () (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0xb62c65c4 in dlamc3_ at plt () from /usr/lib/liblapack.so.3.2.1 (gdb) bt #0 0xb62c65c4 in dlamc3_ at plt () from /usr/lib/liblapack.so.3.2.1 #1 0xb66bc4c2 in dlamc1_ () from /usr/lib/liblapack.so.3.2.1 #2 0xb66bbca0 in dlamc2_ () from /usr/lib/liblapack.so.3.2.1 #3 0xb66bc576 in dlamch_ () from /usr/lib/liblapack.so.3.2.1 #4 0xb6837bc5 in d1mach_ () from /usr/lib/octave-3.2.3/libcruft.so #5 0xb69f158d in oct_mach_info::init_float_format () from /usr/lib/octave-3.2.3/liboctave.so #6 0xb69f1682 in oct_mach_info::oct_mach_info () from /usr/lib/octave-3.2.3/liboctave.so #7 0xb69f16ee in oct_mach_info::instance_ok () from /usr/lib/octave-3.2.3/liboctave.so #8 0xb69f17b7 in oct_mach_info::native_float_format () from /usr/lib/octave-3.2.3/liboctave.so #9 0xb69de464 in octave_ieee_init () from /usr/lib/octave-3.2.3/liboctave.so #10 0xb7789b77 in sysdep_init () from /usr/lib/octave-3.2.3/liboctinterp.so #11 0xb772187a in octave_main () from /usr/lib/octave-3.2.3/liboctinterp.so #12 0x080486da in main () It seems, that Octave is stuck on an infinite loop in LAPACK, which in my case is compiled as a separate shared library by gcc 4.3.3 with flags "-fimplicit-none -O -mieee-fp -march=i486 -mtune=i686 -fPIC". I have the same problem with flags "-fimplicit-none -O2 -march=i486 -mtune=i686 -fPIC" and also with "-O3" (I've though at one point it may be some optimization issue). Then, I noticed that octave runs normally if compiled without system's LAPACK (./configure --without-lapack). In this case LAPACK is compiled for libcruft with just "-O -mieee-fp" flags. Any suggestions? Is the problem in Octave or it's in LAPACK? How could I help for the resolving of this problem? P.S. I found similar problem discussed in http://www.nabble.com/make-check-hangs-at-chol.cc-td22601685.html this thread , but in this case Octave loops upon command execution. -- View this message in context: http://www.nabble.com/Octave-loops-infinitely-in-dlamc3_-from--usr-lib-liblapack.so-tp26114361p26114361.html Sent from the Octave - Bugs mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091029/005ea040/attachment-0001.html From dasergatskov at gmail.com Thu Oct 29 10:36:43 2009 From: dasergatskov at gmail.com (Dmitri A. Sergatskov) Date: Thu, 29 Oct 2009 16:36:43 +0100 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <26114361.post@talk.nabble.com> References: <26114361.post@talk.nabble.com> Message-ID: <892b16670910290836m4449442n578db2e2e49fbb10@mail.gmail.com> On Thu, Oct 29, 2009 at 3:40 PM, Georgi D. Sotirov wrote: > issue). Then, I noticed that octave runs normally if compiled without > system's LAPACK (./configure --without-lapack). In this case LAPACK is > compiled for libcruft with just "-O -mieee-fp" flags. > > Any suggestions? Is the problem in Octave or it's in LAPACK? How could I > help for the resolving of this problem? > dlamch has to be compiled with -O. > P.S. I found similar problem discussed in this thread, but in this case > Octave loops upon command execution. > Dmitri. -- From ipate80 at gmail.com Thu Oct 29 11:57:29 2009 From: ipate80 at gmail.com (Idomeneas Pateros) Date: Thu, 29 Oct 2009 18:57:29 +0200 Subject: clear all command causes segmentation fault Message-ID: <96c5ae740910290957k34aad6fdk68283e80386b4376@mail.gmail.com> Hello I use the octave 3.0.1 version on Ubuntu 9.04 Linux with kernel 2.6.28.16 platform and while when I write the command clear all the octave gives a segmentation fault in terminal. octave:2> clear all panic: Segmentation fault -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete Segmentation fault Although when one writes the simplest command clear everything works fine Thank you Idomeneas -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091029/7f6a2fab/attachment.html From ipate80 at gmail.com Thu Oct 29 12:21:17 2009 From: ipate80 at gmail.com (Idomeneas Pateros) Date: Thu, 29 Oct 2009 19:21:17 +0200 Subject: error,defined variable seems to be undefined Message-ID: <96c5ae740910291021g4bf1ccfdj82db563bf8766242@mail.gmail.com> Hello I use octave version 3.0.1 on Ubuntu 9.04 Linux platform and when I run the function : SolveDuffing (see files in attachment) in command prompt I receive the error : error: `t' undefined near line 3 column 8 error: evaluating argument list element number 1 error: called from `resultsplot' in file `/home/idomeneas/OctaveProjects/DuffingEquation.dir/resultsplot.m' error: called from `SolveDuffing' in file `/home/idomeneas/OctaveProjects/DuffingEquation.dir/SolveDuffing.m' The problem seems to be in calling the function in resultsplot.m file, but when I copy the commands from resultsplot.m to SolveDuffing.m and run the SolveDuffing, the plots are correct. I appreciate any help about this problem. Thank you Idomeneas -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091029/bab75561/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: SolveDuffing.m Type: text/x-objcsrc Size: 569 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091029/bab75561/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: resultsplot.m Type: text/x-objcsrc Size: 267 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091029/bab75561/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Duffing.m Type: text/x-objcsrc Size: 168 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091029/bab75561/attachment-0002.bin From jwe at octave.org Thu Oct 29 14:26:55 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 29 Oct 2009 15:26:55 -0400 Subject: octave crash with repetitive 'clear functions' In-Reply-To: <20091027094933.16510@gmx.net> References: <4AE04C33.1050001@gmx.de> <20091026200954.229490@gmx.net> <20091026232118.GA10907@atlan> <20091027094933.16510@gmx.net> Message-ID: <19177.60543.878467.239711@segfault.lan> On 27-Oct-2009, Kai Habel wrote: | -------- Original-Nachricht -------- | > Datum: Tue, 27 Oct 2009 00:21:18 +0100 | > Von: Thomas Weber | > An: Kai Habel | > CC: Octave Bugs | > Betreff: Re: octave crash with repetitive \'clear functions\' | | > Hi Kai, | > | > On Mon, Oct 26, 2009 at 09:09:54PM +0100, Kai Habel wrote: | > > | > > -------- Original-Nachricht -------- | > > > Datum: Thu, 22 Oct 2009 14:12:35 +0200 | > > > Von: Kai Habel | > > > An: bug-octave at octave.org | > > > Betreff: octave crash with repetitive \'clear functions\' | > > | > > > While playing with optiplux (optilux.sf.net) again, which is written | > for | > > > octave and matlab, I ran into problems. | > > > | > > > I could reduce the problem to the following example. When running | > > > myscript.m, which calls myfun.m octave dies with a segmentation fault | > at | > > > the second 'clear functions'. | > > > | > > > kai at LxLap:~/hg-octave/octave> cat myscript.m | > > > clear functions | > > > myfun | > > > clear functions | > > > kai at LxLap:~/hg-octave/octave> cat myfun.m | > > > function myfun | > > > function f1 | > > > function f2 | > > > kai at LxLap:~/hg-octave/octave> ./run-octave --silent | > > > adding ssprop to path | > > > adding optilux to path | > > > octave:1> myscript | > > > panic: Segmentation fault -- stopping myself... | > > > attempting to save variables to `octave-core'... | > > > save to `octave-core' complete | > > > Speicherzugriffsfehler | > > > kai at LxLap:~/hg-octave/octave> | > > > | > > > I have observed this with a recent tip (yesterday), but not with the | > > > mingw octave3.2.2 binary. Can someone confirm this crash? | > > > | > > | > > Nobody? I had the chance to test it on a second Opensuse system and | > > still see the crash, so I suspect the problem is with octave and not | > > with my local installation(s). | > | > I just tested this on Debian (amd64) and it crashes here as well. Sorry, | > no more info. I need to get some sleep now. | > | > Thomas | | Hello Thomas, | | thanks for your confirmation. Unfortunatly this beyond my knowledge of octave, so I have to leave the debugging to a core developer. I checked in the following change. http://hg.savannah.gnu.org/hgweb/octave/rev/5f8971be8e12 Thanks, jwe From jwe at octave.org Thu Oct 29 14:34:13 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 29 Oct 2009 15:34:13 -0400 Subject: error,defined variable seems to be undefined In-Reply-To: <96c5ae740910291021g4bf1ccfdj82db563bf8766242@mail.gmail.com> References: <96c5ae740910291021g4bf1ccfdj82db563bf8766242@mail.gmail.com> Message-ID: <19177.60981.782833.407778@segfault.lan> On 29-Oct-2009, Idomeneas Pateros wrote: | Hello | I use octave version 3.0.1 on Ubuntu 9.04 Linux platform and when I run the | function : | | SolveDuffing (see files in attachment) | | in command prompt I receive the error : | | error: `t' undefined near line 3 column 8 | error: evaluating argument list element number 1 | error: called from `resultsplot' in file | `/home/idomeneas/OctaveProjects/DuffingEquation.dir/resultsplot.m' | error: called from `SolveDuffing' in file | `/home/idomeneas/OctaveProjects/DuffingEquation.dir/SolveDuffing.m' | | The problem seems to be in calling the function in resultsplot.m file, but | when I copy the commands from resultsplot.m to SolveDuffing.m | and run the SolveDuffing, the plots are correct. | | I appreciate any help about this problem. This doesn't look like a bug in Octave. Your resultplot function doesn't have any arguments, so t (and x) will be undefined inside that function. | function resultsplot | figure(1) | plot(t,x(:,1),'b',t,x(:,2),'r') | xlabel("t") | ylabel("dx/dt") | figure(2) | plot(t,y(:,1),'b',t,y(:,2),'r') | xlabel("t") | ylabel("dx/dt") | figure(3) | plot(t,z(:,1),'b',t,z(:,2),'r') | xlabel("t") | ylabel("dx/dt") | endfunction Write this as function resultplot (x, t) and then call it with resultplot (x, t) and it should work. Unless you have a bug to report, please use the help list. jwe From jwe at octave.org Thu Oct 29 14:36:42 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 29 Oct 2009 15:36:42 -0400 Subject: very strange bug In-Reply-To: References: Message-ID: <19177.61130.614928.714592@segfault.lan> On 25-Oct-2009, Lukas Reichlin wrote: | I modified my example below to make the bug obvious. It's really a | nasty bug ;-) Somehow the objects are not properly "encapsulated", | i.e. there is some kind of partial "passing by reference". I'm using | Octave.app 3.2.3 on a recent MacBookPro with Intel Core2Duo and MacOSX | 10.6.1. | | Regards, | Lukas | | | | clear all; | close all; | clc; | | % script needs control-oo installed, not the "legacy" control package | s = tf ('s'); % this is a simple control-oo-only feature | | % create a simple, continuous-time model | syscont = ss (-1, 1, 1, 0); | | % make a copy of sysc (!) just to be sure that c2d has | % no influence on syscont (but it has) | syscopy = syscont | | % now convert syscopy to discrete-time and save as sysdisc | sysdisc = c2d (syscopy, 2) | | % syscont should stay continuous-time (what else?), | % but it is discrete-time now as well! | syscont | | % Note that matrices a and b are unaltered in syscont (which is right), | % only sampling time changed to 2 seconds (which is obviously WRONG!). Where is the control-oo package? How about posting a self-contained example with everything necessary to reproduce the bug. It would help if you could make the example simple and only include what is necessary to reproduce the bug. jwe From ipate80 at gmail.com Thu Oct 29 14:50:06 2009 From: ipate80 at gmail.com (Idomeneas Pateros) Date: Thu, 29 Oct 2009 12:50:06 -0700 (PDT) Subject: error,defined variable seems to be undefined In-Reply-To: <19177.60981.782833.407778@segfault.lan> References: <96c5ae740910291021g4bf1ccfdj82db563bf8766242@mail.gmail.com> <19177.60981.782833.407778@segfault.lan> Message-ID: <26119596.post@talk.nabble.com> I tried to remove the function and the endfunction commands and the program worked because the t,x,y,z variables were already defined in the SolveDuffing function. John W. Eaton-3 wrote: > > On 29-Oct-2009, Idomeneas Pateros wrote: > > | Hello > | I use octave version 3.0.1 on Ubuntu 9.04 Linux platform and when I run > the > | function : > | > | SolveDuffing (see files in attachment) > | > | in command prompt I receive the error : > | > | error: `t' undefined near line 3 column 8 > | error: evaluating argument list element number 1 > | error: called from `resultsplot' in file > | `/home/idomeneas/OctaveProjects/DuffingEquation.dir/resultsplot.m' > | error: called from `SolveDuffing' in file > | `/home/idomeneas/OctaveProjects/DuffingEquation.dir/SolveDuffing.m' > | > | The problem seems to be in calling the function in resultsplot.m file, > but > | when I copy the commands from resultsplot.m to SolveDuffing.m > | and run the SolveDuffing, the plots are correct. > | > | I appreciate any help about this problem. > > This doesn't look like a bug in Octave. Your resultplot function > doesn't have any arguments, so t (and x) will be undefined inside that > function. > > | function resultsplot > | figure(1) > | plot(t,x(:,1),'b',t,x(:,2),'r') > | xlabel("t") > | ylabel("dx/dt") > | figure(2) > | plot(t,y(:,1),'b',t,y(:,2),'r') > | xlabel("t") > | ylabel("dx/dt") > | figure(3) > | plot(t,z(:,1),'b',t,z(:,2),'r') > | xlabel("t") > | ylabel("dx/dt") > | endfunction > > Write this as > > function resultplot (x, t) > > and then call it with > > resultplot (x, t) > > and it should work. > > Unless you have a bug to report, please use the help list. > > jwe > _______________________________________________ > Bug-octave mailing list > Bug-octave at octave.org > https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave > > -- View this message in context: http://www.nabble.com/error%2Cdefined-variable-seems-to-be-undefined-tp26117500p26119596.html Sent from the Octave - Bugs mailing list archive at Nabble.com. From lukas.reichlin at swissonline.ch Fri Oct 30 03:20:47 2009 From: lukas.reichlin at swissonline.ch (Lukas Reichlin) Date: Fri, 30 Oct 2009 09:20:47 +0100 Subject: very strange bug In-Reply-To: <19177.61130.614928.714592@segfault.lan> References: <19177.61130.614928.714592@segfault.lan> Message-ID: <744DB5EA-D1E1-4083-B17B-38DD7D084736@swissonline.ch> control-oo is here: http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/ Download the package with: http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo.tar.gz?view=tar Make sure that the "legacy" control package is not in your Octave path, because some functions have identical names (Matlab compatibility). I reduced the example as good as possible. If it is still too complicated to understand, you will have to wait until Robert posts his example next weekend. Regards, Lukas > On 25-Oct-2009, Lukas Reichlin wrote: > > | I modified my example below to make the bug obvious. It's really a > | nasty bug ;-) Somehow the objects are not properly "encapsulated", > | i.e. there is some kind of partial "passing by reference". I'm using > | Octave.app 3.2.3 on a recent MacBookPro with Intel Core2Duo and > MacOSX > | 10.6.1. > | > | Regards, > | Lukas > | > | > | > | clear all; > | close all; > | clc; > | > | % script needs control-oo installed, not the "legacy" control > package > | s = tf ('s'); % this is a simple control-oo-only feature > | > | % create a simple, continuous-time model > | syscont = ss (-1, 1, 1, 0); > | > | % make a copy of sysc (!) just to be sure that c2d has > | % no influence on syscont (but it has) > | syscopy = syscont > | > | % now convert syscopy to discrete-time and save as sysdisc > | sysdisc = c2d (syscopy, 2) > | > | % syscont should stay continuous-time (what else?), > | % but it is discrete-time now as well! > | syscont > | > | % Note that matrices a and b are unaltered in syscont (which is > right), > | % only sampling time changed to 2 seconds (which is obviously > WRONG!). > > Where is the control-oo package? > > How about posting a self-contained example with everything necessary > to reproduce the bug. It would help if you could make the example > simple and only include what is necessary to reproduce the bug. > > jwe From jwe at octave.org Fri Oct 30 12:38:07 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 30 Oct 2009 13:38:07 -0400 Subject: base class assignment problem (was: Re: very strange bug) In-Reply-To: <744DB5EA-D1E1-4083-B17B-38DD7D084736@swissonline.ch> References: <19177.61130.614928.714592@segfault.lan> <744DB5EA-D1E1-4083-B17B-38DD7D084736@swissonline.ch> Message-ID: <19179.9343.346812.992458@segfault.lan> On 30-Oct-2009, Lukas Reichlin wrote: | control-oo is here: | http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/ | | Download the package with: | http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo.tar.gz?view=tar | | Make sure that the "legacy" control package is not in your Octave | path, because some functions have identical names (Matlab | compatibility). | | I reduced the example as good as possible. If it is still too | complicated to understand, you will have to wait until Robert posts | his example next weekend. I'm attaching a minimal example. Unpack the oo-bug.tar.gz file, cd to the oo-bug directory and run the bug.m script. The problem seems to be that the base class objects are not properly copied when their fields are modified inside methods. I don't have a solution so it would be great if someone else would like to take a shot a fixing this problem. jwe -------------- next part -------------- A non-text attachment was scrubbed... Name: oo-bug.tar.gz Type: application/octet-stream Size: 473 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20091030/7cdb6cc0/attachment.obj From Thomas.Treichl at gmx.net Fri Oct 30 14:33:22 2009 From: Thomas.Treichl at gmx.net (Thomas Treichl) Date: Fri, 30 Oct 2009 20:33:22 +0100 Subject: issorted incompatibility In-Reply-To: <536AF70D-EE82-4AF2-B016-B69BF2861ECA@gmail.com> References: <536AF70D-EE82-4AF2-B016-B69BF2861ECA@gmail.com> Message-ID: <4AEB3F82.6000200@gmx.net> Carlo de Falco schrieb: > -------- > Bug report for Octave 3.2.3 configured for i386-apple-darwin8.11.1 Can somebody on a Linux box please check this, too? Thanks, Thomas From stefan at stefant.org Fri Oct 30 15:00:28 2009 From: stefan at stefant.org (Stefan Hepp) Date: Fri, 30 Oct 2009 21:00:28 +0100 Subject: Gnuplot terminal detection on linux without X11 patch Message-ID: <4AEB45DC.7060608@stefant.org> To: bug at octave.org Cc: stefan at stefant.org Subject: Gnuplot terminal detection on linux without X11 patch Bug report for Octave 3.0.1 configured for i486-pc-linux-gnu Description: ----------- If 'plot' is used on a linux server without X (p.e. using ssh), octave sets terminal 'aqua' to gnuplot, which is not available (in octave 3.0), and not all diehard console users know/care about setting GNUTERM (like me :) ). Similary, in Octave 3.2 in gnuplot_drawnow.m the Gnuplot terminal should only be set to X11 if DISPLAY is set (else, set to 'unknown' again or something). It would be nice to have an option/command/.. to prevent plot,etc.. from displaying the plot, but only store it to a file using 'print'. (I don't know if there is already such an option, but I could not find one). Repeat-By: --------- Run Octave 3.0/3.2 on a linux terminal, unset DISPLAY and GNUTERM environment variables, execute the following code: plot( [1 2 3 2 3] ); print('test.eps','-deps'); Fix: --- Here is a patch for drawnow.m for octave 3.0 which checks for OS X first, which works for me: diff -ru m.orig/plot/drawnow.m m/plot/drawnow.m --- m.orig/plot/drawnow.m 2009-10-30 20:00:21.000000000 +0100 +++ m/plot/drawnow.m 2009-10-30 19:59:45.000000000 +0100 @@ -160,13 +160,10 @@ term = "x11"; elseif (! isunix ()) term = "windows"; - else - ## This should really be checking for os x before setting - ## the terminal type to aqua, but nobody will notice because - ## every other unix will be using x11 and windows will be - ## using windows. Those diehards still running octave from - ## a linux console know how to set the GNUTERM variable. + elseif ( ismac () ) term = "aqua"; + else + term = "unknown"; endif endif @@ -195,10 +192,9 @@ elseif (enhanced) fprintf (plot_stream, "set terminal %s %s\n", term, enh_str); + elseif ( isempty (getenv ("GNUTERM")) ) + fprintf (plot_stream, "set terminal %s\n", term); endif - ## gnuplot will pick up the GNUTERM environment variable itself - ## so no need to set the terminal type if not also setting the - ## figure title or enhanced mode. endif For Octave 3.2 the following patch could work, but I have *not* tested it: diff -ru scripts.orig/plot/gnuplot_drawnow.m scripts/plot/gnuplot_drawnow.m --- scripts.orig/plot/gnuplot_drawnow.m 2009-10-30 20:41:19.000000000 +0100 +++ scripts/plot/gnuplot_drawnow.m 2009-10-30 20:20:52.000000000 +0100 @@ -326,8 +326,10 @@ term = "aqua"; elseif (! isunix ()) term = "windows"; - else + elseif (! isempty( getenv ("DISPLAY")) ) term = "x11"; + else + term = "unknown"; endif endif endfunction Configuration (please do not edit this section): ----------------------------------------------- uname output: Linux data 2.6.26-2-vserver-686 #1 SMP Sun Jun 21 07:50:38 UTC 2009 i686 GNU/Linux configure opts: '--host=i486-linux-gnu' '--build=i486-linux-gnu' '--prefix=/usr' '--datadir=/usr/share' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-blas=-lblas-3gf' '--with-lapack=-llapackgf-3' '--with-hdf5' '--with-fftw' '--enable-shared' '--enable-rpath' '--disable-static' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CC=gcc' 'CFLAGS=-g -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXX=g++' 'CXXFLAGS=-g -O2' 'F77=gfortran' 'FFLAGS=-g -O2' Fortran compiler: gfortran FFLAGS: -O2 -g F2C: @F2C@ F2CFLAGS: @F2CFLAGS@ FLIBS: -L/usr/lib/gcc/i486-linux-gnu/4.3.2 -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm CPPFLAGS: INCFLAGS: -I. -I. -I./liboctave -I./src -I./libcruft/misc C compiler: gcc, version 4.3.2 (Debian 4.3.2-1.1) CFLAGS: -O2 -g CPICFLAG: -fPIC C++ compiler: g++, version 4.3.2 CXXFLAGS: -O2 -g CXXPICFLAG: -fPIC LD_CXX: g++ LDFLAGS: LIBFLAGS: -L. RLD_FLAG: -Wl,-rpath -Wl,/usr/lib/octave-3.0.1 BLAS_LIBS: -llapackgf-3 -lblas-3gf FFTW_LIBS: -lfftw3 LIBS: -lreadline -lncurses -ldl -lhdf5 -lz -lm LEXLIB: LIBGLOB: SED: /bin/sed DEFS: -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSEPCHAR=':' -DSEPCHAR_STR=":" -D__NO_MATH_INLINES=1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1 -DCXX_ABI=unknown -DHAVE_LIBM=1 -DHAVE_QHULL=1 -DHAVE_PCRE=1 -DHAVE_REGEXEC=1 -DHAVE_REGEX=1 -DHAVE_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1 -DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1 -DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1 -DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1 -DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPWNAM=1 -DHAVE_DEV_T=1 -DHAVE_INO_T=1 -DHAVE_NLINK_T=1 -DHAVE_NLINK_T=1 -DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1 -DHAVE_SIGSET_T=1 -DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos -DHAVE_PLACEMENT_DELETE=1 -DHAVE_DYNAMIC_AUTO_ARRAYS=1 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_POLL_H=1 -DHAVE_PWD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_POLL_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMCAP_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_TERMIO_H=1 -DHAVE_SGTTY_H=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_FNMATCH=1 -DHAVE_GLOB=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_CANONICALIZE_FILE_NAME=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETGRENT=1 -DHAVE_GETGRGID=1 -DHAVE_GETGRNAM=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWUID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_KILL=1 -DHAVE_LGAMMA=1 -DHAVE_LINK=1 -DHAVE_LOCALTIME_R=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_MKSTEMP=1 -DHAVE_ON_EXIT=1 -DHAVE_PIPE=1 -DHAVE_POLL=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_READLINK=1 -DHAVE_REALPATH=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_ROUND=1 -DHAVE_SELECT=1 -DHAVE_SETGRENT=1 -DHAVE_SETLOCALE=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGLONGJMP=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRPTIME=1 -DHAVE_STRSIGNAL=1 -DHAVE_SYMLINK=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMA=1 -DHAVE_UMASK=1 -DHAVE_UNAME=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_STRFTIME=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DHAVE_DLOPEN_API=1 -DENABLE_DYNAMIC_LINKING=1 -DHAVE_TIMEVAL=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ISINF=1 -DHAVE_COPYSIGN=1 -DHAVE_DECL_SIGNBIT=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1 -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_EXP2=1 -DHAVE_LOG2=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DUSE_READLINE=1 -DEXCEPTION_IN_MATH=1 -DRETSIGTYPE=void -DHAVE_DECL_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DRETSIGTYPE_IS_VOID=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1 -DYYTEXT_POINTER=1 -DGNUPLOT_BINARY="gnuplot" User-preferences (please do not edit this section): -------------------------------------------------- EDITOR = vim EXEC_PATH = /usr/lib/octave/3.0.1/site/exec/i486-pc-linux-gnu:/usr/lib/octave/api-v32/site/exec/i486-pc-linux-gnu:/usr/lib/octave/site/exec/i486-pc-linux-gnu:/usr/lib/octave/3.0.1/exec/i486-pc-linux-gnu:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/opt/dmd/dmd/bin:/opt/llvm/llvm/bin:/opt/llvm/ldc/bin IMAGE_PATH = .:/usr/share/octave/3.0.1/imagelib PAGER = pager PS1 = \s:\#> PS2 = > PS4 = + beep_on_error = 0 completion_append_char = crash_dumps_octave_core = 1 echo_executing_commands = 0 fixed_point_format = 0 gnuplot_binary = gnuplot gnuplot_command_end = gnuplot_command_plot = pl gnuplot_command_replot = rep gnuplot_command_splot = sp gnuplot_command_title = t gnuplot_command_using = u gnuplot_command_with = w history_file = /home/stefan/.octave_hist history_size = 1024 ignore_function_time_stamp = system info_file = /usr/share/info/octave3.0.info info_program = info makeinfo_program = makeinfo max_recursion_depth = 256 output_max_field_width = 5 output_precision = 5 page_output_immediately = 0 page_screen_output = 1 print_answer_id_name = 1 print_empty_dimensions = 1 save_precision = 16 saving_history = 1 sighup_dumps_octave_core = 1 sigterm_dumps_octave_core = 1 silent_functions = 0 split_long_rows = 1 string_fill_char = struct_levels_to_print = 2 suppress_verbose_help_message = 0 From soren at hauberg.org Sat Oct 31 04:32:06 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Sat, 31 Oct 2009 10:32:06 +0100 Subject: issorted incompatibility In-Reply-To: <4AEB3F82.6000200@gmx.net> References: <536AF70D-EE82-4AF2-B016-B69BF2861ECA@gmail.com> <4AEB3F82.6000200@gmx.net> Message-ID: <1256981526.3886.25.camel@sh-t400> fre, 30 10 2009 kl. 20:33 +0100, skrev Thomas Treichl: > Carlo de Falco schrieb: > > -------- > > Bug report for Octave 3.2.3 configured for i386-apple-darwin8.11.1 > > Can somebody on a Linux box please check this, too? I see the same (IMHO reasonable) behaviour. I think we should add a flag to 'issorted' with possible values: * 'ascending' which checks that the data is sorted ascending. * 'descending' which checks that the data is sorted descending. * 'both' which checks both. For compatibility this flag should then be ascending by default. S?ren From carlo.defalco at gmail.com Sat Oct 31 12:54:13 2009 From: carlo.defalco at gmail.com (Carlo de Falco) Date: Sat, 31 Oct 2009 18:54:13 +0100 Subject: issorted incompatibility In-Reply-To: <4AEB3F82.6000200@gmx.net> References: <536AF70D-EE82-4AF2-B016-B69BF2861ECA@gmail.com> <4AEB3F82.6000200@gmx.net> Message-ID: <6CA22BF6-CA00-41B0-9934-E2A940761292@gmail.com> On 30 Oct 2009, at 20:33, Thomas Treichl wrote: > Carlo de Falco schrieb: >> -------- >> Bug report for Octave 3.2.3 configured for i386-apple-darwin8.11.1 > > Can somebody on a Linux box please check this, too? > Thanks, > Thomas The behaviour is the same on Fedora 11 c. From deivid.rodriguez at gmail.com Sat Oct 31 17:47:29 2009 From: deivid.rodriguez at gmail.com (deivid) Date: Sat, 31 Oct 2009 15:47:29 -0700 (PDT) Subject: Plot not robust with respect to Inf values In-Reply-To: <18855812.post@talk.nabble.com> References: <18855812.post@talk.nabble.com> Message-ID: <26146673.post@talk.nabble.com> gOS wrote: > > Attempting to pass Inf or NaN to plot results in interestingly different > results, and there's a bug somewhere in it. > > plot(NaN,NaN) results in > error: plot: expecting first argument to be asex handle ... etc > > plot(Inf,Inf) results in > line 15: undefined variable: Inf > > gnuplot> plot "-" using ($1):($2) axes x1y1 title "" with lines ... > > I'd assume that there is some sort of failure on all graphics packages. As > Inf and NaN can appear in matrices, shouldn't plot be able to identify > when its passed data it shouldn't be passed? > > I view this as a bug. Matlab simply returns a blank plot while not > crashing, if this isn't possible in Octave for each back end it probably > needs to be handled. > > Even getting an error from Octave instead of gnuplot would be good enough > for me, currently operations procede if Inf is present so there is no way > to catch on the issue besides checking every value in the matrix before > plotting. > Has this been fixed yet? -- View this message in context: http://old.nabble.com/Plot-not-robust-with-respect-to-Inf-values-tp18855812p26146673.html Sent from the Octave - Bugs mailing list archive at Nabble.com.