From les_klimczak at yahoo.com  Sat Aug  1 14:51:48 2009
From: les_klimczak at yahoo.com (Les Klimczak)
Date: Sat, 1 Aug 2009 12:51:48 -0700 (PDT)
Subject: error compiling Octave 3.2.2 with Magick++ under CentOS 5.3
Message-ID: <24772134.post@talk.nabble.com>


There seems to be some issue with how 'typedef' behaves in C++ namespaces. I
was able to fix it, but don't have a satisfactory explanation for the
problem.
Maybe someone has more insight here?

Les Klimczak, Ph.D.
Research Informatics Consultant
San Francisco, CA - Madison, WI - Gaithersburg, MD

Configuration:

CentOS 5.3
octave-3.2.2.tar.gz

ImageMagick-c++-devel-6.2.8.0-4.el5_1.1
ImageMagick-c++-6.2.8.0-4.el5_1.1
or
GraphicsMagick-1.3.5.tar.gz

./configure F77=gfortran


Problem:

g++ -c   -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc
-DHAVE_CONFIG_H -mieee-fp -I/usr/include/freetype2 -Wall -W -Wshadow
-Wold-style-cast -Wformat -g -O2 ./DLD-FUNCTIONS/__magick_read__.cc -o
pic/__magick_read__.o

./DLD-FUNCTIONS/__magick_read__.cc: In function ?unsigned int
scale_quantum_to_depth(const MagickLib::Quantum&, unsigned int)?:
./DLD-FUNCTIONS/__magick_read__.cc:45: error: ?Quantum? was not declared in
this scope

Fix:

$ diff -cr octave-3.2.2/src/DLD-FUNCTIONS/__magick_read__.cc
octave-3.2.2/src/DLD-FUNCTIONS/__magick_read__.cc.fix
*** octave-3.2.2/src/DLD-FUNCTIONS/__magick_read__.cc   2009-05-28
00:57:14.000000000 -0500
--- octave-3.2.2/src/DLD-FUNCTIONS/__magick_read__.cc.fix       2009-07-29
17:46:57.000000000 -0500
***************
*** 34,42 ****
  #ifdef HAVE_MAGICK
  
  #include <GraphicsMagick/Magick++.h>
  
  unsigned int
! scale_quantum_to_depth (const Magick::Quantum& quantum, unsigned int
depth)
  {
    return (static_cast<unsigned int> (static_cast<double> (quantum)
                                       / MaxRGB * ((1 << depth) - 1)));
--- 34,43 ----
  #ifdef HAVE_MAGICK
  
  #include <GraphicsMagick/Magick++.h>
+ typedef Magick::Quantum Quantum;
  
  unsigned int
! scale_quantum_to_depth (const Quantum& quantum, unsigned int depth)
  {
    return (static_cast<unsigned int> (static_cast<double> (quantum)
                                       / MaxRGB * ((1 << depth) - 1)));




-- 
View this message in context: http://www.nabble.com/error-compiling-Octave-3.2.2-with-Magick%2B%2B-under-CentOS-5.3-tp24772134p24772134.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From emmanuel_depaepe at yahoo.com  Sun Aug  2 08:49:10 2009
From: emmanuel_depaepe at yahoo.com (Emmanuel De Paepe)
Date: Sun, 2 Aug 2009 06:49:10 -0700 (PDT)
Subject: Bug in 'compass' function; Color cannot be changed
Message-ID: <927983.50862.qm@web52812.mail.re2.yahoo.com>

The colour property of the 'compass' function cannot be changed:
For example:

%%%
A = 10+8*j;
compass(A,"r")
%%%

generates an error instead of red arrow.
I do not see this this error in similar functions like 'feather','quiver', etc...




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090802/9fba1d2f/attachment.html 

From mstubbs at facstaff.wisc.edu  Sun Aug  2 13:02:39 2009
From: mstubbs at facstaff.wisc.edu (robin stubbs)
Date: Sun, 02 Aug 2009 13:02:39 -0500
Subject: can this compile on vs2008 or not
Message-ID: <4A75D4BF.5030802@facstaff.wisc.edu>

I downloaded octave source and was wading through all the instructions 
in the readme.mvsvc file. I got stuck on the file glob library and
couldn't find it. So in searching for that I found this post:
http://www.nabble.com/Configure-liboctave-for-MSVC-...-td24008999.html#
> All the information contained in that readme file has been made obsolete
> when the support for octave MSVC binaries was dropped. So you
> shouldn't pay to much attention to it and I guess that file should be removed
> in further octave releases.
> 
> I don't think the link you mentioned points to the correct glob library. I'll
> send you the one I use by private mail.

What a 2-fer! They dropped the can't do it anyway bombshell plus
would not publicly reveal the location of the glob library.

Is this true or isn't it? It would be very nice if you would correct all
references to this. The readme.msvc file is still there.

From tmacchant at yahoo.co.jp  Sun Aug  2 18:40:19 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 3 Aug 2009 08:40:19 +0900 (JST)
Subject: can this compile on vs2008 or not
In-Reply-To: <4A75D4BF.5030802@facstaff.wisc.edu>
Message-ID: <20090802234019.40434.qmail@web3815.mail.bbt.yahoo.co.jp>

Hello

Why do you post your mail to bug at octave.org?

The issue of glob libraries is not at all bug of the octave. 

Please send your post to help at octave.org

Regards

Tatsuro
 

--- robin stubbs  wrote:

> I downloaded octave source and was wading through all the instructions 
> in the readme.mvsvc file. I got stuck on the file glob library and
> couldn't find it. So in searching for that I found this post:
> http://www.nabble.com/Configure-liboctave-for-MSVC-...-td24008999.html#
> > All the information contained in that readme file has been made obsolete
> > when the support for octave MSVC binaries was dropped. So you
> > shouldn't pay to much attention to it and I guess that file should be removed
> > in further octave releases.
> > 
> > I don't think the link you mentioned points to the correct glob library. I'll
> > send you the one I use by private mail.
> 
> What a 2-fer! They dropped the can't do it anyway bombshell plus
> would not publicly reveal the location of the glob library.
> 
> Is this true or isn't it? It would be very nice if you would correct all
> references to this. The readme.msvc file is still there.
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

From tmacchant at yahoo.co.jp  Sun Aug  2 19:58:52 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 3 Aug 2009 09:58:52 +0900 (JST)
Subject: can this compile on vs2008 or not
In-Reply-To: <20090802234019.40434.qmail@web3815.mail.bbt.yahoo.co.jp>
Message-ID: <20090803005852.83646.qmail@web3815.mail.bbt.yahoo.co.jp>

Hello

Sorry
I have misled.
--- Tatsuro MATSUOKA wrote:
> > What a 2-fer! They dropped the can't do it anyway bombshell plus
> > would not publicly reveal the location of the glob library.
> > 
> > Is this true or isn't it? It would be very nice if you would correct all
> > references to this. The readme.msvc file is still there.

Certainly readme.msvc is still on the source package and the some of information is too old.
I think it should be removed from source tar ball.

Regards

Tatsuro 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

From mikulik at physics.muni.cz  Mon Aug  3 06:23:28 2009
From: mikulik at physics.muni.cz (Petr Mikulik)
Date: Mon, 3 Aug 2009 13:23:28 +0200 (CEST)
Subject: -lltdl
Message-ID: <Pine.LNX.4.64.0908031315290.24010@monoceros.physics.muni.cz>

I've tried to hg pull/update/autogen/configure/make Octave on OpenSUSE 11.1. 
Development headers of ImageMagick are installed.

Making Octave fails here:

g++ -shared -o __magick_read__.oct pic/__magick_read__.o -L../libcruft
-lcruft -L../liboctave -loctave -L. -loctinterp        -lblas -lfftw3
-lfftw3f -lreadline  -lncurses -ldl -lblas -lhdf5 -lz -lm  -lfreetype -lz
-L/usr/X11R6/lib -lGL -lGLU -L/usr/X11R6/lib
-L/usr/lib/gcc/i586-suse-linux/4.3
-L/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/lib
-L/usr/lib/gcc/i586-suse-linux/4.3/../../.. -lhdf5 -lz -lgfortranbegin
-lgfortran -lm -lfreetype -lGL -lGLU -lGraphicsMagick++ -lGraphicsMagick
-llcms -lfreetype -lXext -lSM -lICE -lX11 -lbz2 -lz -lm -lgomp -lpthread
-lltdl

with this message:
	ld: cannot find -lltdl

Linking proceeds fine if the "-lltdl" string is deleted.
Where does this requirement come from?

Note: "locate ltdl" shows:
...
/usr/lib/libltdl.so.3
/usr/lib/libltdl.so.3.1.6
/usr/lib/libltdl.so.7
/usr/lib/libltdl.so.7.2.0
/usr/lib/mpi/gcc/openmpi/include/openmpi/opal/libltdl/ltdl.h
...

---
PM


From mikulik at physics.muni.cz  Mon Aug  3 09:30:27 2009
From: mikulik at physics.muni.cz (Petr Mikulik)
Date: Mon, 3 Aug 2009 16:30:27 +0200 (CEST)
Subject: -lltdl
In-Reply-To: <Pine.LNX.4.64.0908031315290.24010@monoceros.physics.muni.cz>
References: <Pine.LNX.4.64.0908031315290.24010@monoceros.physics.muni.cz>
Message-ID: <Pine.LNX.4.64.0908031627580.6316@monoceros.physics.muni.cz>

The same problem appears also during making octave-3.2.2.tar.bz2.

> I've tried to hg pull/update/autogen/configure/make Octave on OpenSUSE 11.1. 
> Development headers of ImageMagick are installed.
> 
> Making Octave fails here:
> 
> g++ -shared -o __magick_read__.oct pic/__magick_read__.o -L../libcruft
> -lcruft -L../liboctave -loctave -L. -loctinterp        -lblas -lfftw3
> -lfftw3f -lreadline  -lncurses -ldl -lblas -lhdf5 -lz -lm  -lfreetype -lz
> -L/usr/X11R6/lib -lGL -lGLU -L/usr/X11R6/lib
> -L/usr/lib/gcc/i586-suse-linux/4.3
> -L/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/lib
> -L/usr/lib/gcc/i586-suse-linux/4.3/../../.. -lhdf5 -lz -lgfortranbegin
> -lgfortran -lm -lfreetype -lGL -lGLU -lGraphicsMagick++ -lGraphicsMagick
> -llcms -lfreetype -lXext -lSM -lICE -lX11 -lbz2 -lz -lm -lgomp -lpthread
> -lltdl
> 
> with this message:
> 	ld: cannot find -lltdl
> 
> Linking proceeds fine if the "-lltdl" string is deleted.
> Where does this requirement come from?
> 
> Note: "locate ltdl" shows:
> ...
> /usr/lib/libltdl.so.3
> /usr/lib/libltdl.so.3.1.6
> /usr/lib/libltdl.so.7
> /usr/lib/libltdl.so.7.2.0
> /usr/lib/mpi/gcc/openmpi/include/openmpi/opal/libltdl/ltdl.h
> ...

---
PM

From mikulik at physics.muni.cz  Mon Aug  3 09:42:18 2009
From: mikulik at physics.muni.cz (Petr Mikulik)
Date: Mon, 3 Aug 2009 16:42:18 +0200 (CEST)
Subject: set() options
Message-ID: <Pine.LNX.4.64.0908031637390.7224@monoceros.physics.muni.cz>

In Matlab, the set() command without all arguments gives a hint message.
For example
	plot(1:10)
	set(gca, 'Visible')
shows
	[ {on} | off ]
i.e. all available options for the 'Visible' keyword.

In Octave, this produces an error:
error: set: invalid number of arguments

The former approach is much more user-friendly as it gives user an idea what 
to set there. Could this work also in Octave?
Thanks.

---
PM

From highegg at gmail.com  Tue Aug  4 02:45:38 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 4 Aug 2009 09:45:38 +0200
Subject: octave: setxor
In-Reply-To: <2fb2ee070908010208q1b7dcb0q6b4f478a37379616@mail.gmail.com>
References: <2fb2ee070908010208q1b7dcb0q6b4f478a37379616@mail.gmail.com>
Message-ID: <69d8d540908040045p60c9419i9815e17050e04dec@mail.gmail.com>

On Sat, Aug 1, 2009 at 11:08 AM, Pieter
Eendebak<pieter.eendebak at gmail.com> wrote:
> Dear Jaroslav,
>
> The setxor function does not work will cells, e.g.
>
> setxor({'a', 'b', 'c'}, {'a', 'bb', 'c'})
>
> The other set functions do work with cells (union, unique). I fixed
> setxor to work with cells. The only drawback I see is that for cells
> we assume the content is strings.

In the change you made, the assumption is OK since otherwise the cell
array would not get through sort.

> Could you have a look at the code
> and commit it to the octave repository?
>

I fixed the style and commited a changeset under your name:
http://hg.savannah.gnu.org/hgweb/octave/rev/a3ae7abaf659
It would be nice if you also created test cases - look at the end of
the source to see how it's done.

Thanks,

-- 
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 Aug  4 02:53:44 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 4 Aug 2009 09:53:44 +0200
Subject: anonymous function cell array syntax error vs. matlab
In-Reply-To: <19056.53209.316307.998605@segfault.lan>
References: <407c57160907291454r73e45939o486e7e808a316f87@mail.gmail.com>
	<19056.53209.316307.998605@segfault.lan>
Message-ID: <69d8d540908040053x60f01c05n5104ece6019b4fb0@mail.gmail.com>

On Thu, Jul 30, 2009 at 12:40 AM, John W. Eaton<jwe at octave.org> wrote:
> On 29-Jul-2009, Ian Rickard wrote:
>
> | Bug report for Octave 3.2.2 configured for i386-apple-darwin8.11.1
> |
> | Description:
> | -----------
> |
> | ? * When a cell array is provided as the output of an anoymous
> | ? ? function, commas must be used to delimit the members along
> | ? ? rows. ?Matlab allows commas or spaces, and octave allows
> | ? ? both as well when the cell array is not an anonymous
> | ? ? function body. ?Examples:
> |
> | ? ? Example:
> |
> | ? ? This expressions is valid syntax in both octave and matlab:
> | ? ? @(){1, 2}
> |
> | ? ? This expression raises a syntax error in octave, but works
> | ? ? in matlab:
> | ? ? @(){1 2}
> |
> | ? ? Note that the following two exressions work in both, and produce
> | ? ? identical results:
> | ? ? {1, 2}
> | ? ? {1 2}
>
> I checked in the following change.
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/24df2e66abbe
>

I transplanted it to the 3.2.x branch.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From olaf.till at uni-jena.de  Tue Aug  4 07:14:41 2009
From: olaf.till at uni-jena.de (Olaf Till)
Date: Tue, 4 Aug 2009 14:14:41 +0200
Subject: griddata.m does not work if x, y, z are row-vectors
Message-ID: <20090804121441.GA8268@olaf>

Octave version: 3.2.0

function: geometry/griddata.m

description: errors from "cross" if first three arguments of griddata
are row-vectors

reproduce with:
[xi, yi] = meshgrid ([.5, 1, 1.5], [.5, 1, 1.5]);
[x, y, z] = griddata ([0, 1, 2, 0, 1, 2, 0, 1, 2], [0, 0, 0,  1, 1, 1, 2, 2, 2], [3, 4, 5, 4, 6, 8, 5, 8, 11], xi, yi);

fix:

@@ -61,6 +61,8 @@
     error ("griddata: xi and yi must be vectors or matrices of same size");
   endif
 
+  x = x(:); y = y(:); z = z(:);
+
   [nr, nc] = size (xi);
   
   ## Triangulate data.

Regards, Olaf

From C.Ellenberger at gmx.net  Wed Aug  5 05:03:10 2009
From: C.Ellenberger at gmx.net (Christoph Ellenberger)
Date: Wed, 05 Aug 2009 12:03:10 +0200
Subject: bug in std.m
Message-ID: <20090805100310.137970@gmx.net>

I don't know if this was already reported or fixed, but I didn't found anything in the bug archive.

I am using the MinGW version 3.2.0 for windows from sourceforge and there I encountered the following.

error: `sz' undefined near line 79 column 21
error: evaluating argument list element number 1
error: evaluating argument list element number 1
error: called from:
error:   C:\Programme\Octave\3.2.0_gcc-4.3.0\share\octave\3.2.0\m\statistics\base\std.m at line 79, column 12

instead of:
 
  if (n == 1)
    retval = zeros (sz);
  elseif (numel (a) > 0)
    retval = sqrt (sumsq (center (a, dim), dim) / (n + opt - 1));
  else
    error ("std: x must not be empty");
  endif

I guess it should be something like

  if (n == 1)
    retval = zeros (size(a));
  elseif (numel (a) > 0)
    retval = sqrt (sumsq (center (a, dim), dim) / (n + opt - 1));
  else
    error ("std: x must not be empty");
  endif

but I am not sure what the intended behaviour should be according to matlab compatibility...

kind regards
christoph
-- 
                                     ... 
                                    (o o) 
-----------------------oOO--(_)--OOo-------------------------- 
 
                          present coordinates: 
 
Christoph Ellenberger 
Hinterkirchweg 13
CH-4106 Therwil
+41 (0)61 721 14 69  
 
                email:   c.ellenberger at gmx.net 
 
---------------------------------------------------------------------- 
 

Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
f?r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

From pieter.eendebak at gmail.com  Wed Aug  5 16:22:34 2009
From: pieter.eendebak at gmail.com (Pieter Eendebak)
Date: Wed, 5 Aug 2009 23:22:34 +0200
Subject: octave: setxor
Message-ID: <2fb2ee070908051422v5fdd72e0n8d396c297c7ee33a@mail.gmail.com>

Attached is a patch with a test for the setxor function.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setxor-test.patch
Type: text/x-patch
Size: 1032 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090805/f59f27e8/attachment.bin 

From highegg at gmail.com  Thu Aug  6 00:28:44 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 6 Aug 2009 07:28:44 +0200
Subject: Can't set xticklabel
In-Reply-To: <052FF5C8-FF20-45EB-A99C-D12777184018@mac.com>
References: <4A70ADF8.6070809@fuw.edu.pl>
	<6AF78D0A-4B4C-4C90-9E1E-124723AE663D@mac.com>
	<052FF5C8-FF20-45EB-A99C-D12777184018@mac.com>
Message-ID: <69d8d540908052228o4d986b81m937983eab5c0de13@mail.gmail.com>

On Thu, Jul 30, 2009 at 2:11 AM, Ben Abbott<bpabbott at mac.com> wrote:
> On Jul 29, 2009, at 7:08 PM, Ben Abbott wrote:
>
>> On Jul 29, 2009, at 4:15 PM, Antoni Aduszkiewicz wrote:
>>
>>> Bug report for Octave 3.2.0 configured for i686-pc-linux-gnu
>>>
>>> Description:
>>> -----------
>>> % The following short example script
>>>
>>> x = 0:0.1:10;
>>> y = sin(x);
>>>
>>> xtick = 0:pi:10;
>>> xticklabel = [" 0 "; " pi"; "2pi"; "3pi"];
>>>
>>> plot(x,y)
>>> set(gca, "xtick",xtick, "xticklabel", xticklabel);
>>>
>>> %END
>>
>> There are several quick fixes. One is
>>
>> ? ? ? ?set (gca, "xtick", xtick, "xticklabel", "0|pi|2pi|3pi")
>>
>> Another that will use the Greek version is ...
>>
>> ? ? ? ?set (gca, "xtick", xtick, "xticklabel", "0|\\pi|2\\pi|3\\pi")
>>
>> In any event, I'll take a look at a changeset.
>>
>> Ben
>
> I've pushed a changeset
>
> ? ? ? ?http://hg.savannah.gnu.org/hgweb/octave/rev/303f862a896d
>
> Jaroslav, you may want to transplant into 3.2 ... but I think the sources
> have branched so there may be problems.
>

It seems to apply, so I suppose it should work.

Btw. It would help me a little if you avoided extending previously
created ChangeLog entries and rather started new ones, at least for
unrelated changes like this. That way, the transplant goes smoothly,
without the need of manual intervention.

thanks


-- 
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  Thu Aug  6 00:36:38 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 6 Aug 2009 07:36:38 +0200
Subject: octave: setxor
In-Reply-To: <2fb2ee070908051422v5fdd72e0n8d396c297c7ee33a@mail.gmail.com>
References: <2fb2ee070908051422v5fdd72e0n8d396c297c7ee33a@mail.gmail.com>
Message-ID: <69d8d540908052236g6e298df4j42e3fec78a7826e@mail.gmail.com>

On Wed, Aug 5, 2009 at 11:22 PM, Pieter
Eendebak<pieter.eendebak at gmail.com> wrote:
> Attached is a patch with a test for the setxor function.
>

It seems to update the wrong ChangeLog file. When changing anything in
scripts, you should add entry to scripts/ChangeLog etc.
Always the nearest ChangeLog file up the path tree.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

From bpabbott at mac.com  Thu Aug  6 06:59:36 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Thu, 06 Aug 2009 07:59:36 -0400
Subject: Can't set xticklabel
In-Reply-To: <69d8d540908052228o4d986b81m937983eab5c0de13@mail.gmail.com>
References: <4A70ADF8.6070809@fuw.edu.pl>
	<6AF78D0A-4B4C-4C90-9E1E-124723AE663D@mac.com>
	<052FF5C8-FF20-45EB-A99C-D12777184018@mac.com>
	<69d8d540908052228o4d986b81m937983eab5c0de13@mail.gmail.com>
Message-ID: <3BCE0482-2990-464C-A18C-5A315FAF60E5@mac.com>

On Aug 6, 2009, at 1:28 AM, Jaroslav Hajek wrote:

> On Thu, Jul 30, 2009 at 2:11 AM, Ben Abbott<bpabbott at mac.com> wrote:
>> On Jul 29, 2009, at 7:08 PM, Ben Abbott wrote:
>>
>>> On Jul 29, 2009, at 4:15 PM, Antoni Aduszkiewicz wrote:
>>>
>>>> Bug report for Octave 3.2.0 configured for i686-pc-linux-gnu
>>>>
>>>> Description:
>>>> -----------
>>>> % The following short example script
>>>>
>>>> x = 0:0.1:10;
>>>> y = sin(x);
>>>>
>>>> xtick = 0:pi:10;
>>>> xticklabel = [" 0 "; " pi"; "2pi"; "3pi"];
>>>>
>>>> plot(x,y)
>>>> set(gca, "xtick",xtick, "xticklabel", xticklabel);
>>>>
>>>> %END
>>>
>>> There are several quick fixes. One is
>>>
>>>        set (gca, "xtick", xtick, "xticklabel", "0|pi|2pi|3pi")
>>>
>>> Another that will use the Greek version is ...
>>>
>>>        set (gca, "xtick", xtick, "xticklabel", "0|\\pi|2\\pi|3\\pi")
>>>
>>> In any event, I'll take a look at a changeset.
>>>
>>> Ben
>>
>> I've pushed a changeset
>>
>>        http://hg.savannah.gnu.org/hgweb/octave/rev/303f862a896d
>>
>> Jaroslav, you may want to transplant into 3.2 ... but I think the  
>> sources
>> have branched so there may be problems.
>>
>
> It seems to apply, so I suppose it should work.
>
> Btw. It would help me a little if you avoided extending previously
> created ChangeLog entries and rather started new ones, at least for
> unrelated changes like this. That way, the transplant goes smoothly,
> without the need of manual intervention.
>
> thanks

No problem. For some reason, I was under the impression that extending  
them was desired.

Ben



From highegg at gmail.com  Thu Aug  6 07:12:32 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 6 Aug 2009 14:12:32 +0200
Subject: Can't set xticklabel
In-Reply-To: <3BCE0482-2990-464C-A18C-5A315FAF60E5@mac.com>
References: <4A70ADF8.6070809@fuw.edu.pl>
	<6AF78D0A-4B4C-4C90-9E1E-124723AE663D@mac.com>
	<052FF5C8-FF20-45EB-A99C-D12777184018@mac.com>
	<69d8d540908052228o4d986b81m937983eab5c0de13@mail.gmail.com>
	<3BCE0482-2990-464C-A18C-5A315FAF60E5@mac.com>
Message-ID: <69d8d540908060512w55b585cds4363ab6d70acd0c5@mail.gmail.com>

On Thu, Aug 6, 2009 at 1:59 PM, Ben Abbott<bpabbott at mac.com> wrote:
> On Aug 6, 2009, at 1:28 AM, Jaroslav Hajek wrote:
>
>> On Thu, Jul 30, 2009 at 2:11 AM, Ben Abbott<bpabbott at mac.com> wrote:
>>>
>>> On Jul 29, 2009, at 7:08 PM, Ben Abbott wrote:
>>>
>>>> On Jul 29, 2009, at 4:15 PM, Antoni Aduszkiewicz wrote:
>>>>
>>>>> Bug report for Octave 3.2.0 configured for i686-pc-linux-gnu
>>>>>
>>>>> Description:
>>>>> -----------
>>>>> % The following short example script
>>>>>
>>>>> x = 0:0.1:10;
>>>>> y = sin(x);
>>>>>
>>>>> xtick = 0:pi:10;
>>>>> xticklabel = [" 0 "; " pi"; "2pi"; "3pi"];
>>>>>
>>>>> plot(x,y)
>>>>> set(gca, "xtick",xtick, "xticklabel", xticklabel);
>>>>>
>>>>> %END
>>>>
>>>> There are several quick fixes. One is
>>>>
>>>> ? ? ? set (gca, "xtick", xtick, "xticklabel", "0|pi|2pi|3pi")
>>>>
>>>> Another that will use the Greek version is ...
>>>>
>>>> ? ? ? set (gca, "xtick", xtick, "xticklabel", "0|\\pi|2\\pi|3\\pi")
>>>>
>>>> In any event, I'll take a look at a changeset.
>>>>
>>>> Ben
>>>
>>> I've pushed a changeset
>>>
>>> ? ? ? http://hg.savannah.gnu.org/hgweb/octave/rev/303f862a896d
>>>
>>> Jaroslav, you may want to transplant into 3.2 ... but I think the sources
>>> have branched so there may be problems.
>>>
>>
>> It seems to apply, so I suppose it should work.
>>
>> Btw. It would help me a little if you avoided extending previously
>> created ChangeLog entries and rather started new ones, at least for
>> unrelated changes like this. That way, the transplant goes smoothly,
>> without the need of manual intervention.
>>
>> thanks
>
> No problem. For some reason, I was under the impression that extending them
> was desired.
>

I thought people tend to do it because that's how Vim and Emacs are
configured by default.
However, I daresay my reasons (smooth transplants) are more important :)
Actually, they're only smooth because I hacked Mercurial (otherwise
conflict would always occur for mismatching previous entry),
but it is saving me a lot of work in the overwhelming case where an
entry is merely prepended to the file.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From pieter.eendebak at gmail.com  Thu Aug  6 07:40:53 2009
From: pieter.eendebak at gmail.com (Pieter Eendebak)
Date: Thu, 6 Aug 2009 14:40:53 +0200
Subject: setxor patch
Message-ID: <2fb2ee070908060540u71a61fd6yfc50b57fdb1c5d8@mail.gmail.com>

The patch adds a test to the setxor function (now with correct ChangeLog)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setxor-test.patch
Type: text/x-patch
Size: 1084 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090806/2f501e6a/attachment.bin 

From highegg at gmail.com  Thu Aug  6 09:29:31 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 6 Aug 2009 16:29:31 +0200
Subject: setxor patch
In-Reply-To: <2fb2ee070908060540u71a61fd6yfc50b57fdb1c5d8@mail.gmail.com>
References: <2fb2ee070908060540u71a61fd6yfc50b57fdb1c5d8@mail.gmail.com>
Message-ID: <69d8d540908060729q277bcf5aj2616bc6465ee3d0f@mail.gmail.com>

On Thu, Aug 6, 2009 at 2:40 PM, Pieter
Eendebak<pieter.eendebak at gmail.com> wrote:
> The patch adds a test to the setxor function (now with correct ChangeLog)
>

I applied it.


-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

From kingcrimson at tiscali.it  Thu Aug  6 11:37:36 2009
From: kingcrimson at tiscali.it (c.)
Date: Thu, 6 Aug 2009 18:37:36 +0200
Subject: removing columns
Message-ID: <E4A10943-A6CA-4D95-A2F9-17EBB5DA8CD9@tiscali.it>


Hi,

I just noticed the following bug when trying to remove columns of a  
diagonal matrix:
----------------
 >> version
ans = 3.2.2
 >> P = rand (4)
P =

    0.95137   0.55747   0.25235   0.94716
    0.72572   0.87972   0.21516   0.64669
    0.88674   0.50588   0.28819   0.86791
    0.54547   0.31508   0.65510   0.28663

 >> P(:,3) = []
P =

    0.95137   0.55747   0.94716
    0.72572   0.87972   0.64669
    0.88674   0.50588   0.86791
    0.54547   0.31508   0.28663

 >> P = eye (4);
 >> P(:,3) = []
error: A(I,J,...) = X: dimensions mismatch
----------------

of course the behaviour in matlab is different:

----------------
ans =
7.7.0.471 (R2008b)
 >> P = eye (4);
 >> P (3,:) = []
P =
      1     0     0     0
      0     1     0     0
      0     0     0     1
 >> version
----------------

cheers,
Carlo

From jwe at octave.org  Thu Aug  6 12:43:32 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 13:43:32 -0400
Subject: removing columns
In-Reply-To: <E4A10943-A6CA-4D95-A2F9-17EBB5DA8CD9@tiscali.it>
References: <E4A10943-A6CA-4D95-A2F9-17EBB5DA8CD9@tiscali.it>
Message-ID: <19067.5700.109720.686556@segfault.lan>

On  6-Aug-2009, c. wrote:

| Hi,
| 
| I just noticed the following bug when trying to remove columns of a  
| diagonal matrix:
| ----------------
|  >> version
| ans = 3.2.2
|  >> P = rand (4)
| P =
| 
|     0.95137   0.55747   0.25235   0.94716
|     0.72572   0.87972   0.21516   0.64669
|     0.88674   0.50588   0.28819   0.86791
|     0.54547   0.31508   0.65510   0.28663
| 
|  >> P(:,3) = []
| P =
| 
|     0.95137   0.55747   0.94716
|     0.72572   0.87972   0.64669
|     0.88674   0.50588   0.86791
|     0.54547   0.31508   0.28663
| 
|  >> P = eye (4);
|  >> P(:,3) = []
| error: A(I,J,...) = X: dimensions mismatch

I checked in the following change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/d5570d4b1116

Thanks,

jwe

From jwe at octave.org  Thu Aug  6 13:29:44 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 14:29:44 -0400
Subject: bug in std.m
In-Reply-To: <20090805100310.137970@gmx.net>
References: <20090805100310.137970@gmx.net>
Message-ID: <19067.8472.459093.991495@segfault.lan>

On  5-Aug-2009, Christoph Ellenberger wrote:

| I don't know if this was already reported or fixed, but I didn't found anything in the bug archive.
| 
| I am using the MinGW version 3.2.0 for windows from sourceforge and there I encountered the following.
| 
| error: `sz' undefined near line 79 column 21
| error: evaluating argument list element number 1
| error: evaluating argument list element number 1
| error: called from:
| error:   C:\Programme\Octave\3.2.0_gcc-4.3.0\share\octave\3.2.0\m\statistics\base\std.m at line 79, column 12
| 
| instead of:
|  
|   if (n == 1)
|     retval = zeros (sz);
|   elseif (numel (a) > 0)
|     retval = sqrt (sumsq (center (a, dim), dim) / (n + opt - 1));
|   else
|     error ("std: x must not be empty");
|   endif
| 
| I guess it should be something like
| 
|   if (n == 1)
|     retval = zeros (size(a));
|   elseif (numel (a) > 0)
|     retval = sqrt (sumsq (center (a, dim), dim) / (n + opt - 1));
|   else
|     error ("std: x must not be empty");
|   endif
| 
| but I am not sure what the intended behaviour should be according to matlab compatibility...

I checked in the following change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/bb37822e9b82

Thanks,

jwe

From jwe at octave.org  Thu Aug  6 13:42:57 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 14:42:57 -0400
Subject: set() options
In-Reply-To: <Pine.LNX.4.64.0908031637390.7224@monoceros.physics.muni.cz>
References: <Pine.LNX.4.64.0908031637390.7224@monoceros.physics.muni.cz>
Message-ID: <19067.9265.461926.568578@segfault.lan>

On  3-Aug-2009, Petr Mikulik wrote:

| In Matlab, the set() command without all arguments gives a hint message.
| For example
| 	plot(1:10)
| 	set(gca, 'Visible')
| shows
| 	[ {on} | off ]
| i.e. all available options for the 'Visible' keyword.
| 
| In Octave, this produces an error:
| error: set: invalid number of arguments
| 
| The former approach is much more user-friendly as it gives user an idea what 
| to set there. Could this work also in Octave?

This feature has already been requested.  It is not a high priority
for me, but if someone submitted a patch, I would be happy to consider
it.

jwe

From jwe at octave.org  Thu Aug  6 13:45:58 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 14:45:58 -0400
Subject: -lltdl
In-Reply-To: <Pine.LNX.4.64.0908031627580.6316@monoceros.physics.muni.cz>
References: <Pine.LNX.4.64.0908031315290.24010@monoceros.physics.muni.cz>
	<Pine.LNX.4.64.0908031627580.6316@monoceros.physics.muni.cz>
Message-ID: <19067.9446.442353.214245@segfault.lan>

On  3-Aug-2009, Petr Mikulik wrote:

| The same problem appears also during making octave-3.2.2.tar.bz2.
| 
| > I've tried to hg pull/update/autogen/configure/make Octave on OpenSUSE 11.1. 
| > Development headers of ImageMagick are installed.
| > 
| > Making Octave fails here:
| > 
| > g++ -shared -o __magick_read__.oct pic/__magick_read__.o -L../libcruft
| > -lcruft -L../liboctave -loctave -L. -loctinterp        -lblas -lfftw3
| > -lfftw3f -lreadline  -lncurses -ldl -lblas -lhdf5 -lz -lm  -lfreetype -lz
| > -L/usr/X11R6/lib -lGL -lGLU -L/usr/X11R6/lib
| > -L/usr/lib/gcc/i586-suse-linux/4.3
| > -L/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/lib
| > -L/usr/lib/gcc/i586-suse-linux/4.3/../../.. -lhdf5 -lz -lgfortranbegin
| > -lgfortran -lm -lfreetype -lGL -lGLU -lGraphicsMagick++ -lGraphicsMagick
| > -llcms -lfreetype -lXext -lSM -lICE -lX11 -lbz2 -lz -lm -lgomp -lpthread
| > -lltdl
| > 
| > with this message:
| > 	ld: cannot find -lltdl
| > 
| > Linking proceeds fine if the "-lltdl" string is deleted.
| > Where does this requirement come from?

Most likely it comes from the list of libraries printed by

  GraphicsMagick++-config --libs

What does that command show on your system?

jwe

From jwe at octave.org  Thu Aug  6 14:10:35 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 15:10:35 -0400
Subject: Bug in 'compass' function; Color cannot be changed
In-Reply-To: <927983.50862.qm@web52812.mail.re2.yahoo.com>
References: <927983.50862.qm@web52812.mail.re2.yahoo.com>
Message-ID: <19067.10923.21098.735655@segfault.lan>

On  2-Aug-2009, Emmanuel De Paepe wrote:

| The colour property of the 'compass' function cannot be changed:
| For example:
| 
| %%%
| A = 10+8*j;
| compass(A,"r")
| %%%
| 
| generates an error instead of red arrow.
| I do not see this this error in similar functions like 'feather','quiver', etc...

I also see the same problem in feather.  I checked in the following
change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/69a57c59868c

Thanks,

jwe

From highegg at gmail.com  Thu Aug  6 14:33:43 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 6 Aug 2009 21:33:43 +0200
Subject: removing columns
In-Reply-To: <19067.5700.109720.686556@segfault.lan>
References: <E4A10943-A6CA-4D95-A2F9-17EBB5DA8CD9@tiscali.it>
	<19067.5700.109720.686556@segfault.lan>
Message-ID: <69d8d540908061233o2314d94h76ce1c82ce94d7e9@mail.gmail.com>

On Thu, Aug 6, 2009 at 7:43 PM, John W. Eaton<jwe at octave.org> wrote:
> On ?6-Aug-2009, c. wrote:
>
> | Hi,
> |
> | I just noticed the following bug when trying to remove columns of a
> | diagonal matrix:
> | ----------------
> | ?>> version
> | ans = 3.2.2
> | ?>> P = rand (4)
> | P =
> |
> | ? ? 0.95137 ? 0.55747 ? 0.25235 ? 0.94716
> | ? ? 0.72572 ? 0.87972 ? 0.21516 ? 0.64669
> | ? ? 0.88674 ? 0.50588 ? 0.28819 ? 0.86791
> | ? ? 0.54547 ? 0.31508 ? 0.65510 ? 0.28663
> |
> | ?>> P(:,3) = []
> | P =
> |
> | ? ? 0.95137 ? 0.55747 ? 0.94716
> | ? ? 0.72572 ? 0.87972 ? 0.64669
> | ? ? 0.88674 ? 0.50588 ? 0.86791
> | ? ? 0.54547 ? 0.31508 ? 0.28663
> |
> | ?>> P = eye (4);
> | ?>> P(:,3) = []
> | error: A(I,J,...) = X: dimensions mismatch
>
> I checked in the following change.
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/d5570d4b1116
>
> Thanks,
>
> jwe

For consistency with the full case, I added by
http://hg.savannah.gnu.org/hgweb/octave/rev/edc657b9ec8a

also support for
a(idx) = ''
a(idx) = ""

I think these (or at least the first one) work for all matrices (not
just strings) due to Matlab compatibility. Is everybody OK with this?
While for a string any of the 3 forms is expectable, for numeric
matrices deleting using = '' is quite unusual and may be more likely a
bug. Perhaps Octave should give an error instead? Opinions?

-- 
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  Thu Aug  6 15:57:17 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 16:57:17 -0400
Subject: removing columns
In-Reply-To: <69d8d540908061233o2314d94h76ce1c82ce94d7e9@mail.gmail.com>
References: <E4A10943-A6CA-4D95-A2F9-17EBB5DA8CD9@tiscali.it>
	<19067.5700.109720.686556@segfault.lan>
	<69d8d540908061233o2314d94h76ce1c82ce94d7e9@mail.gmail.com>
Message-ID: <19067.17325.285419.284936@segfault.lan>

On  6-Aug-2009, Jaroslav Hajek wrote:

| For consistency with the full case, I added by
| http://hg.savannah.gnu.org/hgweb/octave/rev/edc657b9ec8a
| 
| also support for
| a(idx) = ''
| a(idx) = ""
| 
| I think these (or at least the first one) work for all matrices (not
| just strings) due to Matlab compatibility. Is everybody OK with this?
| While for a string any of the 3 forms is expectable, for numeric
| matrices deleting using = '' is quite unusual and may be more likely a
| bug. Perhaps Octave should give an error instead? Opinions?

It does seem strange to allow '' to delete elements from numeric matrices,
but I think this is needed for compatibility.  I don't see that it
does much harm, so I'd say keep this behavior.

jwe

From mikulik at physics.muni.cz  Fri Aug  7 00:30:24 2009
From: mikulik at physics.muni.cz (Petr Mikulik)
Date: Fri, 7 Aug 2009 07:30:24 +0200 (CEST)
Subject: -lltdl
In-Reply-To: <19067.9446.442353.214245@segfault.lan>
References: <Pine.LNX.4.64.0908031315290.24010@monoceros.physics.muni.cz>
	<Pine.LNX.4.64.0908031627580.6316@monoceros.physics.muni.cz>
	<19067.9446.442353.214245@segfault.lan>
Message-ID: <Pine.LNX.4.64.0908070729470.7642@monoceros.physics.muni.cz>

> | The same problem appears also during making octave-3.2.2.tar.bz2.
> | 
> | > I've tried to hg pull/update/autogen/configure/make Octave on OpenSUSE 11.1. 
> | > Development headers of ImageMagick are installed.
> | > 
> | > Making Octave fails here:
> | > 
> | > g++ -shared -o __magick_read__.oct pic/__magick_read__.o -L../libcruft
> | > -lcruft -L../liboctave -loctave -L. -loctinterp        -lblas -lfftw3
> | > -lfftw3f -lreadline  -lncurses -ldl -lblas -lhdf5 -lz -lm  -lfreetype -lz
> | > -L/usr/X11R6/lib -lGL -lGLU -L/usr/X11R6/lib
> | > -L/usr/lib/gcc/i586-suse-linux/4.3
> | > -L/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/lib
> | > -L/usr/lib/gcc/i586-suse-linux/4.3/../../.. -lhdf5 -lz -lgfortranbegin
> | > -lgfortran -lm -lfreetype -lGL -lGLU -lGraphicsMagick++ -lGraphicsMagick
> | > -llcms -lfreetype -lXext -lSM -lICE -lX11 -lbz2 -lz -lm -lgomp -lpthread
> | > -lltdl
> | > 
> | > with this message:
> | > 	ld: cannot find -lltdl
> | > 
> | > Linking proceeds fine if the "-lltdl" string is deleted.
> | > Where does this requirement come from?
> 
> Most likely it comes from the list of libraries printed by
> 
>   GraphicsMagick++-config --libs
> 
> What does that command show on your system?

Yes, it's really there:

-lGraphicsMagick++ -lGraphicsMagick -llcms -lfreetype -lXext -lSM -lICE 
-lX11 -lbz2 -lz -lm -lgomp -lpthread -lltdl


---
PM

From jwe at octave.org  Fri Aug  7 13:06:21 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 7 Aug 2009 14:06:21 -0400
Subject: can this compile on vs2008 or not
In-Reply-To: <20090803005852.83646.qmail@web3815.mail.bbt.yahoo.co.jp>
References: <20090802234019.40434.qmail@web3815.mail.bbt.yahoo.co.jp>
	<20090803005852.83646.qmail@web3815.mail.bbt.yahoo.co.jp>
Message-ID: <19068.27933.182195.334409@segfault.lan>

On  3-Aug-2009, Tatsuro MATSUOKA wrote:

| Certainly readme.msvc is still on the source package and the some of
| information is too old.  I think it should be removed from source tar ball.

Maybe it should be updated instead?

jwe

From jwe at octave.org  Fri Aug  7 13:09:52 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 7 Aug 2009 14:09:52 -0400
Subject: error compiling Octave 3.2.2 with Magick++ under CentOS 5.3
In-Reply-To: <24772134.post@talk.nabble.com>
References: <24772134.post@talk.nabble.com>
Message-ID: <19068.28144.215533.545367@segfault.lan>

On  1-Aug-2009, Les Klimczak wrote:

| There seems to be some issue with how 'typedef' behaves in C++ namespaces. I
| was able to fix it, but don't have a satisfactory explanation for the
| problem.
| Maybe someone has more insight here?
| 
| Les Klimczak, Ph.D.
| Research Informatics Consultant
| San Francisco, CA - Madison, WI - Gaithersburg, MD
| 
| Configuration:
| 
| CentOS 5.3
| octave-3.2.2.tar.gz
| 
| ImageMagick-c++-devel-6.2.8.0-4.el5_1.1
| ImageMagick-c++-6.2.8.0-4.el5_1.1
| or
| GraphicsMagick-1.3.5.tar.gz
| 
| ./configure F77=gfortran
| 
| 
| Problem:
| 
| g++ -c   -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc
| -DHAVE_CONFIG_H -mieee-fp -I/usr/include/freetype2 -Wall -W -Wshadow
| -Wold-style-cast -Wformat -g -O2 ./DLD-FUNCTIONS/__magick_read__.cc -o
| pic/__magick_read__.o
| 
| ./DLD-FUNCTIONS/__magick_read__.cc: In function ?unsigned int
| scale_quantum_to_depth(const MagickLib::Quantum&, unsigned int)?:
| ./DLD-FUNCTIONS/__magick_read__.cc:45: error: ?Quantum? was not declared in
| this scope
| 
| Fix:
| 
| $ diff -cr octave-3.2.2/src/DLD-FUNCTIONS/__magick_read__.cc
| octave-3.2.2/src/DLD-FUNCTIONS/__magick_read__.cc.fix
| *** octave-3.2.2/src/DLD-FUNCTIONS/__magick_read__.cc   2009-05-28
| 00:57:14.000000000 -0500
| --- octave-3.2.2/src/DLD-FUNCTIONS/__magick_read__.cc.fix       2009-07-29
| 17:46:57.000000000 -0500
| ***************
| *** 34,42 ****
|   #ifdef HAVE_MAGICK
|   
|   #include <GraphicsMagick/Magick++.h>
|   
|   unsigned int
| ! scale_quantum_to_depth (const Magick::Quantum& quantum, unsigned int
| depth)
|   {
|     return (static_cast<unsigned int> (static_cast<double> (quantum)
|                                        / MaxRGB * ((1 << depth) - 1)));
| --- 34,43 ----
|   #ifdef HAVE_MAGICK
|   
|   #include <GraphicsMagick/Magick++.h>
| + typedef Magick::Quantum Quantum;
|   
|   unsigned int
| ! scale_quantum_to_depth (const Quantum& quantum, unsigned int depth)
|   {
|     return (static_cast<unsigned int> (static_cast<double> (quantum)
|                                        / MaxRGB * ((1 << depth) - 1)));

What version of GCC do you have?

I don't see this error with GraphicsMagick 1.3.5 on a Debian system
when I'm compiling with GCC 4.3.3

jwe

From tmacchant at yahoo.co.jp  Fri Aug  7 16:17:59 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Sat, 8 Aug 2009 06:17:59 +0900 (JST)
Subject: can this compile on vs2008 or not
In-Reply-To: <19068.27933.182195.334409@segfault.lan>
Message-ID: <20090807211759.75337.qmail@web3815.mail.bbt.yahoo.co.jp>

Hello

--- "John W. Eaton" wrote:

> On  3-Aug-2009, Tatsuro MATSUOKA wrote:
> 
> | Certainly readme.msvc is still on the source package and the some of
> | information is too old.  I think it should be removed from source tar ball.
> 
> Maybe it should be updated instead?

Michael himself have been working for octave development branch by MSVC complier.
Of course, if Michael will update README.MSVC, it will be desirable than be removed.

Regards

Tatsuro  

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

From michael.goffioul at gmail.com  Fri Aug  7 16:44:57 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Fri, 7 Aug 2009 22:44:57 +0100
Subject: can this compile on vs2008 or not
In-Reply-To: <20090807211759.75337.qmail@web3815.mail.bbt.yahoo.co.jp>
References: <19068.27933.182195.334409@segfault.lan>
	<20090807211759.75337.qmail@web3815.mail.bbt.yahoo.co.jp>
Message-ID: <128f38bd0908071444h4eb5bc7tb895bcedcf17fc06@mail.gmail.com>

On Fri, Aug 7, 2009 at 10:17 PM, Tatsuro MATSUOKA<tmacchant at yahoo.co.jp> wrote:
> Hello
>
> --- "John W. Eaton" wrote:
>
>> On ?3-Aug-2009, Tatsuro MATSUOKA wrote:
>>
>> | Certainly readme.msvc is still on the source package and the some of
>> | information is too old. ?I think it should be removed from source tar ball.
>>
>> Maybe it should be updated instead?
>
> Michael himself have been working for octave development branch by MSVC complier.
> Of course, if Michael will update README.MSVC, it will be desirable than be removed.

To be honest, I have no plan to update it. It's now unsupported and
should be removed to avoid confusing users.

Michael.


From les_klimczak at yahoo.com  Fri Aug  7 22:08:24 2009
From: les_klimczak at yahoo.com (Les Klimczak)
Date: Fri, 7 Aug 2009 20:08:24 -0700 (PDT)
Subject: error compiling Octave 3.2.2 with Magick++ under CentOS 5.3
In-Reply-To: <19068.28144.215533.545367@segfault.lan>
References: <24772134.post@talk.nabble.com>
	<19068.28144.215533.545367@segfault.lan>
Message-ID: <24874689.post@talk.nabble.com>


$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)


John W. Eaton-3 wrote:
> 
> 
> What version of GCC do you have?
> 
> I don't see this error with GraphicsMagick 1.3.5 on a Debian system
> when I'm compiling with GCC 4.3.3
> 
> jwe
> 
> 

-- 
View this message in context: http://www.nabble.com/error-compiling-Octave-3.2.2-with-Magick%2B%2B-under-CentOS-5.3-tp24772134p24874689.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From les_klimczak at yahoo.com  Fri Aug  7 22:18:53 2009
From: les_klimczak at yahoo.com (Les Klimczak)
Date: Fri, 7 Aug 2009 20:18:53 -0700 (PDT)
Subject: image handling problems in Octave 3.2.2 under CentOS 5.3
Message-ID: <24874690.post@talk.nabble.com>


Here are some issues I encountered while trying to get Octave 3.2.2 to work
under CentOS 5.3.

Les Klimczak, Ph.D.
Research Informatics Consultant
San Francisco, CA - Madison, WI - Gaithersburg, MD 

1. 'imshow' will still call gnuplot even if version 4.2 is not available
(gnuplot-4.0.0-14.el5 comes with the system) and
image_viewer("/usr/bin/display %s") was set. In addition to giving gnuplot
errors, this exposes a potential bug in imshow.m et al.:
error: Invalid call to strcat.  Correct usage is:

 -- Function File:  strcat (S1, S2, ...)

This originates from __gnuplot_get_var__.m when an empty cell object is
passed to 'strcat'

octave:211> strcat(str{:})
ans = aabb
octave:212> str2 = {};
octave:213> strcat(str2{:})
error: Invalid call to strcat.  Correct usage is:

 -- Function File:  strcat (S1, S2, ...)

To fix this, I checked for this condition:

diff -cr octave-3.2.2/scripts/plot/__gnuplot_get_var__.m
octave-3.2.2/scripts/plot/__gnuplot_get_var__.m.fix
*** octave-3.2.2/scripts/plot/__gnuplot_get_var__.m     2009-06-02
00:22:16.0000
00000 -0500
--- octave-3.2.2/scripts/plot/__gnuplot_get_var__.m.fix 2009-07-30
17:45:38.0000
00000 -0500
***************
*** 110,116 ****
            str = str(1:(end-1));
          endif
        endwhile
!       str = strcat (str{:});
        fclose (gpin);
      else
        ## Direct gnuplot to print to <STDOUT>
--- 110,122 ----
            str = str(1:(end-1));
          endif
        endwhile
! 
!       if (length(str)==0)
!                       str = ""
!                       else
!                       str = strcat (str{:});
!                       endif
! 
        fclose (gpin);
      else
        ## Direct gnuplot to print to <STDOUT>

This problem stopped manifesting itself after I upgraded to
gnuplot-4.2.5.tar.gz


2. in saveimage.m, 'map' is assumed to have always real values 0:1, but
rgb2ind(img) generates it as integers 0:255. This results in color images
having only primary colors.

Again, I introduced a check:

diff -cr octave-3.2.2/scripts/image/saveimage.m
octave-3.2.2/scripts/image/saveimage.m.fix
*** octave-3.2.2/scripts/image/saveimage.m      2009-05-25
01:04:59.000000000 -0
500
--- octave-3.2.2/scripts/image/saveimage.m.fix  2009-07-30
19:40:17.000000000 -0
500
***************
*** 129,138 ****
--- 129,140 ----
  
    map = reshape (map, map_sz, 1);
  
+       if (max(map) < 2)
    map (map > 1) = 1;
    map (map < 0) = 0;
  
    map = round (255 * map);
+       endif
  
    bw = (map_nr == 2
          && ((map(1,1) == 0 && map(2,1) == 255)


-- 
View this message in context: http://www.nabble.com/image-handling-problems-in-Octave-3.2.2-under-CentOS-5.3-tp24874690p24874690.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From ladledaisy at yahoo.com  Sat Aug  8 15:56:36 2009
From: ladledaisy at yahoo.com (Don Guy)
Date: Sat, 8 Aug 2009 13:56:36 -0700 (PDT)
Subject: behavior of "whos" command very different from Matlab
Message-ID: <120236.2854.qm@web57303.mail.re1.yahoo.com>

I notice that "whos" in octave returns a whole lot of information about a whole variety of variables, even when there are no variables in the workspace. This is quite different behavior from matlab, where whos only returns information about variables that currently exist in the workspace. I would consider this to be a serious incompatibility.Is there any way to configure it to behave the same?



      



From jwe at octave.org  Sat Aug  8 16:52:33 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 8 Aug 2009 17:52:33 -0400
Subject: behavior of "whos" command very different from Matlab
In-Reply-To: <120236.2854.qm@web57303.mail.re1.yahoo.com>
References: <120236.2854.qm@web57303.mail.re1.yahoo.com>
Message-ID: <19069.62369.885090.283375@segfault.lan>

On  8-Aug-2009, Don Guy wrote:

| I notice that "whos" in octave returns a whole lot of information
| about a whole variety of variables, even when there are no variables
| in the workspace. This is quite different behavior from matlab,
| where whos only returns information about variables that currently
| exist in the workspace. I would consider this to be a serious
| incompatibility.Is there any way to configure it to behave the same?

What version of Octave are you using?  The current stable version,
3.2.2 reports

  octave:1> who
  Variables in the current scope:

  ans

  octave:2> whos
  Variables in the current scope:

    Attr Name        Size                     Bytes  Class
    ==== ====        ====                     =====  ===== 
	 ans         1x11                        92  cell

  Total is 11 elements using 92 bytes

So maybe you just need to upgrade to a newer version?

jwe

From danny at fftransforms.com  Sun Aug  9 03:18:37 2009
From: danny at fftransforms.com (Danny Keogan)
Date: Sun, 9 Aug 2009 01:18:37 -0700
Subject: evalin in errors out on undefined variable rather than using catch
	argument
Message-ID: <009101ca18c9$ff6a2540$fe3e6fc0$@com>

--------
Bug report for Octave 3.2.2 configured for x86_64-unknown-linux-gnu

Description:
-----------

If you execute the following, where undefined_variable is undefined:

base_value = evalin('base', 'undefined_variable', '[]');

rather than base_value being assigned [] you get the following:

ans = [](0x0)
error: value on right hand side of assignment is undefined

Repeat-By:
---------

To demonstrate the problem in the 'base' context follow the instructions
above.

To see the same problem in the 'caller' context do the following:

Create a file "evalin_bug.m" with the following contents:

function evalin_bug
caller_value = evalin('caller', 'undefined_variable', '[]');

Call the function 

Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Linux vbubuntu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17
01:58:03 UTC 2009 x86_64 GNU/Linux
configure opts:   
Fortran compiler: gfortran
FFLAGS:           -O
FLIBS:            -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3
-L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-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:           -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.2
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lblas -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_QHULL=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_GL_GL_H=1
  -DHAVE_FLTK=1 -DHAVE_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ## _
  -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=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=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.2/site/exec/x86_64-unknown-linux-gnu:/usr/loca
l/libexec/octave/api-v37/site/exec/x86_64-unknown-linux-gnu:/usr/local/libex
ec/octave/site/exec/x86_64-unknown-linux-gnu:/usr/local/libexec/octave/3.2.2
/exec/x86_64-unknown-linux-gnu:/usr/local/bin:/usr/local/sbin:/usr/local/bin
:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
  IMAGE_PATH = .:/usr/local/share/octave/3.2.2/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/danny/.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 = <no value or error in displaying it>
  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 Aug  9 05:42:59 2009
From: jwe at octave.org (John W. Eaton)
Date: Sun, 9 Aug 2009 06:42:59 -0400
Subject: evalin in errors out on undefined variable rather than using catch
	argument
In-Reply-To: <009101ca18c9$ff6a2540$fe3e6fc0$@com>
References: <009101ca18c9$ff6a2540$fe3e6fc0$@com>
Message-ID: <19070.43059.851498.505719@segfault.lan>

On  9-Aug-2009, Danny Keogan wrote:

| --------
| Bug report for Octave 3.2.2 configured for x86_64-unknown-linux-gnu
| 
| Description:
| -----------
| 
| If you execute the following, where undefined_variable is undefined:
| 
| base_value = evalin('base', 'undefined_variable', '[]');
| 
| rather than base_value being assigned [] you get the following:
| 
| ans = [](0x0)
| error: value on right hand side of assignment is undefined
| 
| Repeat-By:
| ---------
| 
| To demonstrate the problem in the 'base' context follow the instructions
| above.
| 
| To see the same problem in the 'caller' context do the following:
| 
| Create a file "evalin_bug.m" with the following contents:
| 
| function evalin_bug
| caller_value = evalin('caller', 'undefined_variable', '[]');
| 
| Call the function 

I checked in the following change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/4562a9a730ae

Jaroslav, this could probably be applied to the 3.2.x release branch.

Thanks,

jwe

From highegg at gmail.com  Mon Aug 10 04:15:11 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 10 Aug 2009 11:15:11 +0200
Subject: evalin in errors out on undefined variable rather than using 
	catch argument
In-Reply-To: <19070.43059.851498.505719@segfault.lan>
References: <009101ca18c9$ff6a2540$fe3e6fc0$@com>
	<19070.43059.851498.505719@segfault.lan>
Message-ID: <69d8d540908100215x108f501fi34f244db28b340ea@mail.gmail.com>

On Sun, Aug 9, 2009 at 12:42 PM, John W. Eaton<jwe at octave.org> wrote:
> On ?9-Aug-2009, Danny Keogan wrote:
>
> | --------
> | Bug report for Octave 3.2.2 configured for x86_64-unknown-linux-gnu
> |
> | Description:
> | -----------
> |
> | If you execute the following, where undefined_variable is undefined:
> |
> | base_value = evalin('base', 'undefined_variable', '[]');
> |
> | rather than base_value being assigned [] you get the following:
> |
> | ans = [](0x0)
> | error: value on right hand side of assignment is undefined
> |
> | Repeat-By:
> | ---------
> |
> | To demonstrate the problem in the 'base' context follow the instructions
> | above.
> |
> | To see the same problem in the 'caller' context do the following:
> |
> | Create a file "evalin_bug.m" with the following contents:
> |
> | function evalin_bug
> | caller_value = evalin('caller', 'undefined_variable', '[]');
> |
> | Call the function
>
> I checked in the following change.
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/4562a9a730ae
>
> Jaroslav, this could probably be applied to the 3.2.x release branch.
>
> Thanks,

Applied.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From Thomas.Treichl at gmx.net  Tue Aug 11 02:40:54 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Tue, 11 Aug 2009 09:40:54 +0200
Subject: MacOSX: cannot link liboctinterp and octave anymore
Message-ID: <4A812086.8090806@gmx.net>

Hi,

I currently have big problems linking liboctave and the main binary with the 
development snapshot. This means that it doesn't work anymore. I've found this 
changeset

   changeset:   9490:3aeb7d881578
   user:        John W. Eaton <jwe at octave.org>
   date:        Wed Aug 05 16:11:06 2009 -0400
   summary:     clean up linker options

which I think causes the problems on my platform. I've attached a file error.txt 
that shows that many dependencies cannot be found anymore while linking. If I 
manually add the linker flags to OCTINTERP_LINK_DEPS in src/Makefile (which is 
enough, cf. attached file succ.txt)

   -L../libcruft -lcruft -lfftw3f -lfftw3

then linking of src/liboctinterp works, but linking octave still fails.

What is the best way that I get these definitions into src/Makefile.in again if 
you don't need it on GNU/Linux and others? Or must I do something completeley 
different now to get it working again?

Thanks for your help,

   Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: succ.txt
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090811/bd749105/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: error.txt
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090811/bd749105/attachment-0003.txt 

From individ at acc.umu.se  Tue Aug 11 04:31:59 2009
From: individ at acc.umu.se (David Grundberg)
Date: Tue, 11 Aug 2009 11:31:59 +0200
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <4A812086.8090806@gmx.net>
References: <4A812086.8090806@gmx.net>
Message-ID: <4A813A8F.5000302@acc.umu.se>

Thomas Treichl wrote:
> Hi,
>
> I currently have big problems linking liboctave and the main binary 
> with the development snapshot. This means that it doesn't work 
> anymore. I've found this changeset
>
>   changeset:   9490:3aeb7d881578
>   user:        John W. Eaton <jwe at octave.org>
>   date:        Wed Aug 05 16:11:06 2009 -0400
>   summary:     clean up linker options
>
> which I think causes the problems on my platform. I've attached a file 
> error.txt that shows that many dependencies cannot be found anymore 
> while linking. If I manually add the linker flags to 
> OCTINTERP_LINK_DEPS in src/Makefile (which is enough, cf. attached 
> file succ.txt)
>
>   -L../libcruft -lcruft -lfftw3f -lfftw3
>
> then linking of src/liboctinterp works, but linking octave still fails.
>
> What is the best way that I get these definitions into src/Makefile.in 
> again if you don't need it on GNU/Linux and others? Or must I do 
> something completeley different now to get it working again?
>
> Thanks for your help,
>
>   Thomas
> ------------------------------------------------------------------------
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

John,

is it possible to revert your change? I've got regressions too. And no 
benefits AFAIK.

David

From jwe at octave.org  Tue Aug 11 10:37:05 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 11 Aug 2009 11:37:05 -0400
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <4A812086.8090806@gmx.net>
References: <4A812086.8090806@gmx.net>
Message-ID: <19073.36897.995668.177155@segfault.lan>

On 11-Aug-2009, Thomas Treichl wrote:

| I currently have big problems linking liboctave and the main binary with the 
| development snapshot. This means that it doesn't work anymore. I've found this 
| changeset
| 
|    changeset:   9490:3aeb7d881578
|    user:        John W. Eaton <jwe at octave.org>
|    date:        Wed Aug 05 16:11:06 2009 -0400
|    summary:     clean up linker options
| 
| which I think causes the problems on my platform. I've attached a file error.txt 
| that shows that many dependencies cannot be found anymore while linking. If I 
| manually add the linker flags to OCTINTERP_LINK_DEPS in src/Makefile (which is 
| enough, cf. attached file succ.txt)
| 
|    -L../libcruft -lcruft -lfftw3f -lfftw3
| 
| then linking of src/liboctinterp works, but linking octave still fails.

So even though liboctave is linked with these libraries, and
liboctinterp is linked with liboctave, you must explicitly list them
again when linking liboctinterp?  Is there no option or other way to
link liboctinterp so that you don't need to list them twice?

What I'd like to be able to do is

  link libcruft with all its dependencies

  link liboctave with libcruft and any new dependencies, but not have
  to list the libcruft dependencies again


  link liboctinterp with liboctave and any new dependencies, but not
  have to list the liboctave or libcruft dependencies again

  link octave with liboctinterp and any new dependencies, but not have
  to list the liboctave or libcruft dependencies again

Is there a way to do this on an OS X system, or are we forced to know
all the dependencies of all the libraries in order to perform the
final link?

| _H5Fclose
| _H5Fcreate
| ...

This looks like a mistake.  The HDF5 libraries should be listed for
the liboctinterp link step, but they are only being listed in LIBS,
not in a separate variable.  I'll see about fixing that.

jwe

From jwe at octave.org  Tue Aug 11 10:37:45 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 11 Aug 2009 11:37:45 -0400
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <4A813A8F.5000302@acc.umu.se>
References: <4A812086.8090806@gmx.net>
	<4A813A8F.5000302@acc.umu.se>
Message-ID: <19073.36937.903371.755463@segfault.lan>

On 11-Aug-2009, David Grundberg wrote:

| is it possible to revert your change? I've got regressions too. And no 
| benefits AFAIK.

I'd rather fix it than simply undo it.

jwe

From highegg at gmail.com  Wed Aug 12 08:34:26 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 12 Aug 2009 15:34:26 +0200
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <19073.36937.903371.755463@segfault.lan>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
Message-ID: <69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>

On Tue, Aug 11, 2009 at 5:37 PM, John W. Eaton<jwe at octave.org> wrote:
> On 11-Aug-2009, David Grundberg wrote:
>
> | is it possible to revert your change? I've got regressions too. And no
> | benefits AFAIK.
>
> I'd rather fix it than simply undo it.
>
> jwe

My build setup with Intel C++ broke, too; libraries in non-standard
location specified in LDFLAGS could not be found.
Adding LDFLAGS to linking of both liboctave and liboctinterp
apparently solves the problem:
http://hg.savannah.gnu.org/hgweb/octave/rev/113dba092d8c

I'm still getting strange errors from the built executables, though,
even on my workstation where LDFLAGS is empty (and thus this change
was not necessary). I'll try to investigate what is wrong.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

From david0815 at gmx.de  Wed Aug 12 06:46:14 2009
From: david0815 at gmx.de (bat_boy)
Date: Wed, 12 Aug 2009 04:46:14 -0700 (PDT)
Subject: Set title to left corner doesnt work
Message-ID: <24934769.post@talk.nabble.com>


Hi folks!

I'd like to set the horizontal postition of the title in my plot to the left
corner.
When I plot and do this:

title("This is my awesome title");
yl = get (gca (), 'title');
get(get(gca()).title).horizontalalignment
set (yl, 'horizontalalignment', 'center');
get(get(gca()).title).horizontalalignment
set (yl, 'horizontalalignment', 'left');
get(get(gca()).title).horizontalalignment

the output is

ans = left
ans = center
ans = left

So it seems that the value is set to "left" as default. Even setting it to
"center" and to "left" afterwards doesnt have any effetct, the title remains
in the center. Do I miss something here?

Thanks!
David
-- 
View this message in context: http://www.nabble.com/Set-title-to-left-corner-doesnt-work-tp24934769p24934769.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From marco.caliari at univr.it  Wed Aug 12 09:04:50 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Wed, 12 Aug 2009 16:04:50 +0200 (CEST)
Subject: Dimensions mismatch
Message-ID: <alpine.DEB.1.00.0908121601280.8946@profs.sci.univr.it>

Dear maintainers,

I noticed that the following

octave:1> v(:,1:2)=[1,1]

gives

error: A(I,J,...) = X: dimensions mismatch

in Octave 3.2.2 whereas it works in Octave 3.0.5 and gives

v =

    1   1

No problem for, e.g.,

octave:2> v(:,1:2)=[1,1;2,2]
v =

    1   1
    2   2

Best regards,

Marco

From Thomas.Treichl at gmx.net  Wed Aug 12 13:25:44 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Wed, 12 Aug 2009 20:25:44 +0200
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <19074.57087.451333.870324@segfault.lan>
References: <4A812086.8090806@gmx.net>	<4A813A8F.5000302@acc.umu.se>	<19073.36937.903371.755463@segfault.lan>	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan>
Message-ID: <4A830928.5090904@gmx.net>

John W. Eaton schrieb:
> On 12-Aug-2009, Jaroslav Hajek wrote:
> 
> | On Tue, Aug 11, 2009 at 5:37 PM, John W. Eaton<jwe at octave.org> wrote:
> | > On 11-Aug-2009, David Grundberg wrote:
> | >
> | > | is it possible to revert your change? I've got regressions too. And no
> | > | benefits AFAIK.
> | >
> | > I'd rather fix it than simply undo it.
> | >
> | > jwe
> | 
> | My build setup with Intel C++ broke, too; libraries in non-standard
> | location specified in LDFLAGS could not be found.
> | Adding LDFLAGS to linking of both liboctave and liboctinterp
> | apparently solves the problem:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/113dba092d8c
> 
> OK, does this change solve the problem on OS X systems?

Sorry for my late answer, I'll try your changeset now and start a new build.
I was trying to solve the problem with some ld flags that I've found in the 
manpage - but none did bring me success. I've tried "-undefined dynamic_lookup" 
and "-r" for Mac's ld, cf.
  http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ld.1.html

but I don't know for sure if I was on the right way?

> Eventually, I'd like to have configure take options for include and
> link flags for each library.  So for example, users could specify all of
> 
>   --with-qhull=-lmyqhull
>   --with-hdf-ldflags=-L/my/qhull/lib
>   --with-qhull-cppflags=-I/my/qhull/include
> 
> These options would set variables like
> 
>   QHULL_LIBS
>   QHULL_LDFLAGS
>   QHULL_CPPFLAGS
> 
> in Makeconfig.  Then we could add these in specific places where they
> are needed rather than lumping them all together in every link step.
> I think this would help when linking with libraries installed in
> nonstandard locations, especially in cases where the library is only a
> dependency of a single .oct file.
> 
> I'd like to have an autoconf macro that will do this in a reasonably
> uniform way for all the optional libraries that are used by Octave so
> we can eliminate some of the custom code we currently have in the
> configure script, and so that the checks are performed in a more
> consistent way.

This (from my point of view) would really be a nice thing. All of my builds eg. 
are in a none standard directory somewhere inside of /tmp and a change like this 
would make things much easier I think. Eg. currently ./configure doesn't find 
any of GLPK anymore but I think this only is a problem of passing the right path 
information?! I'll look into this.

I'll report later, best regards,

   Thomas

From bpabbott at mac.com  Wed Aug 12 12:53:32 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 12 Aug 2009 13:53:32 -0400
Subject: Set title to left corner doesnt work
In-Reply-To: <24934769.post@talk.nabble.com>
References: <24934769.post@talk.nabble.com>
Message-ID: <8B33EC74-C909-4391-AD31-453818ECAC56@mac.com>

On Aug 12, 2009, at 7:46 AM, bat_boy wrote:

> Hi folks!
>
> I'd like to set the horizontal postition of the title in my plot to  
> the left
> corner.
> When I plot and do this:
>
> title("This is my awesome title");
> yl = get (gca (), 'title');
> get(get(gca()).title).horizontalalignment
> set (yl, 'horizontalalignment', 'center');
> get(get(gca()).title).horizontalalignment
> set (yl, 'horizontalalignment', 'left');
> get(get(gca()).title).horizontalalignment
>
> the output is
>
> ans = left
> ans = center
> ans = left
>
> So it seems that the value is set to "left" as default. Even setting  
> it to
> "center" and to "left" afterwards doesnt have any effetct, the title  
> remains
> in the center. Do I miss something here?
>
> Thanks!
> David

Hi David,

The functionality you're looking for is not yet supported by Octave.

As a work around you can try ...

text (0, 1.05, "This is my left aligned title", "horizontalalignment",  
"left", "units", "normalized")

Ben




From andrei.kramer at physik.hu-berlin.de  Wed Aug 12 12:26:50 2009
From: andrei.kramer at physik.hu-berlin.de (Andrei Kramer)
Date: Wed, 12 Aug 2009 19:26:50 +0200
Subject: LaTeX labels do not work as expected
Message-ID: <4A82FB5A.8020402@physik.hu-berlin.de>

--------
Bug report for Octave 3.0.3 configured for i686-pc-linux-gnu

Description:
-----------

it is very hard to include LaTeX code in labels for the terminal epslatex.
the \expressions are converted/interpreted even when using single quotes.

Repeat-By:
---------

plot(1:2,3:4)

OR

pkg load plot
plot(1:2,3:4)
tics(x,1:2,['$\theta_1$';'$\theta_2$'])

Fix:
---

Allow strings to be passed unaltered. If necessary, introduce a new
quoting style, which is incompatible to MATLAB.
  At least with functions like: legend, tics, xlabel, etc. this should work



Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Linux snake 2.6.29-gentoo-r5 #5 Mon Jun 22 00:17:23
CEST 2009 i686 Intel(R) Pentium(R) M processor 1.60GHz GenuineIntel
GNU/Linux
configure opts:   '--prefix=/usr' '--build=i686-pc-linux-gnu'
'--host=i686-pc-linux-gnu' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc'
'--localstatedir=/var/lib' '--localstatedir=/var/state/octave'
'--enable-shared' '--with-blas=-lblas -latlas  ' '--with-lapack=-llapack
-lblas -lcblas -latlas  ' '--without-hdf5' '--without-curl'
'--with-zlib' '--with-fftw' '--with-umfpack' '--with-colamd'
'--with-ccolamd' '--with-cholmod' '--with-cxsparse' '--enable-readline'
'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu'
'CFLAGS=-march=pentium-m -O2 -fno-ident -pipe' 'LDFLAGS=-Wl,-O1'
'CXXFLAGS=-march=pentium-m -O2 -fno-ident -pipe'
Fortran compiler: i686-pc-linux-gnu-gfortran
FFLAGS:           -O -mieee-fp
F2C:              @F2C@
F2CFLAGS:         @F2CFLAGS@
FLIBS:            -L/usr/lib/gcc/i686-pc-linux-gnu/4.3.2
-L/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../.. -lz -lgfortranbegin
-lgfortran -lm
CPPFLAGS:
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       i686-pc-linux-gnu-gcc, version 4.3.2 (Gentoo 4.3.2-r3
p1.6, pie-10.1.5)
CFLAGS:           -march=pentium-m -O2 -fno-ident -pipe
CPICFLAG:         -fPIC
C++ compiler:     i686-pc-linux-gnu-g++, version 4.3.2
CXXFLAGS:         -march=pentium-m -O2 -fno-ident -pipe
CXXPICFLAG:       -fPIC
LD_CXX:           i686-pc-linux-gnu-g++
LDFLAGS:          -Wl,-O1
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-3.0.3
BLAS_LIBS:        -llapack -lblas -lcblas -latlas   -lblas -latlas
FFTW_LIBS:        -lfftw3
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_QHULL=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_IEEE754_DATA_FORMAT=1 -DF77_FUNC(name,NAME)=name ##
  _ -DF77_FUNC_(name,NAME)=name ## _ -DHAVE_BLAS=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_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 = /usr/bin/emacs
  EXEC_PATH =
/usr/libexec/octave/3.0.3/site/exec/i686-pc-linux-gnu:/usr/libexec/octave/api-v32/site/exec/i686-pc-linux-gnu:/usr/libexec/octave/site/exec/i686-pc-linux-gnu:/usr/libexec/octave/3.0.3/exec/i686-pc-linux-gnu:/usr/bin:/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.1:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/opt/sun-jdk-1.4.2.19/bin:/opt/sun-jdk-1.4.2.19/jre/bin:/opt/sun-jdk-1.4.2.19/jre/javaws:/usr/qt/3/bin:/usr/games/bin
  IMAGE_PATH = .:/usr/share/octave/3.0.3/imagelib
  PAGER = /usr/bin/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/andrei/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = /usr/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

From bpabbott at mac.com  Wed Aug 12 20:49:34 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 12 Aug 2009 21:49:34 -0400
Subject: LaTeX labels do not work as expected
In-Reply-To: <4A82FB5A.8020402@physik.hu-berlin.de>
References: <4A82FB5A.8020402@physik.hu-berlin.de>
Message-ID: <CB4A9CB2-9D47-4567-B3D6-93CE5B2DCBDC@mac.com>


On Aug 12, 2009, at 1:26 PM, Andrei Kramer wrote:

> --------
> Bug report for Octave 3.0.3 configured for i686-pc-linux-gnu
>
> Description:
> -----------
>
> it is very hard to include LaTeX code in labels for the terminal  
> epslatex.
> the \expressions are converted/interpreted even when using single  
> quotes.
>
> Repeat-By:
> ---------
>
> plot(1:2,3:4)
>
> OR
>
> pkg load plot
> plot(1:2,3:4)
> tics(x,1:2,['$\theta_1$';'$\theta_2$'])
>
> Fix:
> ---
>
> Allow strings to be passed unaltered. If necessary, introduce a new
> quoting style, which is incompatible to MATLAB.
> At least with functions like: legend, tics, xlabel, etc. this should  
> work


Please upgrade to 3.2. What you've requested works there.

octave:2> x = (0:0.01:4);
octave:3> plot (x, cos (x*pi) )
octave:4> set (gca, "xtick", [0 1 2 3 4], "xticklabel", {"0", "\pi",  
"2\pi", "3\pi", '"4\pi"})

Ben


From jwe at octave.org  Wed Aug 12 21:07:17 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 12 Aug 2009 22:07:17 -0400
Subject: LaTeX labels do not work as expected
In-Reply-To: <CB4A9CB2-9D47-4567-B3D6-93CE5B2DCBDC@mac.com>
References: <4A82FB5A.8020402@physik.hu-berlin.de>
	<CB4A9CB2-9D47-4567-B3D6-93CE5B2DCBDC@mac.com>
Message-ID: <19075.30037.612922.703995@segfault.lan>

On 12-Aug-2009, Ben Abbott wrote:

| Please upgrade to 3.2. What you've requested works there.
| 
| octave:2> x = (0:0.01:4);
| octave:3> plot (x, cos (x*pi) )
| octave:4> set (gca, "xtick", [0 1 2 3 4], "xticklabel", {"0", "\pi",  
| "2\pi", "3\pi", '"4\pi"})

Shouldn't that be '\pi' instead of "\pi"?  Also, does this depend on
the version of gnuplot, or the terminal driver?  And do you need to
set the "interpreter" property for the axes object to something other
than "none" (the default)?  In any case, it doesn't seem to work for
me with the X11 terminal and gnuplot 4.2.5.

jwe

From bpabbott at mac.com  Wed Aug 12 21:12:17 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 12 Aug 2009 22:12:17 -0400
Subject: LaTeX labels do not work as expected
In-Reply-To: <19075.30037.612922.703995@segfault.lan>
References: <4A82FB5A.8020402@physik.hu-berlin.de>
	<CB4A9CB2-9D47-4567-B3D6-93CE5B2DCBDC@mac.com>
	<19075.30037.612922.703995@segfault.lan>
Message-ID: <336A3AE5-9EE2-45D9-AE71-96A3174026BA@mac.com>


On Aug 12, 2009, at 10:07 PM, John W. Eaton wrote:

> On 12-Aug-2009, Ben Abbott wrote:
>
> | Please upgrade to 3.2. What you've requested works there.
> |
> | octave:2> x = (0:0.01:4);
> | octave:3> plot (x, cos (x*pi) )
> | octave:4> set (gca, "xtick", [0 1 2 3 4], "xticklabel", {"0", "\pi",
> | "2\pi", "3\pi", '"4\pi"})
>
> Shouldn't that be '\pi' instead of "\pi"?  Also, does this depend on
> the version of gnuplot, or the terminal driver?  And do you need to
> set the "interpreter" property for the axes object to something other
> than "none" (the default)?  In any case, it doesn't seem to work for
> me with the X11 terminal and gnuplot 4.2.5.
>
> jwe

You are correct. I'm running the developers sources for gnuplot 4.3.x.

Ben

From jwe at octave.org  Thu Aug 13 00:03:50 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 13 Aug 2009 01:03:50 -0400
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <4A830928.5090904@gmx.net>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan> <4A830928.5090904@gmx.net>
Message-ID: <19075.40630.339262.734032@segfault.lan>

On 12-Aug-2009, Thomas Treichl wrote:

| John W. Eaton schrieb:
|
| > Eventually, I'd like to have configure take options for include and
| > link flags for each library.  So for example, users could specify all of
| > 
| >   --with-qhull=-lmyqhull
| >   --with-hdf-ldflags=-L/my/qhull/lib
| >   --with-qhull-cppflags=-I/my/qhull/include
| > 
| > These options would set variables like
| > 
| >   QHULL_LIBS
| >   QHULL_LDFLAGS
| >   QHULL_CPPFLAGS
| > 
| > in Makeconfig.  Then we could add these in specific places where they
| > are needed rather than lumping them all together in every link step.
| > I think this would help when linking with libraries installed in
| > nonstandard locations, especially in cases where the library is only a
| > dependency of a single .oct file.
| > 
| > I'd like to have an autoconf macro that will do this in a reasonably
| > uniform way for all the optional libraries that are used by Octave so
| > we can eliminate some of the custom code we currently have in the
| > configure script, and so that the checks are performed in a more
| > consistent way.
| 
| This (from my point of view) would really be a nice thing. All of my builds eg. 
| are in a none standard directory somewhere inside of /tmp and a change like this 
| would make things much easier I think. Eg. currently ./configure doesn't find 
| any of GLPK anymore but I think this only is a problem of passing the right path 
| information?! I'll look into this.

I checked in the following change, which is a move in the direction I
outlined above.

  http://hg.savannah.gnu.org/hgweb/octave/rev/ee99f9f37505

For now, it just covers the qhull and curl libraries.  If you have
those compiled in non-standard locations, it would help if you could
try using the options

  --with-qhull-includedir=DIR
  --with-qhull-libdir=DIR
  --with-qhull=LIB

(and the corresponding ones for curl).  LIB can be specified as
-lqhull, qhull, /foo/bar/qhull.so, etc., though I would recommend
using the -lqhull form along with the appropriate --with-qhull-libdir
option and not an absolute path.

If this looks good to others, I'll see if I can extend this to cover a
few more libraries.  My priority for now is the list of libraries that
are only linked and appear as direct dependencies of .oct files.

jwe

From highegg at gmail.com  Thu Aug 13 00:24:51 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 13 Aug 2009 07:24:51 +0200
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <19075.40630.339262.734032@segfault.lan>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan> <4A830928.5090904@gmx.net>
	<19075.40630.339262.734032@segfault.lan>
Message-ID: <69d8d540908122224s798f2d48iddab4d39ae012835@mail.gmail.com>

On Thu, Aug 13, 2009 at 7:03 AM, John W. Eaton<jwe at octave.org> wrote:
> On 12-Aug-2009, Thomas Treichl wrote:
>
> | John W. Eaton schrieb:
> |
> | > Eventually, I'd like to have configure take options for include and
> | > link flags for each library. ?So for example, users could specify all of
> | >
> | > ? --with-qhull=-lmyqhull
> | > ? --with-hdf-ldflags=-L/my/qhull/lib
> | > ? --with-qhull-cppflags=-I/my/qhull/include
> | >
> | > These options would set variables like
> | >
> | > ? QHULL_LIBS
> | > ? QHULL_LDFLAGS
> | > ? QHULL_CPPFLAGS
> | >
> | > in Makeconfig. ?Then we could add these in specific places where they
> | > are needed rather than lumping them all together in every link step.
> | > I think this would help when linking with libraries installed in
> | > nonstandard locations, especially in cases where the library is only a
> | > dependency of a single .oct file.
> | >
> | > I'd like to have an autoconf macro that will do this in a reasonably
> | > uniform way for all the optional libraries that are used by Octave so
> | > we can eliminate some of the custom code we currently have in the
> | > configure script, and so that the checks are performed in a more
> | > consistent way.
> |
> | This (from my point of view) would really be a nice thing. All of my builds eg.
> | are in a none standard directory somewhere inside of /tmp and a change like this
> | would make things much easier I think. Eg. currently ./configure doesn't find
> | any of GLPK anymore but I think this only is a problem of passing the right path
> | information?! I'll look into this.
>
> I checked in the following change, which is a move in the direction I
> outlined above.
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/ee99f9f37505
>
> For now, it just covers the qhull and curl libraries. ?If you have
> those compiled in non-standard locations, it would help if you could
> try using the options
>
> ?--with-qhull-includedir=DIR
> ?--with-qhull-libdir=DIR
> ?--with-qhull=LIB
>
> (and the corresponding ones for curl). ?LIB can be specified as
> -lqhull, qhull, /foo/bar/qhull.so, etc., though I would recommend
> using the -lqhull form along with the appropriate --with-qhull-libdir
> option and not an absolute path.
>
> If this looks good to others, I'll see if I can extend this to cover a
> few more libraries. ?My priority for now is the list of libraries that
> are only linked and appear as direct dependencies of .oct files.
>
> jwe

With this change, configure script no longer finds the qhull library
for me. Mine is a static one; it needs also to be linked with -lm
which apparently isn't tried by configure. Is it necessary to specify
--with-qhull=-lqhull -lm manually?

-- 
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  Thu Aug 13 01:08:53 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 13 Aug 2009 08:08:53 +0200
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <19074.57087.451333.870324@segfault.lan>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan>
Message-ID: <69d8d540908122308m47fb5841s9f2da6b57fb8e05d@mail.gmail.com>

On Wed, Aug 12, 2009 at 5:25 PM, John W. Eaton<jwe at octave.org> wrote:
> On 12-Aug-2009, Jaroslav Hajek wrote:
>
> | On Tue, Aug 11, 2009 at 5:37 PM, John W. Eaton<jwe at octave.org> wrote:
> | > On 11-Aug-2009, David Grundberg wrote:
> | >
> | > | is it possible to revert your change? I've got regressions too. And no
> | > | benefits AFAIK.
> | >
> | > I'd rather fix it than simply undo it.
> | >
> | > jwe
> |
> | My build setup with Intel C++ broke, too; libraries in non-standard
> | location specified in LDFLAGS could not be found.
> | Adding LDFLAGS to linking of both liboctave and liboctinterp
> | apparently solves the problem:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/113dba092d8c
>
> OK, does this change solve the problem on OS X systems?
>
> Eventually, I'd like to have configure take options for include and
> link flags for each library. ?So for example, users could specify all of
>
> ?--with-qhull=-lmyqhull
> ?--with-hdf-ldflags=-L/my/qhull/lib
> ?--with-qhull-cppflags=-I/my/qhull/include
>
> These options would set variables like
>
> ?QHULL_LIBS
> ?QHULL_LDFLAGS
> ?QHULL_CPPFLAGS
>
> in Makeconfig. ?Then we could add these in specific places where they
> are needed rather than lumping them all together in every link step.
> I think this would help when linking with libraries installed in
> nonstandard locations, especially in cases where the library is only a
> dependency of a single .oct file.
>
> I'd like to have an autoconf macro that will do this in a reasonably
> uniform way for all the optional libraries that are used by Octave so
> we can eliminate some of the custom code we currently have in the
> configure script, and so that the checks are performed in a more
> consistent way.
>
> | I'm still getting strange errors from the built executables, though,
> | even on my workstation where LDFLAGS is empty (and thus this change
> | was not necessary). I'll try to investigate what is wrong.
>
> What are the errors?
>

I was getting errors from the schur test and also from something as
simple as matrix division, which for certain inputs generated a
Fortran XERBLA error in DLASDA. In agreement with my suspicions, these
problems are gone when I disable ARPACK.
I suppose the problem is that since my ARPACK contains portion of
LAPACK2 (as advised in the ARPACK readme) and these get into the way
of true LAPACK when linking. Or maybe vice versa. I'll try to
recompile ARPACK and link it directly to LAPACK 3, maybe it'll just
work. It's something I wanted to try long ago anyway.

-- 
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  Thu Aug 13 01:10:51 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 13 Aug 2009 02:10:51 -0400
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <69d8d540908122224s798f2d48iddab4d39ae012835@mail.gmail.com>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan> <4A830928.5090904@gmx.net>
	<19075.40630.339262.734032@segfault.lan>
	<69d8d540908122224s798f2d48iddab4d39ae012835@mail.gmail.com>
Message-ID: <19075.44651.147310.299798@segfault.lan>

On 13-Aug-2009, Jaroslav Hajek wrote:

| With this change, configure script no longer finds the qhull library
| for me. Mine is a static one; it needs also to be linked with -lm
| which apparently isn't tried by configure. Is it necessary to specify
| --with-qhull=-lqhull -lm manually?

In configure.in, the following appears just before the tests for qhull:

  case "$canonical_host_type" in
    *-*-nextstep*)
    ;;  
    *-*-linux*)
      AC_CHECK_LIB(m, sin, , , -lc)
    ;;
    *)
      AC_CHECK_LIB(m, sin)
    ;;
  esac

Does this not add -lm to LIBS?  The new OCTAVE_CHECK_LIBRARY macro
should add QHULL_LIBS to LIBS for any linking check.

What is the compile command that fails, and what is the error message?
I think that should appear in config.log.

jwe

From highegg at gmail.com  Thu Aug 13 01:14:47 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 13 Aug 2009 08:14:47 +0200
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <19075.44651.147310.299798@segfault.lan>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan> <4A830928.5090904@gmx.net>
	<19075.40630.339262.734032@segfault.lan>
	<69d8d540908122224s798f2d48iddab4d39ae012835@mail.gmail.com>
	<19075.44651.147310.299798@segfault.lan>
Message-ID: <69d8d540908122314i183e06y4e339c293c1fe1c@mail.gmail.com>

On Thu, Aug 13, 2009 at 8:10 AM, John W. Eaton<jwe at octave.org> wrote:
> On 13-Aug-2009, Jaroslav Hajek wrote:
>
> | With this change, configure script no longer finds the qhull library
> | for me. Mine is a static one; it needs also to be linked with -lm
> | which apparently isn't tried by configure. Is it necessary to specify
> | --with-qhull=-lqhull -lm manually?
>
> In configure.in, the following appears just before the tests for qhull:
>
> ?case "$canonical_host_type" in
> ? ?*-*-nextstep*)
> ? ?;;
> ? ?*-*-linux*)
> ? ? ?AC_CHECK_LIB(m, sin, , , -lc)
> ? ?;;
> ? ?*)
> ? ? ?AC_CHECK_LIB(m, sin)
> ? ?;;
> ?esac
>
> Does this not add -lm to LIBS? ?The new OCTAVE_CHECK_LIBRARY macro
> should add QHULL_LIBS to LIBS for any linking check.
>

Apparently, it doesn't.
It seems the following patchie fixes it:

diff --git a/aclocal.m4 b/aclocal.m4
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -453,7 +453,7 @@
       save_LDFLAGS="$LDFLAGS"
       LDFLAGS="$m4_toupper([$1])_LDFLAGS $LDFLAGS"
       save_LIBS="$LIBS"
-      LIBS="$m4_toupper([$1])_LIBS"
+      LIBS="$m4_toupper([$1])_LIBS $LIBS"
       octave_$1_ok=no
       AC_MSG_CHECKING([for $5 in $m4_toupper([$1])_LIBS])
       AC_LINK_IFELSE([AC_LANG_CALL([], [$5])],

OK to commit?

-- 
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  Thu Aug 13 01:21:03 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 13 Aug 2009 02:21:03 -0400
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <69d8d540908122314i183e06y4e339c293c1fe1c@mail.gmail.com>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan> <4A830928.5090904@gmx.net>
	<19075.40630.339262.734032@segfault.lan>
	<69d8d540908122224s798f2d48iddab4d39ae012835@mail.gmail.com>
	<19075.44651.147310.299798@segfault.lan>
	<69d8d540908122314i183e06y4e339c293c1fe1c@mail.gmail.com>
Message-ID: <19075.45263.481529.709246@segfault.lan>

On 13-Aug-2009, Jaroslav Hajek wrote:

| Apparently, it doesn't.
| It seems the following patchie fixes it:
| 
| diff --git a/aclocal.m4 b/aclocal.m4
| --- a/aclocal.m4
| +++ b/aclocal.m4
| @@ -453,7 +453,7 @@
|        save_LDFLAGS="$LDFLAGS"
|        LDFLAGS="$m4_toupper([$1])_LDFLAGS $LDFLAGS"
|        save_LIBS="$LIBS"
| -      LIBS="$m4_toupper([$1])_LIBS"
| +      LIBS="$m4_toupper([$1])_LIBS $LIBS"
|        octave_$1_ok=no
|        AC_MSG_CHECKING([for $5 in $m4_toupper([$1])_LIBS])
|        AC_LINK_IFELSE([AC_LANG_CALL([], [$5])],
| 
| OK to commit?

Yes, thanks.

jwe

From highegg at gmail.com  Thu Aug 13 01:57:38 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 13 Aug 2009 08:57:38 +0200
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <69d8d540908122308m47fb5841s9f2da6b57fb8e05d@mail.gmail.com>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan>
	<69d8d540908122308m47fb5841s9f2da6b57fb8e05d@mail.gmail.com>
Message-ID: <69d8d540908122357r67d7d6e4qc94290bd19474317@mail.gmail.com>

On Thu, Aug 13, 2009 at 8:08 AM, Jaroslav Hajek<highegg at gmail.com> wrote:
> On Wed, Aug 12, 2009 at 5:25 PM, John W. Eaton<jwe at octave.org> wrote:
>> On 12-Aug-2009, Jaroslav Hajek wrote:
>>
>> | On Tue, Aug 11, 2009 at 5:37 PM, John W. Eaton<jwe at octave.org> wrote:
>> | > On 11-Aug-2009, David Grundberg wrote:
>> | >
>> | > | is it possible to revert your change? I've got regressions too. And no
>> | > | benefits AFAIK.
>> | >
>> | > I'd rather fix it than simply undo it.
>> | >
>> | > jwe
>> |
>> | My build setup with Intel C++ broke, too; libraries in non-standard
>> | location specified in LDFLAGS could not be found.
>> | Adding LDFLAGS to linking of both liboctave and liboctinterp
>> | apparently solves the problem:
>> | http://hg.savannah.gnu.org/hgweb/octave/rev/113dba092d8c
>>
>> OK, does this change solve the problem on OS X systems?
>>
>> Eventually, I'd like to have configure take options for include and
>> link flags for each library. ?So for example, users could specify all of
>>
>> ?--with-qhull=-lmyqhull
>> ?--with-hdf-ldflags=-L/my/qhull/lib
>> ?--with-qhull-cppflags=-I/my/qhull/include
>>
>> These options would set variables like
>>
>> ?QHULL_LIBS
>> ?QHULL_LDFLAGS
>> ?QHULL_CPPFLAGS
>>
>> in Makeconfig. ?Then we could add these in specific places where they
>> are needed rather than lumping them all together in every link step.
>> I think this would help when linking with libraries installed in
>> nonstandard locations, especially in cases where the library is only a
>> dependency of a single .oct file.
>>
>> I'd like to have an autoconf macro that will do this in a reasonably
>> uniform way for all the optional libraries that are used by Octave so
>> we can eliminate some of the custom code we currently have in the
>> configure script, and so that the checks are performed in a more
>> consistent way.
>>
>> | I'm still getting strange errors from the built executables, though,
>> | even on my workstation where LDFLAGS is empty (and thus this change
>> | was not necessary). I'll try to investigate what is wrong.
>>
>> What are the errors?
>>
>
> I was getting errors from the schur test and also from something as
> simple as matrix division, which for certain inputs generated a
> Fortran XERBLA error in DLASDA. In agreement with my suspicions, these
> problems are gone when I disable ARPACK.
> I suppose the problem is that since my ARPACK contains portion of
> LAPACK2 (as advised in the ARPACK readme) and these get into the way
> of true LAPACK when linking. Or maybe vice versa. I'll try to
> recompile ARPACK and link it directly to LAPACK 3, maybe it'll just
> work. It's something I wanted to try long ago anyway.
>

I tried the above, and all problems now seem to have gone. My
Linux/gcc build seems now to work as before. I'll try the Intel C++
build and report later.

I have 2 more thoughts:
1. I see BLAS_LIBS is not specified for linking liboctave. Is this
intentional? I suppose the BLAS&LAPACK are linked through libcruft,
right?
2. In top/Makeconf, I now have (after configure CXXFLAGS=something, no
other options)

LIBS=-lblas -lm

where did -lblas come from? It probably doesn't hurt, but seems leaked
from somewhere.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From Thomas.Treichl at gmx.net  Thu Aug 13 02:01:40 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Thu, 13 Aug 2009 09:01:40 +0200
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <19074.57087.451333.870324@segfault.lan>
References: <4A812086.8090806@gmx.net>	<4A813A8F.5000302@acc.umu.se>	<19073.36937.903371.755463@segfault.lan>	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan>
Message-ID: <4A83BA54.1030802@gmx.net>

John W. Eaton schrieb:
> On 12-Aug-2009, Jaroslav Hajek wrote:
> 
> | On Tue, Aug 11, 2009 at 5:37 PM, John W. Eaton<jwe at octave.org> wrote:
> | > On 11-Aug-2009, David Grundberg wrote:
> | >
> | > | is it possible to revert your change? I've got regressions too. And no
> | > | benefits AFAIK.
> | >
> | > I'd rather fix it than simply undo it.
> | >
> | > jwe
> | 
> | My build setup with Intel C++ broke, too; libraries in non-standard
> | location specified in LDFLAGS could not be found.
> | Adding LDFLAGS to linking of both liboctave and liboctinterp
> | apparently solves the problem:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/113dba092d8c
> 
> OK, does this change solve the problem on OS X systems?

No, it doesn't solve the OS X problems. Here are the flags that I could need to 
compile the two files

   liboctinterp.dylib:

     -L../libcruft -lcruft -lfftw3 -lfftw3f -lreadline

   octave:

     -lhdf5 -lz -lreadline -lfftw3 -lfftw3f

Once I compiled these two files manually I have errors creating the *oct files. 
I've attached error.txt.gz that shows the error that I then have...

   Thomas

From jwe at octave.org  Thu Aug 13 10:32:18 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 13 Aug 2009 11:32:18 -0400
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <69d8d540908122357r67d7d6e4qc94290bd19474317@mail.gmail.com>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan>
	<69d8d540908122308m47fb5841s9f2da6b57fb8e05d@mail.gmail.com>
	<69d8d540908122357r67d7d6e4qc94290bd19474317@mail.gmail.com>
Message-ID: <19076.12802.935086.127389@segfault.lan>

On 13-Aug-2009, Jaroslav Hajek wrote:

| I have 2 more thoughts:
| 1. I see BLAS_LIBS is not specified for linking liboctave. Is this
| intentional? I suppose the BLAS&LAPACK are linked through libcruft,
| right?

Yes.  There are direct calls to BLAS and LAPACK routines in liboctave,
but since liboctave also requires libcruft, and libcruft requires BLAS
and LAPACK, I didn't see the point of also linking liboctave with
them.

| 2. In top/Makeconf, I now have (after configure CXXFLAGS=something, no
| other options)
| 
| LIBS=-lblas -lm
| 
| where did -lblas come from? It probably doesn't hurt, but seems leaked
| from somewhere.

I noticed this too, but haven't had time to find out why it is
happening.

jwe

From lindnerben at gmx.net  Thu Aug 13 15:13:35 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Thu, 13 Aug 2009 22:13:35 +0200
Subject: mingw32: cannot link liboctinterp and .oct files
Message-ID: <4A8473EF.805@gmx.net>

Hello list,

This has been mentioned already for macos and also for mingw32/liboctave.

The changeset 9490:3aeb7d881578 completely breaks a mingw32 build.
Both linking liboctinterp.dll fails and also any .oct file from 
DLD_FUNCTIONS/ fails linking.

I get at a rough estimate the following undefined reference errors

undefined reference to `octave_signal_caught'
undefined reference to `octave_handle_signal'
undefined reference to `octave_throw_interrupt_exception'
undefined reference to `current_liboctave_error_handler'
undefined reference to `octave_interrupt_immediately'
undefined reference to `octave_exception_state'
undefined reference to `octave_jump_to_enclosing_context'
undefined reference to `octave_save_signal_mask'
undefined reference to `octave_signal_hook'
undefined reference to `octave_interrupt_hook'
undefined reference to `octave_bad_alloc_hook'
undefined reference to `set_liboctave_error_handler'
undefined reference to `set_liboctave_warning_handler'
undefined reference to `set_liboctave_warning_with_id_handler'
undefined reference to `w32_raise'
undefined reference to `w32_in_main_thread'
undefined reference to `w32_sigint_init'
undefined reference to `w32_raise_final'
undefined reference to `current_context'
undefined reference to `octave_save_current_context'
undefined reference to `octave_restore_current_context'

These all stem from -lcruft missing from the link dependencies.

Then I get

undefined reference to `GetDeviceCaps at 8'
undefined reference to `mkstemps'

These are mingw32-specific errors, but at configure stage it is ensured 
that for mingw platform the required libraries get added to $LIBS, which 
- again - is missing from link dependencies.

Then there are the errors

undefined reference to `_gfortran_st_write'
undefined reference to `_gfortran_transfer_character'
undefined reference to `_gfortran_transfer_integer'
undefined reference to `_gfortran_st_write_done'
undefined reference to `xstopx_'

which (I presume) arise from including xerbla.o as object file which 
depends on gcc's fortran libraries which are stored in $FLIBS by the 
configure script, and again, $FLIBS is missing from link dependencies.


Regarding the .oct linking failures, well I'm not that an expert on 
octave source internals to be able to tell which libraries they depend on

In makefile.in I read

OCT_LINK_DEPS = $(RLD_FLAG) -L. $(LIBOCTINTERP)

I would suspect at least to also have $LIBCRUFT and $LIBOCTAVE there. No?

Also there are additional library depedencies for individual DLD 
functions. Some are mentioned in the makefile, but I find at least 
amd.oct misses its dependency libraries, too.

This changeset should be repaired, otherwise maintainance gets even 
harder...

benjamin

From lindnerben at gmx.net  Thu Aug 13 15:50:53 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Thu, 13 Aug 2009 22:50:53 +0200
Subject: mingw32: cannot link liboctinterp and .oct files
In-Reply-To: <4A8473EF.805@gmx.net>
References: <4A8473EF.805@gmx.net>
Message-ID: <4A847CAD.5000709@gmx.net>

Benjamin Lindner wrote:
> Hello list,
> 
> This has been mentioned already for macos and also for mingw32/liboctave.
> 
> The changeset 9490:3aeb7d881578 completely breaks a mingw32 build.
> Both linking liboctinterp.dll fails and also any .oct file from 
> DLD_FUNCTIONS/ fails linking.
> 
> I get at a rough estimate the following undefined reference errors
> 
> undefined reference to `octave_signal_caught'
> undefined reference to `octave_handle_signal'
> undefined reference to `octave_throw_interrupt_exception'
> undefined reference to `current_liboctave_error_handler'
> undefined reference to `octave_interrupt_immediately'
> undefined reference to `octave_exception_state'
> undefined reference to `octave_jump_to_enclosing_context'
> undefined reference to `octave_save_signal_mask'
> undefined reference to `octave_signal_hook'
> undefined reference to `octave_interrupt_hook'
> undefined reference to `octave_bad_alloc_hook'
> undefined reference to `set_liboctave_error_handler'
> undefined reference to `set_liboctave_warning_handler'
> undefined reference to `set_liboctave_warning_with_id_handler'
> undefined reference to `w32_raise'
> undefined reference to `w32_in_main_thread'
> undefined reference to `w32_sigint_init'
> undefined reference to `w32_raise_final'
> undefined reference to `current_context'
> undefined reference to `octave_save_current_context'
> undefined reference to `octave_restore_current_context'
> 
> These all stem from -lcruft missing from the link dependencies.
> 
> Then I get
> 
> undefined reference to `GetDeviceCaps at 8'
> undefined reference to `mkstemps'
> 
> These are mingw32-specific errors, but at configure stage it is ensured 
> that for mingw platform the required libraries get added to $LIBS, which 
> - again - is missing from link dependencies.
> 
> Then there are the errors
> 
> undefined reference to `_gfortran_st_write'
> undefined reference to `_gfortran_transfer_character'
> undefined reference to `_gfortran_transfer_integer'
> undefined reference to `_gfortran_st_write_done'
> undefined reference to `xstopx_'
> 
> which (I presume) arise from including xerbla.o as object file which 
> depends on gcc's fortran libraries which are stored in $FLIBS by the 
> configure script, and again, $FLIBS is missing from link dependencies.
> 
> 
> Regarding the .oct linking failures, well I'm not that an expert on 
> octave source internals to be able to tell which libraries they depend on
> 
> In makefile.in I read
> 
> OCT_LINK_DEPS = $(RLD_FLAG) -L. $(LIBOCTINTERP)
> 
> I would suspect at least to also have $LIBCRUFT and $LIBOCTAVE there. No?
> 
> Also there are additional library depedencies for individual DLD 
> functions. Some are mentioned in the makefile, but I find at least 
> amd.oct misses its dependency libraries, too.
> 

The attached changeset fixes the issues for the mingw32 platform.
it

*) adds $(LIBCRUFT), $(LIBS) and $(FLIBS) to OCTINTERP_LINK_DEPS,

*) adds $(LIBOCTAVE) and $(LIBCRUFT) to OCT_LINK_DEPS and

*) adds respective link dependencies for eigs.oct, amd.oct, ccolamd.oct, 
colamd.oct, chol.oct, dmprem.oct, fftw.oct, qz.oct and symbfact.oct

benjamin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: liboctinterp-linkdeps.changeset
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090813/a547d576/attachment.ksh 

From jwe at octave.org  Thu Aug 13 17:17:24 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 13 Aug 2009 18:17:24 -0400
Subject: mingw32: cannot link liboctinterp and .oct files
In-Reply-To: <4A847CAD.5000709@gmx.net>
References: <4A8473EF.805@gmx.net>
	<4A847CAD.5000709@gmx.net>
Message-ID: <19076.37108.480955.851402@segfault.lan>

On 13-Aug-2009, Benjamin Lindner wrote:

| Benjamin Lindner wrote:
| > Hello list,
| > 
| > This has been mentioned already for macos and also for mingw32/liboctave.
| > 
| > The changeset 9490:3aeb7d881578 completely breaks a mingw32 build.
| > Both linking liboctinterp.dll fails and also any .oct file from 
| > DLD_FUNCTIONS/ fails linking.
| > 
| > I get at a rough estimate the following undefined reference errors
| > 
| > undefined reference to `octave_signal_caught'
| > undefined reference to `octave_handle_signal'
| > undefined reference to `octave_throw_interrupt_exception'
| > undefined reference to `current_liboctave_error_handler'
| > undefined reference to `octave_interrupt_immediately'
| > undefined reference to `octave_exception_state'
| > undefined reference to `octave_jump_to_enclosing_context'
| > undefined reference to `octave_save_signal_mask'
| > undefined reference to `octave_signal_hook'
| > undefined reference to `octave_interrupt_hook'
| > undefined reference to `octave_bad_alloc_hook'
| > undefined reference to `set_liboctave_error_handler'
| > undefined reference to `set_liboctave_warning_handler'
| > undefined reference to `set_liboctave_warning_with_id_handler'
| > undefined reference to `w32_raise'
| > undefined reference to `w32_in_main_thread'
| > undefined reference to `w32_sigint_init'
| > undefined reference to `w32_raise_final'
| > undefined reference to `current_context'
| > undefined reference to `octave_save_current_context'
| > undefined reference to `octave_restore_current_context'
| > 
| > These all stem from -lcruft missing from the link dependencies.
| > 
| > Then I get
| > 
| > undefined reference to `GetDeviceCaps at 8'
| > undefined reference to `mkstemps'
| > 
| > These are mingw32-specific errors, but at configure stage it is ensured 
| > that for mingw platform the required libraries get added to $LIBS, which 
| > - again - is missing from link dependencies.
| > 
| > Then there are the errors
| > 
| > undefined reference to `_gfortran_st_write'
| > undefined reference to `_gfortran_transfer_character'
| > undefined reference to `_gfortran_transfer_integer'
| > undefined reference to `_gfortran_st_write_done'
| > undefined reference to `xstopx_'
| > 
| > which (I presume) arise from including xerbla.o as object file which 
| > depends on gcc's fortran libraries which are stored in $FLIBS by the 
| > configure script, and again, $FLIBS is missing from link dependencies.
| > 
| > 
| > Regarding the .oct linking failures, well I'm not that an expert on 
| > octave source internals to be able to tell which libraries they depend on
| > 
| > In makefile.in I read
| > 
| > OCT_LINK_DEPS = $(RLD_FLAG) -L. $(LIBOCTINTERP)
| > 
| > I would suspect at least to also have $LIBCRUFT and $LIBOCTAVE there. No?

It is not needed on some platforms if the dependencies are already
linked to libcruft or liboctave (which is linked with libcruft).  It's
unfortunate that things can't work this way on all systems, but OK, it
will be fixed.

| The attached changeset fixes the issues for the mingw32 platform.
| it
| 
| *) adds $(LIBCRUFT), $(LIBS) and $(FLIBS) to OCTINTERP_LINK_DEPS,
| 
| *) adds $(LIBOCTAVE) and $(LIBCRUFT) to OCT_LINK_DEPS and
| 
| *) adds respective link dependencies for eigs.oct, amd.oct, ccolamd.oct, 
| colamd.oct, chol.oct, dmprem.oct, fftw.oct, qz.oct and symbfact.oct

As I've already mentioned, I'm working on cleaning up these things so
that we can have better control over the flags needed for each library
in case they are installed in non-standard locations.  I'll be
checking in a patch soon that does some of what your patch does, then
I plan to do some more work on this in the next few days.

Sorry for the breakage.  It's not permanent, but I will likely need
some help understanding precisely what needs to be linked on non-GNU
systems.  What I don't want to do is go back to the way things were
before, where every .oct file was linked with every library, since I
don't think that should be necessary, even on Windows or OS X systems.

jwe

From lindnerben at gmx.net  Fri Aug 14 05:53:54 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Fri, 14 Aug 2009 12:53:54 +0200
Subject: mingw32: cannot link liboctinterp and .oct files
In-Reply-To: <19076.37108.480955.851402@segfault.lan>
References: <4A8473EF.805@gmx.net>	<4A847CAD.5000709@gmx.net>
	<19076.37108.480955.851402@segfault.lan>
Message-ID: <4A854242.7060204@gmx.net>

John W. Eaton wrote:
> 
> It is not needed on some platforms if the dependencies are already
> linked to libcruft or liboctave (which is linked with libcruft).  It's
> unfortunate that things can't work this way on all systems, but OK, it
> will be fixed.

Ah, I didn't know that. One tends to be a bit short sighted, working 
only on windows platform.

> | The attached changeset fixes the issues for the mingw32 platform.
> | it
> | 
> | *) adds $(LIBCRUFT), $(LIBS) and $(FLIBS) to OCTINTERP_LINK_DEPS,
> | 
> | *) adds $(LIBOCTAVE) and $(LIBCRUFT) to OCT_LINK_DEPS and
> | 
> | *) adds respective link dependencies for eigs.oct, amd.oct, ccolamd.oct, 
> | colamd.oct, chol.oct, dmprem.oct, fftw.oct, qz.oct and symbfact.oct
> 
> As I've already mentioned, I'm working on cleaning up these things so
> that we can have better control over the flags needed for each library
> in case they are installed in non-standard locations.  I'll be
> checking in a patch soon that does some of what your patch does, then
> I plan to do some more work on this in the next few days.
> 
> Sorry for the breakage.  It's not permanent, but I will likely need
> some help understanding precisely what needs to be linked on non-GNU
> systems.  What I don't want to do is go back to the way things were
> before, where every .oct file was linked with every library, since I
> don't think that should be necessary, even on Windows or OS X systems.
> 

Thanks for looking into it. If you need help or testing, just call out.

benjamin


From sergstesh at yahoo.com  Fri Aug 14 06:41:17 2009
From: sergstesh at yahoo.com (Sergei Steshenko)
Date: Fri, 14 Aug 2009 04:41:17 -0700 (PDT)
Subject: mingw32: cannot link liboctinterp and .oct files
In-Reply-To: <19076.37108.480955.851402@segfault.lan>
Message-ID: <901368.47680.qm@web35201.mail.mud.yahoo.com>



--- On Thu, 8/13/09, John W. Eaton <jwe at octave.org> wrote:

> From: John W. Eaton <jwe at octave.org>
> Subject: Re: mingw32: cannot link liboctinterp and .oct files
> To: "Benjamin Lindner" <lindnerben at gmx.net>
> Cc: "octave-bug mailing list" <bug-octave at octave.org>

...
> Sorry for the breakage.? It's not permanent, but I
> will likely need
> some help understanding precisely what needs to be linked
> on non-GNU
> systems.? What I don't want to do is go back to the
> way things were
> before, where every .oct file was linked with every
> library, since I
> don't think that should be necessary, even on Windows or OS
> X systems.
> 
> jwe
> _______________________________________________


I have tried GNU libtool and cross (Linux -> Windows) environment - worked quite fine for me - the point being the same commands used for both Linux
and Windows.

Interestingly enough, with GNU libtool one can even have .so file under
Windows (instead of .dll).

I tried all this on a small code example, not 'octave', but, of course, the
example dealt with dynamic library loading as well as with some static linking.

Regards,
  Sergei.


      


From stefan at pofahl.de  Fri Aug 14 08:19:50 2009
From: stefan at pofahl.de (stefan.pofahl)
Date: Fri, 14 Aug 2009 15:19:50 +0200
Subject: Get Default Values of an object
Message-ID: <4A856476.20803@pofahl.de>

Bug report for Octave 3.2.0 configured for i686-pc-mingw32

Description:
-----------

It should be possible to see the valid potential values of an object
with the set() command, e.g.
 > set(gca())
should (at least) show you the default property values for an axes
object (see Octave documentation Chap. 15)

Repeat-By:
---------
Give the commands:
 > plot(0);
 > set(gca())
Error message:

error: axes::defaults: not implemented

Fix:
---
Sorry, I have no fix :-(

Workaround:
Read Matlab documentation and hope that the potential values
of a property are the same under Octave



Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Windows
configure opts:
Fortran compiler: mingw32-gfortran-4.3.0-dw2
FFLAGS:           -O -mieee-fp
FLIBS:            -lgfortran
CPPFLAGS:         -march=i686 -mtune=generic -O2
INCFLAGS:         -I. -I/octaveforge_mingw32/octave/octave-3.2.0 -I. 
-I./liboctave -I./src -I./libcruft/misc 
-I/octaveforge_mingw32/octave/octave-3.2.0 
-I/octaveforge_mingw32/octave/octave-3.2.0/liboctave 
-I/octaveforge_mingw32/octave/octave-3.2.0/src 
-I/octaveforge_mingw32/octave/octave-3.2.0/libcruft/misc
C compiler:       mingw32-gcc-4.3.0-dw2, version4.3.0-dw2 (GCC TDM-2 
for MinGW)
CFLAGS:           -Wall
CPICFLAG:
C++ compiler:     mingw32-g++-4.3.0-dw2, version4.3.0-dw2
CXXFLAGS:         -D_DLL -Wall
CXXPICFLAG:
LD_CXX:           mingw32-g++-4.3.0-dw2
LDFLAGS:          -shared-libgcc -Wl,--exclude-libs=-lstdc++_s 
-Wl,--allow-multiple-definition
LIBFLAGS:         -L.
RLD_FLAG:
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -liberty -lblas -lhdf5 -lz -lm 
  -lgdi32 -lws2_32 -luser32 -lkernel32
LEXLIB:
LIBGLOB:          -lglob
SED:              /usr/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_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_GLPK_H=1 -DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 
-DHAVE_MAGICK=1 -DHAVE_WINDOWS_H=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 
-Duid_t=int -Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_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=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_ASSERT_H=1 
-DHAVE_CURSES_H=1 -DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_PTHREAD_H=1 
-DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1 
-DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 
-DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 
-DHAVE_EXPM1F=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 
-DHAVE_GETTIMEOFDAY=1 -DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 
-DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 
-DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 
-DHAVE_ROUNDL=1 -DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 
-DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 
-DHAVE_STRICMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 
-DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 
-DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 
-DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1 
-DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1 
-DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1 
-DHAVE_MKSTEMPS=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1 
-DOCTAVE_HAVE_BROKEN_STRPTIME=1 -D_WIN32_WINNT=0x0403 
-DHAVE_LOADLIBRARY_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_COPYSIGN=1 -DHAVE_SIGNBIT=1 
-DHAVE__FINITE=1 -DHAVE__ISNAN=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_RDEV=1 -DHAVE_DECL_TZNAME=1 -DHAVE_TZNAME=1 
-DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void 
-DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1 
-DRETSIGTYPE_IS_VOID=1


User-preferences (please do not edit this section):

   EDITOR = C:\Programme\pspad\PSPad.exe
   EXEC_PATH = 
C:\Programme\Octave\3.2.0_gcc-4.3.0\MINGW32\bin;C:\Programme\Octave\3.2.0_gcc-4.3.0\MSYS\bin;C:\Programme\Octave\3.2.0_gcc-4.3.0\libexec\octave\3.2.0\site\exec\i686-pc-mingw32;C:\Programme\Octave\3.2.0_gcc-4.3.0\libexec\octave\api-v37\site\exec\i686-pc-mingw32;C:\Programme\Octave\3.2.0_gcc-4.3.0\libexec\octave\site\exec\i686-pc-mingw32;C:\Programme\Octave\3.2.0_gcc-4.3.0\libexec\octave\3.2.0\exec\i686-pc-mingw32;C:\Programme\Octave\3.2.0_gcc-4.3.0\bin;C:\Programme\MiKTeX 
2.7\miktex\bin;C:\Programme\Microsoft Visual 
Studio\Common\Tools;C:\Programme\Microsoft Visual 
Studio\Common\Msdev98\BIN;C:\Programme\Microsoft Visual 
Studio\DF98\BIN;C:\Programme\Microsoft Visual 
Studio\VC98\BIN;C:\PROGRA~1\GEMEIN~1\ASPENT~1;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\Gemeinsame 
Dateien\AspenTech Shared\;C:\Programme\Rainbow Technologies\SentinelLM 
7.2.0.1 
Server\English\;C:\Programme\gnuplot\bin\;C:\VXIpnp\WinNT\Bin;C:\Programme\XEmacs\XEmacs-21.4.21\i586-pc-win32;C:\Programme\Ghostgum\gs\gs8.63\bin
   IMAGE_PATH = 
.;C:\Programme\Octave\3.2.0_gcc-4.3.0\share\octave\3.2.0\imagelib
   PAGER = C:\Programme\Octave\3.2.0_gcc-4.3.0\bin\less.exe
   PS1 = \s:\#:\w
> 
   PS2 = >
   PS4 = +
   beep_on_error = 0
   completion_append_char =
   crash_dumps_octave_core = 1
   echo_executing_commands = 0
   fixed_point_format = 0
   gnuplot_binary = C:\Programme\Octave\3.2.0_gcc-4.3.0\bin\gnuplot.exe
# gnuplot_command_end = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
   history_file = C:\Dokumente und Einstellungen\spofahl\.octave_hist
   history_size = 1024
   ignore_function_time_stamp = system
   info_file = C:\Programme\Octave\3.2.0_gcc-4.3.0\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 = <no value or error in displaying it>
   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 david0815 at gmx.de  Thu Aug 13 02:31:58 2009
From: david0815 at gmx.de (bat_boy)
Date: Thu, 13 Aug 2009 00:31:58 -0700 (PDT)
Subject: Set title to left corner doesnt work
In-Reply-To: <8B33EC74-C909-4391-AD31-453818ECAC56@mac.com>
References: <24934769.post@talk.nabble.com>
	<8B33EC74-C909-4391-AD31-453818ECAC56@mac.com>
Message-ID: <24950179.post@talk.nabble.com>


Hi Ben!

THANKS SO MUCH!!!
That's exactly what I was looking for :) :) :)

Cheers, David





Ben Abbott wrote:
> 
> On Aug 12, 2009, at 7:46 AM, bat_boy wrote:
> 
>> Hi folks!
>>
>> I'd like to set the horizontal postition of the title in my plot to  
>> the left
>> corner.
>> When I plot and do this:
>>
>> title("This is my awesome title");
>> yl = get (gca (), 'title');
>> get(get(gca()).title).horizontalalignment
>> set (yl, 'horizontalalignment', 'center');
>> get(get(gca()).title).horizontalalignment
>> set (yl, 'horizontalalignment', 'left');
>> get(get(gca()).title).horizontalalignment
>>
>> the output is
>>
>> ans = left
>> ans = center
>> ans = left
>>
>> So it seems that the value is set to "left" as default. Even setting  
>> it to
>> "center" and to "left" afterwards doesnt have any effetct, the title  
>> remains
>> in the center. Do I miss something here?
>>
>> Thanks!
>> David
> 
> Hi David,
> 
> The functionality you're looking for is not yet supported by Octave.
> 
> As a work around you can try ...
> 
> text (0, 1.05, "This is my left aligned title", "horizontalalignment",  
> "left", "units", "normalized")
> 
> Ben
> 
> 
> 
> _______________________________________________
> 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/Set-title-to-left-corner-doesnt-work-tp24934769p24950179.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From jwe at octave.org  Fri Aug 14 08:29:29 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 14 Aug 2009 09:29:29 -0400
Subject: Get Default Values of an object
In-Reply-To: <4A856476.20803@pofahl.de>
References: <4A856476.20803@pofahl.de>
Message-ID: <19077.26297.256901.162656@segfault.lan>

On 14-Aug-2009, stefan.pofahl wrote:

| Bug report for Octave 3.2.0 configured for i686-pc-mingw32
| 
| Description:
| -----------
| 
| It should be possible to see the valid potential values of an object
| with the set() command, e.g.
|  > set(gca())
| should (at least) show you the default property values for an axes
| object (see Octave documentation Chap. 15)
| 
| Repeat-By:
| ---------
| Give the commands:
|  > plot(0);
|  > set(gca())
| Error message:
| 
| error: axes::defaults: not implemented
| 
| Fix:
| ---
| Sorry, I have no fix :-(

This feature has already been requested several times.  It is not a
high priority for me, but if someone submitted a patch, I would be
happy to consider it.

| Workaround:
| Read Matlab documentation and hope that the potential values
| of a property are the same under Octave

It would also be useful if someone contributed changes that improved
the Octave documentation (though of course it is important that those
changes not be done by cut and paste or other method of copying the
Matlab docs).

jwe

From lindnerben at gmx.net  Fri Aug 14 08:37:40 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Fri, 14 Aug 2009 15:37:40 +0200
Subject: mingw32: cannot link liboctinterp and .oct files
In-Reply-To: <901368.47680.qm@web35201.mail.mud.yahoo.com>
References: <901368.47680.qm@web35201.mail.mud.yahoo.com>
Message-ID: <4A8568A4.2080706@gmx.net>


> 
> I have tried GNU libtool and cross (Linux -> Windows) environment - worked quite fine for me - the point being the same commands used for both Linux
> and Windows.
> 
> Interestingly enough, with GNU libtool one can even have .so file under
> Windows (instead of .dll).
> 
> I tried all this on a small code example, not 'octave', but, of course, the
> example dealt with dynamic library loading as well as with some static linking.
> 

I would rather dislike seeing octave switching to libtool.
It simply does not really work under windows. It doesn't.
I had quite a headache building all the supporting libraries for octave 
where many use libtool and to my experience it creates more effort and 
work than perhaps being helpful.

If it's strightforwad quick-and-dirty it works, but then I don't need it 
because I can do it the GNU-way anyway using simply gcc/binutils. 
libtool then makes the process much slower, less transparent and less 
maintainable.

If it is not starightfroward, because it requires some platform specific 
hacks, then libtool will by all chance not know about it and what's its 
use then.

In many builds I looked at for building octave and dependencies, libtool 
was hacked for a windows platform.

So, I don't really fancy libtool, judging from my so-far experience.

benjamin


From sergstesh at yahoo.com  Fri Aug 14 09:19:43 2009
From: sergstesh at yahoo.com (Sergei Steshenko)
Date: Fri, 14 Aug 2009 07:19:43 -0700 (PDT)
Subject: mingw32: cannot link liboctinterp and .oct files
In-Reply-To: <4A8568A4.2080706@gmx.net>
Message-ID: <327582.802.qm@web35207.mail.mud.yahoo.com>



--- On Fri, 8/14/09, Benjamin Lindner <lindnerben at gmx.net> wrote:

> From: Benjamin Lindner <lindnerben at gmx.net>
> Subject: Re: mingw32: cannot link liboctinterp and .oct files
> To: "Sergei Steshenko" <sergstesh at yahoo.com>
> Cc: "John W. Eaton" <jwe at octave.org>, "octave-bug mailing list" <bug-octave at octave.org>
> Date: Friday, August 14, 2009, 6:37 AM
> 
> > 
> > I have tried GNU libtool and cross (Linux ->
> Windows) environment - worked quite fine for me - the point
> being the same commands used for both Linux
> > and Windows.
> > 
> > Interestingly enough, with GNU libtool one can even
> have .so file under
> > Windows (instead of .dll).
> > 
> > I tried all this on a small code example, not
> 'octave', but, of course, the
> > example dealt with dynamic library loading as well as
> with some static linking.
> > 
> 
> I would rather dislike seeing octave switching to libtool.
> It simply does not really work under windows. It doesn't.
> I had quite a headache building all the supporting
> libraries for octave where many use libtool and to my
> experience it creates more effort and work than perhaps
> being helpful.
> 
> If it's strightforwad quick-and-dirty it works, but then I
> don't need it because I can do it the GNU-way anyway using
> simply gcc/binutils. libtool then makes the process much
> slower, less transparent and less maintainable.
> 
> If it is not starightfroward, because it requires some
> platform specific hacks, then libtool will by all chance not
> know about it and what's its use then.
> 
> In many builds I looked at for building octave and
> dependencies, libtool was hacked for a windows platform.
> 
> So, I don't really fancy libtool, judging from my so-far
> experience.
> 
> benjamin
> 
> 

Please note that I tried 'libtool' in cross environment (Linux -> Windows),
maybe under cross environment it works better.

Regards,
  Sergei.


      

From joebock at uwm.edu  Fri Aug 14 14:13:49 2009
From: joebock at uwm.edu (Joseph Bockhorst)
Date: Fri, 14 Aug 2009 14:13:49 -0500
Subject: crash in fft following fftw( 'planner', 'exhaustive' )
Message-ID: <95A722B7-243E-4FA6-8DC9-61EEB0945E2F@uwm.edu>

Bug report for Octave 3.0.0 configured for i486-pc-linux-gnu

Description:
-----------

octave crashes on calls to fft(x) following
fftw( 'planner', 'exhaustive' )

when x is a large enough multidimensional array.

octave:1> fftw( 'planner', 'exhaustive' );
octave:2> x = rand(16);
octave:3> fft( x );
*** glibc detected *** octave: corrupted double-linked list:  
0x09772b40 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb5e770cd]
/lib/tls/i686/cmov/libc.so.6[0xb5e78edd]
/lib/tls/i686/cmov/libc.so.6[0xb5e79f7c]
/lib/tls/i686/cmov/libc.so.6(__libc_memalign+0xcd)[0xb5e7ae6d]
/usr/lib/libfftw3.so.3(fftw_kernel_malloc+0x25)[0xb62c5f75]
/usr/lib/libfftw3.so.3(fftw_malloc_plain+0x28)[0xb62c53b8]
/usr/lib/libfftw3.so.3[0xb62c7079]
/usr/lib/libfftw3.so.3[0xb62c73ac]
/usr/lib/libfftw3.so.3[0xb62c7ffb]
...

Repeat-By:
---------

fftw( 'planner', 'exhaustive' );
x = rand(16);
y = fft( x );

Fix:
---

Perhaps call fft multiple times passing in a 1D array each time.

fftw( 'planner', 'exhaustive' );
x = rand(16);
y = zeros(16); % the result
for i=1:16
  y(:,i) = fft( x(:,i) );
end

Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Linux callisto 2.6.24-16-generic #1 SMP Thu Apr 10  
13:23:42 UTC 2008 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
F2C:              @F2C@
F2CFLAGS:         @F2CFLAGS@
FLIBS:            -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/ 
i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib - 
L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. -lhdf5 -lz -lgfortranbegin  
-lgfortran -lm
CPPFLAGS:
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.2.3 (Ubuntu 4.2.3-2ubuntu6)
CFLAGS:           -O2
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.2.3
CXXFLAGS:         -O2
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-3.0.0
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.0/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.0/exec/i486-pc-linux-gnu:/ 
usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/ 
usr/games:/opt/real/RealPlayer
  IMAGE_PATH = .:/usr/share/octave/3.0.0/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 = /root/.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 root at callisto.cs.uwm.edu  Fri Aug 14 13:55:55 2009
From: root at callisto.cs.uwm.edu (root)
Date: Fri, 14 Aug 2009 13:55:55 -0500 (CDT)
Subject: crash in fft() following fftw( 'planner', 'exhaustive') 
Message-ID: <20090814185555.892F513F67B9@callisto.cs.uwm.edu>

To: bug at octave.org
Cc: 
Subject: crash in fft() following fftw( 'planner', 'exhaustive') 

Bug report for Octave 3.0.0 configured for i486-pc-linux-gnu

Description:
-----------

octve crashes when fft() is used with a multi-dimensional array 
following a call to fftw( 'planner', 'exhaustive' );

Repeat-By:
---------

fftw( 'planner', 'exhaustive' );
fft( ones(10) );

if the argument to fft is a 1D array, there's no crash.

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 callisto 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 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
F2C:              @F2C@
F2CFLAGS:         @F2CFLAGS@
FLIBS:            -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.2.3 (Ubuntu 4.2.3-2ubuntu6)
CFLAGS:           -O2
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.2.3
CXXFLAGS:         -O2
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:          
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-3.0.0
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.0/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.0/exec/i486-pc-linux-gnu:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/real/RealPlayer
  IMAGE_PATH = .:/usr/share/octave/3.0.0/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 = /root/.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 dasergatskov at gmail.com  Sat Aug 15 23:57:49 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Sat, 15 Aug 2009 23:57:49 -0500
Subject: [OctDev] incorrect complex matrix multiplication results in 
	Octave 3.2.2
In-Reply-To: <c98441230908152033tbbb2d20o3a28b4e6a9610083@mail.gmail.com>
References: <c98441230908152033tbbb2d20o3a28b4e6a9610083@mail.gmail.com>
Message-ID: <892b16670908152157y748473fbte69d34616f53a826@mail.gmail.com>

On Sat, Aug 15, 2009 at 10:33 PM, Shuhua Zhang<shuhua.zhang at gmail.com> wrote:
> Hi,
>
> ???? I built octave 3.2.2 on my x86_64 desktop and x86 notebook a few weeks
> ago.
> ???? They passed all the tests.
>
> ???? But I've just noticed some weird complex matrix multiplication results
> on both
> ???? the machines:
> ????????? octave:48> [1 0]*[i 0]'
> ????????? ans =? 0 - 1i?????????????????????????????? %% correct
> ????????? octave:49> [1 i]*[i 0]'
> ????????? ans =? 0 + 1i???????????????????????????? %% incorrect,? 0+1i=[i
> 0]*[1 i]'
>
> ? ? The problem is that for nx1 row vectors a and b both with non-zero
> imaginary parts,
> ??? a*b' turns out to be b*a', which is the conjugate of the correct result.
> If either a or b
> ??? are real, the result will be correct.
>
> ??? I also checked out Octave 3.0.3, it didn't have this problem.
>
> ??? So, is it a run time configuration problem, a build configuration
> problem, or a bug?
>

This looks like a bug, but you reported it to the wrong list.
I Cc'ed it accordingly.


octave:14> a=[1,i]
a =

   1 + 0i   0 + 1i

octave:15> b=[i,0]
b =

   0 + 1i   0 + 0i

octave:16> c=b'
c =

   0 - 1i
   0 - 0i

octave:17> a*b'
ans =  0 + 1i
octave:18> a*c
ans =  0 - 1i



>
> Regards,
>
> ? Shuhua Zhang, Oct. 16, 2009
>

Sincerely,

Dmitri.
--


From highegg at gmail.com  Sun Aug 16 00:08:00 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sun, 16 Aug 2009 07:08:00 +0200
Subject: [OctDev] incorrect complex matrix multiplication results in 
	Octave 3.2.2
In-Reply-To: <c98441230908152033tbbb2d20o3a28b4e6a9610083@mail.gmail.com>
References: <c98441230908152033tbbb2d20o3a28b4e6a9610083@mail.gmail.com>
Message-ID: <69d8d540908152208m1f6dacb1i754d51aa29873b6f@mail.gmail.com>

On Sun, Aug 16, 2009 at 5:33 AM, Shuhua Zhang<shuhua.zhang at gmail.com> wrote:
> Hi,
>
> ???? I built octave 3.2.2 on my x86_64 desktop and x86 notebook a few weeks
> ago.
> ???? They passed all the tests.
>
> ???? But I've just noticed some weird complex matrix multiplication results
> on both
> ???? the machines:
> ????????? octave:48> [1 0]*[i 0]'
> ????????? ans =? 0 - 1i?????????????????????????????? %% correct
> ????????? octave:49> [1 i]*[i 0]'
> ????????? ans =? 0 + 1i???????????????????????????? %% incorrect,? 0+1i=[i
> 0]*[1 i]'
>
> ? ? The problem is that for nx1 row vectors a and b both with non-zero
> imaginary parts,
> ??? a*b' turns out to be b*a', which is the conjugate of the correct result.
> If either a or b
> ??? are real, the result will be correct.
>
> ??? I also checked out Octave 3.0.3, it didn't have this problem.
>
> ??? So, is it a run time configuration problem, a build configuration
> problem, or a bug?
>
>
> Regards,
>
> ? Shuhua Zhang, Oct. 16, 2009

Oops.
Please try this patch:
http://hg.savannah.gnu.org/hgweb/octave/rev/f3ebc728ffd7

thanks for report

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From shuhua.zhang at gmail.com  Sun Aug 16 00:06:17 2009
From: shuhua.zhang at gmail.com (Shuhua Zhang)
Date: Sun, 16 Aug 2009 13:06:17 +0800
Subject: [OctDev] incorrect complex matrix multiplication results in 
	Octave 3.2.2
In-Reply-To: <892b16670908152157y748473fbte69d34616f53a826@mail.gmail.com>
References: <c98441230908152033tbbb2d20o3a28b4e6a9610083@mail.gmail.com>
	<892b16670908152157y748473fbte69d34616f53a826@mail.gmail.com>
Message-ID: <c98441230908152206u700d7560w35bd75dee4de7f87@mail.gmail.com>

Hi,

   Thanks for your kind reply!

Regards,

   Shuhua Zhang, Aug 16, 2009


On Sun, Aug 16, 2009 at 12:57 PM, Dmitri A. Sergatskov <
dasergatskov at gmail.com> wrote:

> On Sat, Aug 15, 2009 at 10:33 PM, Shuhua Zhang<shuhua.zhang at gmail.com>
> wrote:
> > Hi,
> >
> >      I built octave 3.2.2 on my x86_64 desktop and x86 notebook a few
> weeks
> > ago.
> >      They passed all the tests.
> >
> >      But I've just noticed some weird complex matrix multiplication
> results
> > on both
> >      the machines:
> >           octave:48> [1 0]*[i 0]'
> >           ans =  0 - 1i                               %% correct
> >           octave:49> [1 i]*[i 0]'
> >           ans =  0 + 1i                             %% incorrect,
> 0+1i=[i
> > 0]*[1 i]'
> >
> >     The problem is that for nx1 row vectors a and b both with non-zero
> > imaginary parts,
> >     a*b' turns out to be b*a', which is the conjugate of the correct
> result.
> > If either a or b
> >     are real, the result will be correct.
> >
> >     I also checked out Octave 3.0.3, it didn't have this problem.
> >
> >     So, is it a run time configuration problem, a build configuration
> > problem, or a bug?
> >
>
> This looks like a bug, but you reported it to the wrong list.
> I Cc'ed it accordingly.
>
>
> octave:14> a=[1,i]
> a =
>
>   1 + 0i   0 + 1i
>
> octave:15> b=[i,0]
> b =
>
>   0 + 1i   0 + 0i
>
> octave:16> c=b'
> c =
>
>   0 - 1i
>   0 - 0i
>
> octave:17> a*b'
> ans =  0 + 1i
> octave:18> a*c
> ans =  0 - 1i
>
>
>
> >
> > Regards,
> >
> >   Shuhua Zhang, Oct. 16, 2009
> >
>
> Sincerely,
>
> Dmitri.
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090816/ac3032e4/attachment-0001.html 

From tbohdan at yahoo.com.au  Sun Aug 16 03:27:42 2009
From: tbohdan at yahoo.com.au (Tom Bohdan)
Date: Sun, 16 Aug 2009 01:27:42 -0700 (PDT)
Subject: Formatted Output bug
Message-ID: <954365.80607.qm@web45710.mail.sp1.yahoo.com>

I was running this simple m-file. 
I think there is a bug in the printf statement. It simply cannot print two variables correctly. The second variable is always wrong. I can print them separately and it works. It has me baffled.

Ubuntu 9.04, 

p, li { white-space: pre-wrap; }

QtOctave version 0..7.4Octave 
p, li { white-space: pre-wrap; }
3.0.1


p, li { white-space: pre-wrap; }

mass=1500*[1 0 0 0;0 2 0 0;0 0 2 0;0 0 0 3]
stiff=800e3*[1 -1 0 0;-1 3 -2 0;0 -2 5 -3;0 0 -3 7]
mr=sqrtm(mass);
kt=inv(mr)*stiff*inv(mr);
[v,d]=eig(kt);
w=sqrt(d);
w=w*[1;1;1;1];
w=w./(2*pi)
T=1./w
printf("Natural Frequency = %.2f Hz  \n" ,w)
printf("Period = %.2f Hz  \n" ,T)
printf("Natural Frequency = %f Hz		Period= %f   \n",  w ,T )


      __________________________________________________________________________________
Find local businesses and services in your area with Yahoo!7 Local.
Get started: http://local.yahoo.com.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090816/e12ab640/attachment.html 

From dastew at sympatico.ca  Sun Aug 16 09:52:35 2009
From: dastew at sympatico.ca (dastew at sympatico.ca)
Date: Sun, 16 Aug 2009 14:52:35 +0000
Subject: Formatted Output bug
In-Reply-To: <954365.80607.qm@web45710.mail.sp1.yahoo.com>
References: <954365.80607.qm@web45710.mail.sp1.yahoo.com>
Message-ID: <COL107-W32A08772BF89402EA9F383A1000@phx.gbl>




Date: Sun, 16 Aug 2009 01:27:42 -0700
From: tbohdan at yahoo.com.au
Subject: Formatted Output bug
To: bug at octave.org

I was running this simple m-file. 
I think there is a bug in the printf statement. It simply cannot print two variables correctly. The second variable is always wrong. I can print them separately and it works. It has me baffled.

Ubuntu 9.04, 

QtOctave version 0.7.4Octave 3.0.1



mass=1500*[1 0 0 0;0 2 0 0;0 0 2 0;0 0 0 3]
stiff=800e3*[1 -1 0 0;-1 3 -2 0;0 -2 5 -3;0 0 -3 7]
mr=sqrtm(mass);
kt=inv(mr)*stiff*inv(mr);
[v,d]=eig(kt);
w=sqrt(d);
w=w*[1;1;1;1];
w=w./(2*pi)
T=1./w
printf("Natural Frequency = %.2f Hz  \n" ,w)
printf("Period = %.2f Hz  \n" ,T)
printf("Natural Frequency = %f Hz		Period= %f   \n",  w ,T )




      
Find local businesses and services in your area with Yahoo!7 Local.  Get started.


On my ubuntu i get this
octave-3.0.1:14> 
octave-3.0.1:14> printf("Natural Frequency = %.2f Hz \n" ,w)
Natural Frequency = 1.73 Hz 
Natural Frequency = 3.85 Hz 
Natural Frequency = 5.34 Hz 
Natural Frequency = 7.26 Hz 
octave-3.0.1:15> 
octave-3.0.1:15> printf("Period = %.2f Hz \n" ,T)
Period = 0.58 Hz 
Period = 0.26 Hz 
Period = 0.19 Hz 
Period = 0.14 Hz 
octave-3.0.1:16> 
octave-3.0.1:16> printf("Natural Frequency = %f Hz Period= %f \n", w ,T )
Natural Frequency = 1.727485 Hz Period= 3.854267 
Natural Frequency = 5.338151 Hz Period= 7.261830 
Natural Frequency = 0.578876 Hz Period= 0.259453 
Natural Frequency = 0.187331 Hz Period= 0.137706 
octave-3.0.1:17> 

It is using all the w array first and then all the T array.

Doug Stewart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090816/9d15f826/attachment.html 

From dastew at sympatico.ca  Sun Aug 16 10:11:45 2009
From: dastew at sympatico.ca (dastew at sympatico.ca)
Date: Sun, 16 Aug 2009 15:11:45 +0000
Subject: Formatted Output bug
In-Reply-To: <COL107-W32A08772BF89402EA9F383A1000@phx.gbl>
References: <954365.80607.qm@web45710.mail.sp1.yahoo.com>
	<COL107-W32A08772BF89402EA9F383A1000@phx.gbl>
Message-ID: <COL107-W1221E7BA9BC6C80C9C685A1000@phx.gbl>




From: dastew at sympatico.ca
To: tbohdan at yahoo.com.au; bug at octave.org
Subject: RE: Formatted Output bug
Date: Sun, 16 Aug 2009 14:52:35 +0000










Date: Sun, 16 Aug 2009 01:27:42 -0700
From: tbohdan at yahoo.com.au
Subject: Formatted Output bug
To: bug at octave.org

I was running this simple m-file. 
I think there is a bug in the printf statement. It simply cannot print two variables correctly. The second variable is always wrong. I can print them separately and it works. It has me baffled.

Ubuntu 9.04, 

QtOctave version 0.7.4Octave 3.0.1



mass=1500*[1 0 0 0;0 2 0 0;0 0 2 0;0 0 0 3]
stiff=800e3*[1 -1 0 0;-1 3 -2 0;0 -2 5 -3;0 0 -3 7]
mr=sqrtm(mass);
kt=inv(mr)*stiff*inv(mr);
[v,d]=eig(kt);
w=sqrt(d);
w=w*[1;1;1;1];
w=w./(2*pi)
T=1./w
printf("Natural Frequency = %.2f Hz  \n" ,w)
printf("Period = %.2f Hz  \n" ,T)
printf("Natural Frequency = %f Hz		Period= %f   \n",  w ,T )




      
Find local businesses and services in your area with Yahoo!7 Local.  Get started.


On my ubuntu i get this
octave-3.0.1:14> 
octave-3.0.1:14> printf("Natural Frequency = %.2f Hz \n" ,w)
Natural Frequency = 1.73 Hz 
Natural Frequency = 3.85 Hz 
Natural Frequency = 5.34 Hz 
Natural Frequency = 7.26 Hz 
octave-3.0.1:15> 
octave-3.0.1:15> printf("Period = %.2f Hz \n" ,T)
Period = 0.58 Hz 
Period = 0.26 Hz 
Period = 0.19 Hz 
Period = 0.14 Hz 
octave-3.0.1:16> 
octave-3.0.1:16> printf("Natural Frequency = %f Hz Period= %f \n", w ,T )
Natural Frequency = 1.727485 Hz Period= 3.854267 
Natural Frequency = 5.338151 Hz Period= 7.261830 
Natural Frequency = 0.578876 Hz Period= 0.259453 
Natural Frequency = 0.187331 Hz Period= 0.137706 
octave-3.0.1:17> 

It is using all the w array first and then all the T array.

Doug Stewart



You cold try

q=[w T]'
octave-3.0.1:16> printf("Natural Frequency = %f Hz Period= %f \n", q )
Natural Frequency = 1.727485 Hz Period= 0.578876 
Natural Frequency = 3.854267 Hz Period= 0.259453 
Natural Frequency = 5.338151 Hz Period= 0.187331 
Natural Frequency = 7.261830 Hz Period= 0.137706 
octave-3.0.1:24> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090816/12229021/attachment.html 

From dastew at sympatico.ca  Sun Aug 16 22:29:50 2009
From: dastew at sympatico.ca (dastew at sympatico.ca)
Date: Mon, 17 Aug 2009 03:29:50 +0000
Subject: Formatted Output bug
In-Reply-To: <61311.3555.qm@web45701.mail.sp1.yahoo.com>
References: <COL107-W1221E7BA9BC6C80C9C685A1000@phx.gbl>
	<61311.3555.qm@web45701.mail.sp1.yahoo.com>
Message-ID: <COL107-W1088ABC65DDE4D84D8F992A1010@phx.gbl>




Date: Sun, 16 Aug 2009 19:44:55 -0700
From: tbohdan at yahoo.com.au
Subject: RE: Formatted Output bug
To: dastew at sympatico.ca

thanks for the prompt reply. I still find it odd that it would print the first array and then the second array when i have clearly specified the order etc. Thanks for the tip to correct it

You are welcome. 

I don't know if this is a bug or is the desired effect.
 But at least you have it working now.
Doug


--- On Mon, 17/8/09, dastew at sympatico.ca <dastew at sympatico.ca> wrote:

From: dastew at sympatico.ca <dastew at sympatico.ca>
Subject: RE: Formatted Output bug
To: tbohdan at yahoo.com.au, bug at octave.org
Received: Monday, 17 August, 2009, 1:11 AM






From: dastew at sympatico.ca
To: tbohdan at yahoo.com.au; bug at octave.org
Subject: RE: Formatted Output bug
Date: Sun, 16 Aug 2009 14:52:35 +0000










Date: Sun, 16 Aug 2009 01:27:42 -0700
From: tbohdan at yahoo.com.au
Subject: Formatted Output bug
To: bug at octave.org

I was running this simple m-file. 
I think there is a bug in the printf statement. It simply cannot print two variables correctly. The second variable is always wrong. I can print them separately and it works. It has me baffled.

Ubuntu 9.04, 

QtOctave version 0.7.4Octave 3.0.1



mass=1500*[1 0 0 0;0 2 0 0;0 0 2 0;0 0 0 3]
stiff=800e3*[1 -1 0 0;-1 3 -2 0;0 -2 5 -3;0 0 -3 7]
mr=sqrtm(mass);
kt=inv(mr)*stiff*inv(mr);
[v,d]=eig(kt);
w=sqrt(d);
w=w*[1;1;1;1];
w=w./(2*pi)
T=1./w
printf("Natural Frequency = %.2f Hz  \n" ,w)
printf("Period = %.2f Hz  \n" ,T)
printf("Natural Frequency = %f Hz		Period= %f   \n",  w ,T )




      
Find local businesses and services in your area with Yahoo!7 Local.  Get started..


On my ubuntu i get this
octave-3.0.1:14> 
octave-3.0.1:14> printf("Natural Frequency = %.2f Hz \n" ,w)
Natural Frequency = 1.73 Hz 
Natural Frequency = 3.85 Hz 
Natural Frequency = 5.34 Hz 
Natural Frequency = 7.26 Hz 
octave-3.0.1:15> 
octave-3.0.1:15> printf("Period = %.2f Hz \n" ,T)
Period = 0.58 Hz 
Period = 0.26 Hz 
Period = 0.19 Hz 
Period = 0.14 Hz 
octave-3.0.1:16> 
octave-3.0.1:16> printf("Natural Frequency = %f Hz Period= %f \n", w ,T )
Natural Frequency = 1.727485 Hz Period= 3.854267 
Natural Frequency = 5.338151 Hz Period= 7.261830 
Natural Frequency = 0.578876 Hz Period= 0.259453 
Natural Frequency = 0.187331 Hz Period= 0.137706 
octave-3.0.1:17> 

It is using all the w array first and then all the T array.

Doug Stewart



You
 cold try

q=[w T]'
octave-3.0.1:16> printf("Natural Frequency = %f Hz Period= %f \n", q )
Natural Frequency = 1.727485 Hz Period= 0.578876 
Natural Frequency = 3.854267 Hz Period= 0.259453 
Natural Frequency = 5.338151 Hz Period= 0.187331 
Natural Frequency = 7.261830 Hz Period= 0.137706 
octave-3.0.1:24> 

 





      
Find local businesses and services in your area with Yahoo!7 Local.  Get started.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090817/04e9c96e/attachment.html 

From jwe at octave.org  Sun Aug 16 23:18:31 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 17 Aug 2009 00:18:31 -0400
Subject: Formatted Output bug
In-Reply-To: <COL107-W1088ABC65DDE4D84D8F992A1010@phx.gbl>
References: <COL107-W1221E7BA9BC6C80C9C685A1000@phx.gbl>
	<61311.3555.qm@web45701.mail.sp1.yahoo.com>
	<COL107-W1088ABC65DDE4D84D8F992A1010@phx.gbl>
Message-ID: <19080.55831.508268.970495@segfault.lan>

On 17-Aug-2009, dastew at sympatico.ca wrote:

| I don't know if this is a bug or is the desired effect.

It's not a bug.  It's the way it is supposed to work, and is
compatible with the way Matlab behaves.

jwe


From tmacchant at yahoo.co.jp  Mon Aug 17 00:13:08 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 17 Aug 2009 14:13:08 +0900 (JST)
Subject: buid error octave-bug.exe by GCC-4.4.0 building (MinGW Official but
	not TDM)
Message-ID: <20090817051308.27767.qmail@web3806.mail.bbt.yahoo.co.jp>

Hello

I have tried to build the development branch source with gcc-4.4.0 MinGW (from Official site version
but not TDM version).

description	GNU Octave (development branch)
owner	John W. Eaton
last change	Sun, 16 Aug 2009 08:25:24 +0200
project home	http://savannah.gnu.org/projects/octave


I have encountered make error at building octave-bug.exe

g++ -shared-libgcc -c -Ic:/Programs/OctaveBuild/include -Ic:/Programs/WinDevTools/include
-Ic:/Programs/GnuWin32/include
 -IC:/Programs/GnuWin32/include -I. -I../../hg/octave-work -I. -I./liboctave -I./src -I./libcruft/misc
-I../../hg/octave
-work -I../../hg/octave-work/liboctave -I../../hg/octave-work/src -I../../hg/octave-work/libcruft/misc
 -DHAVE_CONFIG_H
-mieee-fp -IC:/Programs/WinDevTools/include/freetype2 -IC:/Programs/WinDevTools/include
-IC:/Programs/WinDevTools/includ
e   -Wall -W -Wshadow -Wold-style-cast -Wformat -D_DLL -DPIC -O3 -fomit-frame-pointer  octave-bug.cc
-o octave-bug.o
octave-bug.cc: In function 'int main(int, char**)':
octave-bug.cc:102: error: expected primary-expression before '%' token
octave-bug.cc:102: error: 'OCTAVE_CONF_FFTW_LIBS' was not declared in this scope
octave-bug.cc:102: error: expected primary-expression before ';' token
octave-bug.cc:231: warning: use of old-style cast
octave-bug.cc:232: warning: use of old-style cast
octave-bug.cc:233: warning: use of old-style cast
octave-bug.cc:240: warning: deprecated conversion from string constant to 'CHAR*'
octave-bug.cc:240: warning: deprecated conversion from string constant to 'CHAR*'
octave-bug.cc:254: warning: deprecated conversion from string constant to 'CHAR*'
make[1]: *** [octave-bug.o] Error 1
make[1]: Leaving directory `/home/octaves/OctBuild/hg-devel'
make: *** [all] Error 2


I have looked at line 102 of octave-bug.cc generated by configure

  vars["FFTW_LIBS"] = %OCTAVE_CONF_FFTW_LIBS%;

Surely 'OCTAVE_CONF_FFTW_LIBS' was not declared in this scope.

I have used 

  --with-fftw3-includedir=c:/Programs/OctaveBuild/include \
  --with-fftw3-libdir=c:/Programs/OctaveBuild/lib \
  --with-fftw3f-includedir=c:/Programs/OctaveBuild/include \
  --with-fftw3f-libdir=c:/Programs/OctaveBuild/lib \

flags at the configure.
Why this is not recognized ?

Regards

Tatsuro
 

The  below is just the reference.
***************:
Octave is now configured for i686-pc-mingw32

  Source directory:     ../../hg/octave-work
  Installation prefix:  c:/Programs/OctaveBuild
  C compiler:           gcc -shared-libgcc  -mieee-fp  -Wall -W -Wshadow -Wformat -D_DLL -DPIC -O3
-fomit-frame-pointer
  C++ compiler:         g++ -shared-libgcc  -mieee-fp -IC:/Programs/WinDevTools/include/freetype2
-IC:/Programs/WinDevTo
ols/include -IC:/Programs/WinDevTools/include    -Wall -W -Wshadow -Wold-style-cast -Wformat -D_DLL
-DPIC -O3 -fomit-fra
me-pointer
  Fortran compiler:     gfortran -shared-libgcc -D_DLL -DPIC -O3 -fomit-frame-pointer -mieee-fp
  Fortran libraries:     -Lc:/Programs/OctaveBuild/lib -L:/Programs/WinDevTools/lib
-Lc:/Programs/GnuWin32/lib -Lc:/prog
rams/mingw/bin/../lib/gcc/mingw32/4.4.0 -Lc:/programs/mingw/bin/../lib/gcc
-Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.
4.0/../../../../mingw32/lib -Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/../../.. -lm
-lgfortran.dll -lgfortranbegin
 -lgfortran -lmingw32 -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32
  LIBS:                 -liberty  -lblas.dll -llapack.dll  -Lc:/Programs/OctaveBuild/lib
-L:/Programs/WinDevTools/lib -L
c:/Programs/GnuWin32/lib -Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0
-Lc:/programs/mingw/bin/../lib/gcc -Lc:/progra
ms/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/lib
-Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/../../..
-lm -lgfortran.dll -lgfortranbegin -lgfortran -lmingw32 -lmoldname -lmingwex -lmsvcrt -luser32
-lkernel32 -ladvapi32 -ls
hell32 -lblas.dll -llapack.dll -lm -lgfortran.dll -lgdi32 -lws2_32 -luser32 -lkernel32

  AMD CPPFLAGS:         -Ic:/Programs/OctaveBuild/include
  AMD LDFLAGS:          -Lc:/Programs/OctaveBuild/lib
  AMD libraries:        -lamd
  ARPACK libraries:     -larpack
  BLAS libraries:        -lblas.dll -llapack.dll
  CAMD CPPFLAGS:        -Ic:/Programs/OctaveBuild/include
  CAMD LDFLAGS:         -Lc:/Programs/OctaveBuild/lib
  CAMD libraries:       -lcamd
  CARBON libraries:
  CCOLAMD CPPFLAGS:     -Ic:/Programs/OctaveBuild/include
  CCOLAMD LDFLAGS:      -Lc:/Programs/OctaveBuild/lib
  CCOLAMD libraries:    -lccolamd
  CHOLMOD CPPFLAGS:     -Ic:/Programs/OctaveBuild/include
  CHOLMOD LDFLAGS:      -Lc:/Programs/OctaveBuild/lib
  CHOLMOD libraries:    -lcholmod
  COLAMD CPPFLAGS:      -Ic:/Programs/OctaveBuild/include
  COLAMD LDFLAGS:       -Lc:/Programs/OctaveBuild/lib
  COLAMD libraries:     -lcolamd
  CURL CPPFLAGS:        -Ic:/Programs/OctaveBuild/include
  CURL LDFLAGS:         -Lc:/Programs/OctaveBuild/lib
  CURL libraries:       -lcurl
  CXSPARSE CPPFLAGS:    -Ic:/Programs/OctaveBuild/include
  CXSPARSE LDFLAGS:     -Lc:/Programs/OctaveBuild/lib
  CXSPARSE libraries:   -lcxsparse
  DL libraries:
  FFTW3 CPPFLAGS:       -Ic:/Programs/OctaveBuild/include
  FFTW3 LDFLAGS:        -Lc:/Programs/OctaveBuild/lib
  FFTW3 libraries:      -lfftw3
  FFTW3F CPPFLAGS:      -Ic:/Programs/OctaveBuild/include
  FFTW3F LDFLAGS:       -Lc:/Programs/OctaveBuild/lib
  FFTW3F libraries:     -lfftw3f
  FLTK backend libs:    -L/c/Programs/OctaveBuild/lib -mwindows -Lc:/Programs/OctaveBuild/lib
-Lc:/Programs/WinDevTools/
lib -Lc:/Programs/GnuWin32/lib -mno-cygwin -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc
-lfltk_gl -lglu32
-lopengl32 -lfltk -lpthread -lole32 -lcomctl32
  GLPK CPPFLAGS:        -Ic:/Programs/OctaveBuild/include
  GLPK LDFLAGS:         -Lc:/Programs/OctaveBuild/lib
  GLPK libraries:       -lglpk
  HDF5 libraries:       -lhdf5
  OPENGL libraries:     -LC:/Programs/WinDevTools/lib -lfontconfig   -lftgl
-LC:/Programs/WinDevTools/lib -lfreetype -lo
pengl32 -lglu32
  PTHREAD flags:
  PTHREAD libraries:    -lpthread
  QHULL CPPFLAGS:       -Ic:/Programs/OctaveBuild/include
  QHULL LDFLAGS:        -Lc:/Programs/OctaveBuild/lib
  QHULL libraries:      -lqhull
  QRUPDATE libraries:   -lqrupdate
  READLINE libraries:   -lreadline
  REGEX libraries:      -lregex -LC:/Programs/GnuWin32/lib -lpcre -Wl,-s
  TERM libraries:       -ltermcap
  UMFPACK libraries:    -lumfpack
  X11 include flags:
  X11 libraries:
  ZLIB libraries:       -lz

  Default pager:        less
  gnuplot:              gnuplot
  Magick config:        GraphicsMagick++-config

  Do internal array bounds checking:  false
  Build static libraries:             false
  Build shared libraries:             true
  Dynamic Linking:                    true (LoadLibrary)
  Include support for GNU readline:   true
  64-bit array dims and indexing:     false




--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

From lindnerben at gmx.net  Mon Aug 17 02:12:03 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 17 Aug 2009 09:12:03 +0200
Subject: buid error octave-bug.exe by GCC-4.4.0 building (MinGW Official
	but	not TDM)
In-Reply-To: <20090817051308.27767.qmail@web3806.mail.bbt.yahoo.co.jp>
References: <20090817051308.27767.qmail@web3806.mail.bbt.yahoo.co.jp>
Message-ID: <4A8902C3.3010907@gmx.net>

Tatsuro MATSUOKA wrote:
> Hello
> 
> I have tried to build the development branch source with gcc-4.4.0 MinGW (from Official site version
> but not TDM version).
> 
> I have looked at line 102 of octave-bug.cc generated by configure
> 
>   vars["FFTW_LIBS"] = %OCTAVE_CONF_FFTW_LIBS%;
> 
> Surely 'OCTAVE_CONF_FFTW_LIBS' was not declared in this scope.

Yes, the configure scripts are currently under change (link 
dependencies) and both the C++ as the shell versions of both bug-octave 
and mkoctfile need to be updated.

I believe it's best to do this when the configure process is settled again.

benjamin

From tmacchant at yahoo.co.jp  Mon Aug 17 02:40:04 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 17 Aug 2009 16:40:04 +0900 (JST)
Subject: buid error octave-bug.exe by GCC-4.4.0 building (MinGW Official
	but not TDM)
In-Reply-To: <4A8902C3.3010907@gmx.net>
Message-ID: <20090817074004.38605.qmail@web3803.mail.bbt.yahoo.co.jp>

Hello

--- Benjamin Lindner  wrote:

> Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have tried to build the development branch source with gcc-4.4.0 MinGW (from Official site
> version
> > but not TDM version).
> > 
> > I have looked at line 102 of octave-bug.cc generated by configure
> > 
> >   vars["FFTW_LIBS"] = %OCTAVE_CONF_FFTW_LIBS%;
> > 
> > Surely 'OCTAVE_CONF_FFTW_LIBS' was not declared in this scope.
> 
> Yes, the configure scripts are currently under change (link 
> dependencies) and both the C++ as the shell versions of both bug-octave 
> and mkoctfile need to be updated.
> 
> I believe it's best to do this when the configure process is settled again.
> 
Thank you for your reply.
I will wait for your change.

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

From lindnerben at gmx.net  Mon Aug 17 04:58:24 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 17 Aug 2009 11:58:24 +0200
Subject: imgwrite/imfinfo fail in octave 3.2.x
Message-ID: <4A8929C0.9000204@gmx.net>

Hello,

I am building a 3.2.2 mingw32 binary and during testing I get the 
following error when calling imwrite.

octave.exe:1> a = uint16([12340,12341,12342]);
octave.exe:2> imwrite("test16.tif", a);
error: `__magick_write__' undefined near line 124 column 7
error: called from:
error: 
D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\share\octave\3.2.2\m\image\imwrite.m 
at line 124, column 7

indeed there is no file __magick_write__.oct, but an __magick_read__.oct.
and the PKG_ADD file contains the line

autoload ("magick_write", "__magick_read__.oct");

but imwrite.m calls a function "__magick_write__".
Interestingly "help magick_write" states the function name to be 
"__magick_write__"

 > help magick_write
`magick_write' is a function from the file 
D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\libexec\octave\3.2.2\oct\i686-pc-mingw32\__magick_read__.oct

  -- Function File:  __magick_write__(FNAME, FMT, IMG)
  -- Function File:  __magick_write__(FNAME, FMT, IMG, MAP)
      Write images with ImageMagick++.  In general you should not be
      using this function.  Instead you should use `imwrite'.

      See also: imread


So I'm confused as to what to fix. Should it be "__magick_write__" or 
"magick_write".

The same goes for "magick_finfo" vs. "__magick_finfo__".
The script imfinfo.m calls "__magick_finfo__", however the PKG_ADD file 
only autoloads

autoload ("magick_finfo", "__magick_read__.oct");

so a call to imfinfo also fails.

octave.exe:5> imfinfo('c:\windows\winnt.bmp')
error: `__magick_finfo__' undefined near line 129 column 12
error: called from:
error: 
D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\share\octave\3.2.2\m\
image\imfinfo.m at line 134, column 5


benjamin


From tmacchant at yahoo.co.jp  Mon Aug 17 05:36:26 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 17 Aug 2009 19:36:26 +0900 (JST)
Subject: imgwrite/imfinfo fail in octave 3.2.x
In-Reply-To: <4A8929C0.9000204@gmx.net>
Message-ID: <20090817103626.30974.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello

In my case,

GNU Octave, version 3.2.2
 :
octave.exe:1> cd D:\usr\Tatsu\program\Octave\test2
octave.exe:2>  a = uint16([12340,12341,12342]);
octave.exe:3> imwrite("test16.tif", a);
error: Invalid call to imwrite.  Correct usage is:

 -- Function File:  imwrite (IMG, FILENAME, FMT, P1, V1, ...)
 -- Function File:  imwrite (IMG, MAP, FILENAME, FMT, P1, V1, ...)


Additional help for built-in functions and operators is
available in the on-line version of the manual.  Use the command
`doc <topic>' to search the manual index.

Help and information about Octave is also available on the WWW
at http://www.octave.org and via the help at octave.org
mailing list.
octave.exe:3> imwrite(a,"test16.tif");
octave.exe:4> imread("test16.tif")
octave.exe:5> b=imread("test16.tif")
b =

  12339  12340  12341

I have used graphicsmagick  configured with  --with-quantum-depth=16. 

Regards

Tatsuro

--- Benjamin Lindner wrote:

> Hello,
> 
> I am building a 3.2.2 mingw32 binary and during testing I get the 
> following error when calling imwrite.
> 
> octave.exe:1> a = uint16([12340,12341,12342]);
> octave.exe:2> imwrite("test16.tif", a);
> error: `__magick_write__' undefined near line 124 column 7
> error: called from:
> error: 
>
D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\share\octave\3.2.2\m\image\imwrite.m
> 
> at line 124, column 7
> 
> indeed there is no file __magick_write__.oct, but an __magick_read__.oct.
> and the PKG_ADD file contains the line
> 
> autoload ("magick_write", "__magick_read__.oct");
> 
> but imwrite.m calls a function "__magick_write__".
> Interestingly "help magick_write" states the function name to be 
> "__magick_write__"
> 
>  > help magick_write
> `magick_write' is a function from the file 
>
D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\libexec\octave\3.2.2\oct\i686-pc-mingw32\__magick_read__.oct
> 
>   -- Function File:  __magick_write__(FNAME, FMT, IMG)
>   -- Function File:  __magick_write__(FNAME, FMT, IMG, MAP)
>       Write images with ImageMagick++.  In general you should not be
>       using this function.  Instead you should use `imwrite'.
> 
>       See also: imread
> 
> 
> So I'm confused as to what to fix. Should it be "__magick_write__" or 
> "magick_write".
> 
> The same goes for "magick_finfo" vs. "__magick_finfo__".
> The script imfinfo.m calls "__magick_finfo__", however the PKG_ADD file 
> only autoloads
> 
> autoload ("magick_finfo", "__magick_read__.oct");
> 
> so a call to imfinfo also fails.
> 
> octave.exe:5> imfinfo('c:\windows\winnt.bmp')
> error: `__magick_finfo__' undefined near line 129 column 12
> error: called from:
> error: 
> D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\share\octave\3.2.2\m\
> image\imfinfo.m at line 134, column 5
> 
> 
> benjamin
> 
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

From lindnerben at gmx.net  Mon Aug 17 05:54:04 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 17 Aug 2009 12:54:04 +0200
Subject: imgwrite/imfinfo fail in octave 3.2.x
In-Reply-To: <20090817103626.30974.qmail@web3808.mail.bbt.yahoo.co.jp>
References: <20090817103626.30974.qmail@web3808.mail.bbt.yahoo.co.jp>
Message-ID: <4A8936CC.7050307@gmx.net>

Tatsuro MATSUOKA wrote:
> Hello
> 
> In my case,
> 
> GNU Octave, version 3.2.2
>  :
> octave.exe:1> cd D:\usr\Tatsu\program\Octave\test2
> octave.exe:2>  a = uint16([12340,12341,12342]);
> octave.exe:3> imwrite("test16.tif", a);
> error: Invalid call to imwrite.  Correct usage is:
> 
>  -- Function File:  imwrite (IMG, FILENAME, FMT, P1, V1, ...)
>  -- Function File:  imwrite (IMG, MAP, FILENAME, FMT, P1, V1, ...)
> 

You are of course right, stupid copy-from-console-and-paste-into-emailer 
error.

> --- Benjamin Lindner wrote:
> 
>> Hello,
>>
>> I am building a 3.2.2 mingw32 binary and during testing I get the 
>> following error when calling imwrite.
>>
>> octave.exe:1> a = uint16([12340,12341,12342]);
>> octave.exe:2> imwrite("test16.tif", a);
                  ^^^^^^^^^^^^^^^^^^^^^^^^

this should read of course
octave.exe:2> imwrite(a, "test16.tif");

>> error: `__magick_write__' undefined near line 124 column 7
>> error: called from:
>> error: 
>>
> D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\share\octave\3.2.2\m\image\imwrite.m
>> at line 124, column 7
>>
>> indeed there is no file __magick_write__.oct, but an __magick_read__.oct.
>> and the PKG_ADD file contains the line
>>
>> autoload ("magick_write", "__magick_read__.oct");
>>
>> but imwrite.m calls a function "__magick_write__".
>> Interestingly "help magick_write" states the function name to be 
>> "__magick_write__"
>>
>>  > help magick_write
>> `magick_write' is a function from the file 
>>
> D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\libexec\octave\3.2.2\oct\i686-pc-mingw32\__magick_read__.oct
>>   -- Function File:  __magick_write__(FNAME, FMT, IMG)
>>   -- Function File:  __magick_write__(FNAME, FMT, IMG, MAP)
>>       Write images with ImageMagick++.  In general you should not be
>>       using this function.  Instead you should use `imwrite'.
>>
>>       See also: imread
>>
>>
>> So I'm confused as to what to fix. Should it be "__magick_write__" or 
>> "magick_write".
>>
>> The same goes for "magick_finfo" vs. "__magick_finfo__".
>> The script imfinfo.m calls "__magick_finfo__", however the PKG_ADD file 
>> only autoloads
>>
>> autoload ("magick_finfo", "__magick_read__.oct");
>>
>> so a call to imfinfo also fails.
>>
>> octave.exe:5> imfinfo('c:\windows\winnt.bmp')
>> error: `__magick_finfo__' undefined near line 129 column 12
>> error: called from:
>> error: 
>> D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\share\octave\3.2.2\m\
>> image\imfinfo.m at line 134, column 5
>>
>>
>> benjamin


From lindnerben at gmx.net  Mon Aug 17 08:10:10 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 17 Aug 2009 15:10:10 +0200
Subject: imgwrite/imfinfo fail in octave 3.2.x
In-Reply-To: <4A8936CC.7050307@gmx.net>
References: <20090817103626.30974.qmail@web3808.mail.bbt.yahoo.co.jp>
	<4A8936CC.7050307@gmx.net>
Message-ID: <4A8956B2.4040500@gmx.net>

Benjamin Lindner wrote:
>>> Hello,
>>>
>>> I am building a 3.2.2 mingw32 binary and during testing I get the 
>>> following error when calling imwrite.
>>>
>>> octave.exe:1> a = uint16([12340,12341,12342]);
>>> octave.exe:2> imwrite("test16.tif", a);
>                   ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> this should read of course
> octave.exe:2> imwrite(a, "test16.tif");
> 
>>> error: `__magick_write__' undefined near line 124 column 7
>>> error: called from:
>>> error: 
>>>
>> D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\share\octave\3.2.2\m\image\imwrite.m
>>> at line 124, column 7
>>>

The problem is the following changeset
http://hg.tw-math.de/release-3-2-x/rev/44300eb51817
which changes the names of the DLD functions in __magick_read__.cc but 
does not appropriately change the function names in the scripts where 
they are called.
It changes, however, in imread.m the call to __magick_read__ into a call 
to magick_read_internal, which seems wrong.

Now on the development branch, the unintended changes were undone by the 
two changesets

http://hg.savannah.gnu.org/hgweb/octave/rev/3ca88e72f0e8
http://hg.savannah.gnu.org/hgweb/octave/rev/5302df15ad76

So these two should also be transplanted to the 3.2.x branch!

benjamin



From cameron at morland.ca  Mon Aug 17 12:11:57 2009
From: cameron at morland.ca (roger_wilco)
Date: Mon, 17 Aug 2009 10:11:57 -0700 (PDT)
Subject: axis colors override xrdb
Message-ID: <25010647.post@talk.nabble.com>


Hi,

I'm using Octave 3.0.1 (Ubuntu), and gnuplot 4.2 patchlevel 4.

I would prefer to have my plots be white-on-black.  As I understand, gnuplot
does not support changing the background color, in general.  So I am using
xrdb to set the background in the x11 terminal.  I am also specifying
gnuplot*borderColor (and tried *textColor and *axisColor, to no evident
impact).  In gnuplot, the color of the border, legend, and axis labels all
take the value from *borderColor.  

In Octave, the border and legend behave as in gnuplot, but the axis labels
remain black.

I have not been able to discover how to specify the color of the axis
labels.  If I knew that I would be happy enough.  At the same time, it would
be ideal if Octave would allow gnuplot to use the default colors.

Let me know if I can help solve this problem.
-- 
View this message in context: http://www.nabble.com/axis-colors-override-xrdb-tp25010647p25010647.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From jwe at octave.org  Tue Aug 18 11:16:47 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 18 Aug 2009 12:16:47 -0400
Subject: MacOSX: cannot link liboctinterp and octave anymore
In-Reply-To: <69d8d540908122357r67d7d6e4qc94290bd19474317@mail.gmail.com>
References: <4A812086.8090806@gmx.net> <4A813A8F.5000302@acc.umu.se>
	<19073.36937.903371.755463@segfault.lan>
	<69d8d540908120634l18744a03n62974f0545ef40@mail.gmail.com>
	<19074.57087.451333.870324@segfault.lan>
	<69d8d540908122308m47fb5841s9f2da6b57fb8e05d@mail.gmail.com>
	<69d8d540908122357r67d7d6e4qc94290bd19474317@mail.gmail.com>
Message-ID: <19082.54255.710219.124026@segfault.lan>

On 13-Aug-2009, Jaroslav Hajek wrote:

| 2. In top/Makeconf, I now have (after configure CXXFLAGS=something, no
| other options)
| 
| LIBS=-lblas -lm
| 
| where did -lblas come from? It probably doesn't hurt, but seems leaked
| from somewhere.

I checked in the following change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/afbdf01bcacc

jwe

From svabj at foi.se  Tue Aug 18 12:44:54 2009
From: svabj at foi.se (=?ISO-8859-1?Q?=22Svante_Bj=F6rklund=2C_FOI=22?=)
Date: Tue, 18 Aug 2009 19:44:54 +0200
Subject: Illegal instruction graphics
Message-ID: <4A8AE896.6060205@foi.se>

To: bug at octave.org
Cc: svabj at foi.se
Subject: Illegal instruction graphics
--------
Bug report for Octave 3.2.2 configured for i686-pc-linux-gnu

Description:
-----------

  * Please replace this item with a detailed description of the
    problem.  Suggestions or general comments are also welcome.

    Octave crashes for all graphic commands that I try (except "figure")
with the message "panic: Illegal instruction -- stopping myself...".
    Octave crashes when I try to run "make check".
    I am using OpenSuse Linux 11.1.
    I have compiled from source: "./configure" and "make".
    I had to install some extra libraries and "devel" packages.
    I gave no command-line arguments to the "configure" command.

Repeat-By:
---------

  * Please replace this item with a description of the sequence of
    events that causes the problem to occur.




magic(svabj)49> ./run-octave
GNU Octave, version 3.2.2
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 "i686-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 <bug at octave.org> (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'.

warning: implicit conversion from scalar to string
octave:1> figure
octave:2> title('Test')
panic: Illegal instruction -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Illegal instruction
magic(svabj)49>


magic(svabj)49> ./run-octave
GNU Octave, version 3.2.2
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 "i686-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 <bug at octave.org> (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'.

warning: implicit conversion from scalar to string
octave:1> figure
octave:2> plot 1
panic: Illegal instruction -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Illegal instruction
magic(svabj)49>


magic(svabj)50> ./run-octave
GNU Octave, version 3.2.2
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 "i686-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 <bug at octave.org> (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'.

warning: implicit conversion from scalar to string
octave:1> figure
octave:2> xlabel('test')
panic: Illegal instruction -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Illegal instruction
magic(svabj)51>


magic(svabj)51> make check
make -f octMakefile check
make[1]: Entering directory `/export/home/svabj/src/octave-3.2.2'
make -C test check
make[2]: Entering directory `/export/home/svabj/src/octave-3.2.2/test'
../run-octave --norc --silent --no-history ./fntests.m .

Integrated test scripts:

  src/DLD-FUNCTIONS/besselj.cc ...........................panic: Illegal
instruction -- stopping myself...
make[2]: *** [check] Illegal instruction
make[2]: Leaving directory `/export/home/svabj/src/octave-3.2.2/test'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/export/home/svabj/src/octave-3.2.2'
make: *** [check] Error 2
magic(svabj)52>


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 magic 2.6.27.25-0.1-pae #1 SMP 2009-07-01
15:37:09 +0200 i686 i686 i386 GNU/Linux
configure opts:
Fortran compiler: gfortran
FFLAGS:           -O -mieee-fp
FLIBS:            -L/usr/lib/gcc/i586-suse-linux/4.3
-L/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/lib
-L/usr/lib/gcc/i586-suse-linux/4.3/../../.. -lhdf5 -lz -lgfortranbegin
-lgfortran -lm
CPPFLAGS:
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.2 [gcc-4_3-branch revision 141291]
(SUSE Linux)
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,/usr/local/lib/octave-3.2.2
BLAS_LIBS:        -llapack -lcblas -lf77blas -latlas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lcblas -lf77blas -latlas
-lhdf5 -lz -lm
LEXLIB:
LIBGLOB:
SED:              /usr/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_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_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_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 = kwrite
  EXEC_PATH =
/usr/local/libexec/octave/3.2.2/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.2/exec/i686-pc-linux-gnu:/usr/local/bin:/home/svabj/bin:/home/svabj/local/bin:/opt/kde3/bin:/home/svabj/bin:/home/svabj/local/bin:/usr/lib/mpi/gcc/openmpi/bin:/home/svabj/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/X11R6/bin:/usr/bin/X11:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/gnome/bin:/usr/lib/qt3/bin:/export/usr/local/bin:/export/usr/local/bin
  IMAGE_PATH = .:/home/svabj/export/src/octave-3.2.2/scripts/image
  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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/svabj/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file =
/export/home/svabj/src/octave-3.2.2/doc/interpreter/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 = <no value or error in displaying it>
  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 marco.caliari at univr.it  Wed Aug 19 08:19:51 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Wed, 19 Aug 2009 15:19:51 +0200 (CEST)
Subject: Dimensions mismatch (fwd)
Message-ID: <alpine.DEB.1.00.0908191510220.28697@profs.sci.univr.it>

Dear maintainers,

I investigated a little bit the problem, that is

octave:1> v(:,1:2)=[1,1]
error: A(I,J,...) = X: dimensions mismatch

in Octave 3.2.2 and discovered that, if I remove

rhdv0.chop_all_singletons ();

from zero_dims_inquire in Array-utils.cc, than it works. What does not 
work is

octave:2> v(:,1:2)=[1;1]
error: A(I,J,...) = X: dimensions mismatch

which is a correct behavior for me and also ml-compatible. However, the 
same command in Octave 3.0.5 gives

octave-3.0.5:1> v(:,1:2)=[1;1]
v =

    1   1

I hope my investigation can help to fix the problem.

Best regards,

Marco

---------- Forwarded message ----------
Date: Wed, 12 Aug 2009 16:04:50 +0200 (CEST)
From: Marco Caliari <marco.caliari at univr.it>
To: bug-octave at octave.org
Subject: Dimensions mismatch

Dear maintainers,

I noticed that the following

octave:1> v(:,1:2)=[1,1]

gives

error: A(I,J,...) = X: dimensions mismatch

in Octave 3.2.2 whereas it works in Octave 3.0.5 and gives

v =

    1   1

No problem for, e.g.,

octave:2> v(:,1:2)=[1,1;2,2]
v =

    1   1
    2   2

Best regards,

Marco

From highegg at gmail.com  Wed Aug 19 09:25:56 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 19 Aug 2009 16:25:56 +0200
Subject: Dimensions mismatch
In-Reply-To: <alpine.DEB.1.00.0908121601280.8946@profs.sci.univr.it>
References: <alpine.DEB.1.00.0908121601280.8946@profs.sci.univr.it>
Message-ID: <69d8d540908190725v54180ccci507d80968b9c0083@mail.gmail.com>

On Wed, Aug 12, 2009 at 4:04 PM, Marco Caliari<marco.caliari at univr.it> wrote:
> Dear maintainers,
>
> I noticed that the following
>
> octave:1> v(:,1:2)=[1,1]
>
> gives
>
> error: A(I,J,...) = X: dimensions mismatch
>
> in Octave 3.2.2 whereas it works in Octave 3.0.5 and gives
>
> v =
>
> ? ?1 ? 1
>
> No problem for, e.g.,
>
> octave:2> v(:,1:2)=[1,1;2,2]
> v =
>
> ? ?1 ? 1
> ? ?2 ? 2
>
> Best regards,
>

please try
http://hg.savannah.gnu.org/hgweb/octave/rev/ed34b1da0e26

thanks

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From cameron at morland.ca  Thu Aug 20 13:54:17 2009
From: cameron at morland.ca (roger_wilco)
Date: Thu, 20 Aug 2009 11:54:17 -0700 (PDT)
Subject: axis colors override xrdb
In-Reply-To: <25010647.post@talk.nabble.com>
References: <25010647.post@talk.nabble.com>
Message-ID: <25067791.post@talk.nabble.com>



roger_wilco wrote:
> 
> I have not been able to discover how to specify the color of the axis
> labels.  If I knew that I would be happy enough.  At the same time, it
> would be ideal if Octave would allow gnuplot to use the default colors.
> 

This patch uses gnuplot's default colours for the axes, and possibly other
cases.  It would be better to set a non-empty colorspec string iff the user
has asked to change the axes colours, but I don't understand the code well
enough to do that.

<pre>
diff -u __go_draw_axes__.m.orig __go_draw_axes__.m
--- __go_draw_axes__.m.orig	2009-08-20 14:52:20.000000000 -0400
+++ __go_draw_axes__.m	2009-08-20 14:43:26.000000000 -0400
@@ -1590,9 +1590,12 @@
     if (mono)
       colorspec = "";
     else
-			colorspec = sprintf ("textcolor rgb \"#%02x%02x%02x\"",
-			round (255*color));
+			% don't fuss with the axis colours, let gnuplot do that.
+			%colorspec = sprintf ("textcolor rgb \"#%02x%02x%02x\"",
+			%   round (255*color));
+			colorspec = "";
     endif
   else
     typ = get_old_gnuplot_color (color);
     colorspec = sprintf ("textcolor lt %d", typ);
</pre>


-- 
View this message in context: http://www.nabble.com/axis-colors-override-xrdb-tp25010647p25067791.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From marco.caliari at univr.it  Fri Aug 21 04:17:00 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Fri, 21 Aug 2009 11:17:00 +0200 (CEST)
Subject: contourf and edgecolor
Message-ID: <alpine.DEB.1.00.0908211111010.425@profs.sci.univr.it>

Dear maintainers,

I noticed that

contourf(peaks,'EdgeColor','red')

gives

error: subscript indices must be either positive integers or logicals.
error: called from:
error:   /usr/local/share/octave/3.2.2/m/plot/__add_datasource__.m at line 
42, column 5
error:   /usr/local/share/octave/3.2.2/m/plot/__contour__.m at line 110, 
column 8
error:   /usr/local/share/octave/3.2.2/m/plot/contourf.m at line 73, 
column 5

(Octave 3.2.2, gnuplot 4.2.5). I easily fixed this problem, changing

strcmpi (arg(end-9:end), "datasource")

with

strcmpi (arg(max(end-9,1):end), "datasource")

but then I get

error: set: unknown property "EdgeColor"
error: called from:
error:   /usr/local/share/octave/3.2.2/m/plot/__contour__.m at line 191, 
column 5
error:   /usr/local/share/octave/3.2.2/m/plot/contourf.m at line 73, 
column 5

No problem in Octave 3.0.5 or ml.

Best regards,

Marco

From dbateman at free.fr  Fri Aug 21 07:32:10 2009
From: dbateman at free.fr (dbateman)
Date: Fri, 21 Aug 2009 05:32:10 -0700 (PDT)
Subject: contourf and edgecolor
In-Reply-To: <alpine.DEB.1.00.0908211111010.425@profs.sci.univr.it>
References: <alpine.DEB.1.00.0908211111010.425@profs.sci.univr.it>
Message-ID: <25078927.post@talk.nabble.com>




Marco Caliari-4 wrote:
> 
> Dear maintainers,
> 
> I noticed that
> 
> contourf(peaks,'EdgeColor','red')
> 
> gives
> 
> error: subscript indices must be either positive integers or logicals.
> error: called from:
> error:   /usr/local/share/octave/3.2.2/m/plot/__add_datasource__.m at line 
> 42, column 5
> error:   /usr/local/share/octave/3.2.2/m/plot/__contour__.m at line 110, 
> column 8
> error:   /usr/local/share/octave/3.2.2/m/plot/contourf.m at line 73, 
> column 5
> 
> (Octave 3.2.2, gnuplot 4.2.5). I easily fixed this problem, changing
> 
> strcmpi (arg(end-9:end), "datasource")
> 
> with
> 
> strcmpi (arg(max(end-9,1):end), "datasource")
> 
> but then I get
> 
> error: set: unknown property "EdgeColor"
> error: called from:
> error:   /usr/local/share/octave/3.2.2/m/plot/__contour__.m at line 191, 
> column 5
> error:   /usr/local/share/octave/3.2.2/m/plot/contourf.m at line 73, 
> column 5
> 
> No problem in Octave 3.0.5 or ml.
> 
> Best regards,
> 
> Marco
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
> 
> 

I can't patch this now, but changing the line

&& length (arg) > 1 && strcmpi (arg(end-9:end), "datasource")

to 

&& length (arg) > 9 && strcmpi (arg(end-9:end), "datasource")

and it will work correctly. I believe it should be 'LineColor' and not
'EdgeColor' for this case as well. Can someone generate and apply the patch
for me?

Cheers
David

-- 
View this message in context: http://www.nabble.com/contourf-and-edgecolor-tp25076787p25078927.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From dbateman at free.fr  Fri Aug 21 07:33:05 2009
From: dbateman at free.fr (dbateman)
Date: Fri, 21 Aug 2009 05:33:05 -0700 (PDT)
Subject: contourf and edgecolor
In-Reply-To: <25078927.post@talk.nabble.com>
References: <alpine.DEB.1.00.0908211111010.425@profs.sci.univr.it>
	<25078927.post@talk.nabble.com>
Message-ID: <25078940.post@talk.nabble.com>




dbateman wrote:
> 
> 
> 
> Marco Caliari-4 wrote:
>> 
>> Dear maintainers,
>> 
>> I noticed that
>> 
>> contourf(peaks,'EdgeColor','red')
>> 
>> gives
>> 
>> error: subscript indices must be either positive integers or logicals.
>> error: called from:
>> error:   /usr/local/share/octave/3.2.2/m/plot/__add_datasource__.m at
>> line 
>> 42, column 5
>> error:   /usr/local/share/octave/3.2.2/m/plot/__contour__.m at line 110, 
>> column 8
>> error:   /usr/local/share/octave/3.2.2/m/plot/contourf.m at line 73, 
>> column 5
>> 
>> (Octave 3.2.2, gnuplot 4.2.5). I easily fixed this problem, changing
>> 
>> strcmpi (arg(end-9:end), "datasource")
>> 
>> with
>> 
>> strcmpi (arg(max(end-9,1):end), "datasource")
>> 
>> but then I get
>> 
>> error: set: unknown property "EdgeColor"
>> error: called from:
>> error:   /usr/local/share/octave/3.2.2/m/plot/__contour__.m at line 191, 
>> column 5
>> error:   /usr/local/share/octave/3.2.2/m/plot/contourf.m at line 73, 
>> column 5
>> 
>> No problem in Octave 3.0.5 or ml.
>> 
>> Best regards,
>> 
>> Marco
>> _______________________________________________
>> Bug-octave mailing list
>> Bug-octave at octave.org
>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>> 
>> 
> 
> I can't patch this now, but changing the line
> 
> && length (arg) > 1 && strcmpi (arg(end-9:end), "datasource")
> 
> to 
> 
> && length (arg) > 9 && strcmpi (arg(end-9:end), "datasource")
> 
> and it will work correctly. I believe it should be 'LineColor' and not
> 'EdgeColor' for this case as well. Can someone generate and apply the
> patch for me?
> 
> Cheers
> David
> 
> 

The patch is in __add_datasource__.m around line 43

D.


-- 
View this message in context: http://www.nabble.com/contourf-and-edgecolor-tp25076787p25078940.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From marco.caliari at univr.it  Fri Aug 21 08:05:10 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Fri, 21 Aug 2009 15:05:10 +0200 (CEST)
Subject: contourf and edgecolor
Message-ID: <alpine.DEB.1.00.0908211453320.4380@profs.sci.univr.it>

Dear David,

yes, 'LineColor' works. On the other hand, it does not work in Octave 
3.0.5 (while 'EdgeColor' works) and 'EdgeColor', although not mentioned in 
the docs, appears to be a synonym for 'LineColor' in Matlab (at least for 
contourf). I would suggest to keep it as a synonym.

Thanks,

Marco

From marco.caliari at univr.it  Fri Aug 21 08:10:41 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Fri, 21 Aug 2009 15:10:41 +0200 (CEST)
Subject: epslatexstandalone
Message-ID: <alpine.DEB.1.00.0908211505220.4380@profs.sci.univr.it>

Dear maintainers,

the following

x=linspace(0,10);
plot(x,x)
print('-depslatexstandalone','foo.tex')

produces a final eps file in which the axis labels appears to be shifted 
up-right. I'm using Octave 3.2.2 and gnuplot 4.2.5.

Best regards,

Marco

From dbateman at free.fr  Fri Aug 21 08:26:02 2009
From: dbateman at free.fr (dbateman)
Date: Fri, 21 Aug 2009 06:26:02 -0700 (PDT)
Subject: contourf and edgecolor
In-Reply-To: <alpine.DEB.1.00.0908211453320.4380@profs.sci.univr.it>
References: <alpine.DEB.1.00.0908211111010.425@profs.sci.univr.it>
	<alpine.DEB.1.00.0908211453320.4380@profs.sci.univr.it>
Message-ID: <25079753.post@talk.nabble.com>




Marco Caliari-4 wrote:
> 
> Dear David,
> 
> yes, 'LineColor' works. On the other hand, it does not work in Octave 
> 3.0.5 (while 'EdgeColor' works) and 'EdgeColor', although not mentioned in 
> the docs, appears to be a synonym for 'LineColor' in Matlab (at least for 
> contourf). I would suggest to keep it as a synonym.
> 
> Thanks,
> 
> Marco
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
> 
> 

Ok, then a new patch is need for the contourgroup making edgecolor a synonym
to linecolor. I'll see what I can do over the weekend

D.

-- 
View this message in context: http://www.nabble.com/contourf-and-edgecolor-tp25076787p25079753.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From alexl at users.sourceforge.net  Fri Aug 21 17:55:59 2009
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Fri, 21 Aug 2009 15:55:59 -0700
Subject: "panic" message during install of octave-forge-20090607 with Octave
	3.2.2
Message-ID: <7ud46olqtc.fsf@allele2.eebweb.arizona.edu>

Hi there,

I'm the maintainer of the octave-forge packages for Fedora and I'm
trying to build the full bundle, but running into "panic" messages

I get this message during the final installation (after the build all
of the packages) during the installation.  This is not exactly
repeatable because it occurs at different points (but it always
happens for at least one package during the build).  This particular
run happened during the install of financial-0.3.2

+ cd ..
+ for dir in '*.[0-9]'
+ cd financial-0.3.2
+ make install TMPDIR=/var/tmp
+ DESTDIR=/builddir/build/BUILDROOT/octave-forge-20090607-8.fc12.x86_64
+ DISTPKG=redhat
mkdir (/var/tmp/oct-BuLyRd)
untar (/var/tmp/financial-0.3.2.tar.gz, /var/tmp/oct-BuLyRd)
panic: Illegal instruction -- stopping myself...
/bin/sh: line 41: 21088 Illegal instruction     octave -H -q
+ --no-site-file --eval
+ "warning('off','all');pkg('prefix','$octprefix','$archprefix');pkg('global_list',fullfile('$shareprefix','octave_packages'));pkg('local_list',fullfile('$shareprefix','octave_packages'));pkg('install','-nodeps','-nodeps','-verbose','/var/tmp/financial-0.3.2.tar.gz');"
error: can't perform indexing operations for cs-list type
error: evaluating argument list element number 1
error: evaluating argument list element number 1
/bin/sh: line 25: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 26: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 27: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 28: /packinfo/dist_admin: No such file or directory
/bin/sh: line 29: /packinfo/dist_admin: No such file or directory
/bin/sh: line 30: /packinfo/dist_admin: No such file or directory
/bin/sh: line 31: /packinfo/dist_admin: No such file or directory
/bin/sh: line 32: /packinfo/dist_admin: No such file or directory
/bin/sh: line 33: /packinfo/dist_admin: No such file or directory
/bin/sh: line 34: /packinfo/dist_admin: No such file or directory
/bin/sh: line 35: /packinfo/dist_admin: No such file or directory
/bin/sh: line 36: /packinfo/dist_admin: No such file or directory
/bin/sh: line 37: /packinfo/dist_admin: No such file or directory
/bin/sh: line 38: /packinfo/dist_admin: No such file or directory
/bin/sh: line 39: /packinfo/dist_admin: No such file or directory
chmod: cannot access `/packinfo/dist_admin': No such file or directory

Full log is available here:

https://koji.fedoraproject.org/koji/getfile?taskID=1616313&name=build.log

and the overall task information (showing dependent package versions)
are linked to from:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1616313

Thanks,
Alex

From bpabbott at mac.com  Fri Aug 21 18:41:49 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Fri, 21 Aug 2009 19:41:49 -0400
Subject: contourf and edgecolor
In-Reply-To: <25079753.post@talk.nabble.com>
References: <alpine.DEB.1.00.0908211111010.425@profs.sci.univr.it>
	<alpine.DEB.1.00.0908211453320.4380@profs.sci.univr.it>
	<25079753.post@talk.nabble.com>
Message-ID: <425E1541-D3DC-4F73-BBBA-487B3ECA36E5@mac.com>


On Aug 21, 2009, at 9:26 AM, dbateman wrote:

> Marco Caliari-4 wrote:
>>
>> Dear David,
>>
>> yes, 'LineColor' works. On the other hand, it does not work in Octave
>> 3.0.5 (while 'EdgeColor' works) and 'EdgeColor', although not  
>> mentioned in
>> the docs, appears to be a synonym for 'LineColor' in Matlab (at  
>> least for
>> contourf). I would suggest to keep it as a synonym.
>>
>> Thanks,
>>
>> Marco
>> _______________________________________________
>> Bug-octave mailing list
>> Bug-octave at octave.org
>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>>
>>
>
> Ok, then a new patch is need for the contourgroup making edgecolor a  
> synonym
> to linecolor. I'll see what I can do over the weekend
>
> D.

David, I have a faint recollection that you may no longer have access  
to a current Matlab license (?).

What I see is more complicated than I'd expected, but appears straight  
forward (not for me as I've never bother to dig into the details of  
the hggroup).

 >> [c,h] = contour(rand(10,10));
 >> get (h, 'linecolor')

ans =

auto

 >> get (h, 'edgecolor')

ans =

flat

 >> set (h, 'linecolor', 'b')
 >> get (h, 'edgecolor')

ans =

      0     0     1

 >> set (h, 'linecolor', 'auto')
 >> get (h, 'edgecolor')

ans =

flat

 >> set (h, 'edgecolor', [0 0 1])
 >> get (h, 'linecolor')

ans =

      0     0     1

 >> set (h, 'edgecolor', 'flat')
 >> get (h, 'linecolor')

ans =

auto

 >> set (h, 'edgecolor', [0 0 1])
 >> set (h, 'linecolor', [0 0 1])
 >> set (h, 'edgecolor', 'flat')
 >> get (h, 'linecolor')

ans =

auto

Ben

p.s. This has to go under WWMTT ... maybe we should start a list for  
"What Was MathWorks Thinking"? ;-)


From bpabbott at mac.com  Fri Aug 21 19:07:43 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Fri, 21 Aug 2009 20:07:43 -0400
Subject: axis colors override xrdb
In-Reply-To: <25067791.post@talk.nabble.com>
References: <25010647.post@talk.nabble.com> <25067791.post@talk.nabble.com>
Message-ID: <C94965D2-FFC8-4EB0-BB8B-8336F20FCC12@mac.com>


On Aug 20, 2009, at 2:54 PM, roger_wilco wrote:

> roger_wilco wrote:
>>
>> I have not been able to discover how to specify the color of the axis
>> labels.  If I knew that I would be happy enough.  At the same time,  
>> it
>> would be ideal if Octave would allow gnuplot to use the default  
>> colors.
>>
>
> This patch uses gnuplot's default colours for the axes, and possibly  
> other
> cases.  It would be better to set a non-empty colorspec string iff  
> the user
> has asked to change the axes colours, but I don't understand the  
> code well
> enough to do that.
>
> <pre>
> diff -u __go_draw_axes__.m.orig __go_draw_axes__.m
> --- __go_draw_axes__.m.orig	2009-08-20 14:52:20.000000000 -0400
> +++ __go_draw_axes__.m	2009-08-20 14:43:26.000000000 -0400
> @@ -1590,9 +1590,12 @@
>     if (mono)
>       colorspec = "";
>     else
> -			colorspec = sprintf ("textcolor rgb \"#%02x%02x%02x\"",
> -			round (255*color));
> +			% don't fuss with the axis colours, let gnuplot do that.
> +			%colorspec = sprintf ("textcolor rgb \"#%02x%02x%02x\"",
> +			%   round (255*color));
> +			colorspec = "";
>     endif
>   else
>     typ = get_old_gnuplot_color (color);
>     colorspec = sprintf ("textcolor lt %d", typ);
> </pre>

Roger,

Octave's current sources have changed a lot since 3.0.x.

I recommend you upgrade.

Regarding how to produce a plot on a black background, we'd prefer to  
find a solution that is compatible with Matlab. With Matlab, the  
following produces a blue line on a black background with the axes'  
lines and labels drawn in white..

plot (1:10)
set (gca, 'color', [0 0 0])
set (gcf, 'color', [0 0 0])
set (gca,'xcolor',[1 1 1],'ycolor',[1 1 1])

None of the "set" commands result in the compatible changes for Octave  
(perhaps 3 patches are needed?).

If you have the time, your help in fixing this problem would be  
appreciated.

Regarding


From dasergatskov at gmail.com  Fri Aug 21 19:22:55 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Fri, 21 Aug 2009 19:22:55 -0500
Subject: "panic" message during install of octave-forge-20090607 with 
	Octave 3.2.2
In-Reply-To: <7ud46olqtc.fsf@allele2.eebweb.arizona.edu>
References: <7ud46olqtc.fsf@allele2.eebweb.arizona.edu>
Message-ID: <892b16670908211722u7286181cidafa83d8c1bfc988@mail.gmail.com>

On Fri, Aug 21, 2009 at 5:55 PM, Alex
Lancaster<alexl at users.sourceforge.net> wrote:
> Hi there,
>
> I'm the maintainer of the octave-forge packages for Fedora and I'm
> trying to build the full bundle, but running into "panic" messages
>
> I get this message during the final installation (after the build all
> of the packages) during the installation. ?This is not exactly
> repeatable because it occurs at different points (but it always
> happens for at least one package during the build). ?This particular
> run happened during the install of financial-0.3.2
>

FWIW -- I do not have problem installing financial-0.3.2 by hand
(i.e by running pkg install financial-0.3.2.tar.gz on octave propt)
on octave-3.2.2 that I built from fedora-devel src.rpm, though
with lapack and blas libs replaced
with atlas. This is on Fedora 11 (x86_64).

Sincerely,

Dmitri.
--


From dasergatskov at gmail.com  Fri Aug 21 19:37:12 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Fri, 21 Aug 2009 19:37:12 -0500
Subject: "panic" message during install of octave-forge-20090607 with 
	Octave 3.2.2
In-Reply-To: <7ud46olqtc.fsf@allele2.eebweb.arizona.edu>
References: <7ud46olqtc.fsf@allele2.eebweb.arizona.edu>
Message-ID: <892b16670908211737x5d7cd89cia6712f9a283104b1@mail.gmail.com>

On Fri, Aug 21, 2009 at 5:55 PM, Alex
Lancaster<alexl at users.sourceforge.net> wrote:

> https://koji.fedoraproject.org/koji/getfile?taskID=1616313&name=build.log
>
BTW I cannot connect with https:// but http:// seems to work.
In any case, at the very beginning I see:

sh: octave-config: command not found

Is it normal? I have octave-config in /usr/bin and it isa symlink to
octave-config-3.2.2


> Alex

Dmitri.
--

From alexl at users.sourceforge.net  Sat Aug 22 03:37:52 2009
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 22 Aug 2009 01:37:52 -0700
Subject: "panic" message during install of octave-forge-20090607 with
	Octave 3.2.2
In-Reply-To: <892b16670908211722u7286181cidafa83d8c1bfc988@mail.gmail.com>
	(Dmitri A. Sergatskov's message of "Fri\,
	21 Aug 2009 19\:22\:55 -0500")
References: <7ud46olqtc.fsf@allele2.eebweb.arizona.edu>
	<892b16670908211722u7286181cidafa83d8c1bfc988@mail.gmail.com>
Message-ID: <xd8whckzvj.fsf@allele2.eebweb.arizona.edu>

>>>>> Dmitri A Sergatskov  writes:

> On Fri, Aug 21, 2009 at 5:55 PM, Alex
> Lancaster<alexl at users.sourceforge.net> wrote:
>> Hi there,
>> 
>> I'm the maintainer of the octave-forge packages for Fedora and I'm
>> trying to build the full bundle, but running into "panic" messages
>> 
>> I get this message during the final installation (after the build all
>> of the packages) during the installation. ?This is not exactly
>> repeatable because it occurs at different points (but it always
>> happens for at least one package during the build). ?This particular
>> run happened during the install of financial-0.3.2
>> 

> FWIW -- I do not have problem installing financial-0.3.2 by hand
> (i.e by running pkg install financial-0.3.2.tar.gz on octave propt)
> on octave-3.2.2 that I built from fedora-devel src.rpm, though
> with lapack and blas libs replaced
> with atlas. This is on Fedora 11 (x86_64).

Thanks, but how did you replace lapack with atlas, did you modify the
BuildRequires in the octave.spec file?  If so, could you send me your
changes.

I'm not suprised that it worked in standalone mode, because the
installation fails during the build at random places, not always in
the financials package, but it seems after installing a number of
packages in a row (which is what the .spec is effectively doing).

To get access to the .src.rpm files, even for builds that fail on
koji, you can generally go the "buildSRPMFromSCM" link on the task
page.  In the case of octave-forge

http://koji.fedoraproject.org/koji/taskinfo?taskID=1616369

which will take you to:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1616370

with a link to the src.rpm:

http://koji.fedoraproject.org/koji/getfile?taskID=1616370&name=octave-forge-20090607-8.fc12.src.rpm

Sorry for the https:// links earlier, they work if you're a Fedora
developer logged into koji, just drop the "s".

Alex


From alexl at users.sourceforge.net  Sat Aug 22 03:42:44 2009
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 22 Aug 2009 01:42:44 -0700
Subject: "panic" message during install of octave-forge-20090607 with
	Octave 3.2.2
In-Reply-To: <892b16670908211737x5d7cd89cia6712f9a283104b1@mail.gmail.com>
	(Dmitri A. Sergatskov's message of "Fri\,
	21 Aug 2009 19\:37\:12 -0500")
References: <7ud46olqtc.fsf@allele2.eebweb.arizona.edu>
	<892b16670908211737x5d7cd89cia6712f9a283104b1@mail.gmail.com>
Message-ID: <741vn4kznf.fsf@allele2.eebweb.arizona.edu>

>>>>> Dmitri A Sergatskov  writes:

> On Fri, Aug 21, 2009 at 5:55 PM, Alex
> Lancaster<alexl at users.sourceforge.net> wrote:

>> https://koji.fedoraproject.org/koji/getfile?taskID=1616313&name=build.log
>> 
> BTW I cannot connect with https:// but http:// seems to work.
> In any case, at the very beginning I see:

> sh: octave-config: command not found

> Is it normal? I have octave-config in /usr/bin and it isa symlink to
> octave-config-3.2.2

I think that has been there on previous builds which worked, e.g. in
the last (pre Octave 3.2) octave-forge build, it appears at the top:

http://kojipkgs.fedoraproject.org/packages/octave-forge/20080831/10.fc12/data/logs/i686/build.log

but the build successfully completes.  Same with the version in F-11:

http://kojipkgs.fedoraproject.org/packages/octave-forge/20080831/8.fc11/data/logs/i586/build.log

Alex

From xarthisius.kk at gmail.com  Sat Aug 22 08:12:02 2009
From: xarthisius.kk at gmail.com (Kacper Kowalik)
Date: Sat, 22 Aug 2009 15:12:02 +0200
Subject: Fixing HDF-1.8 API for octave-3.2.x
Message-ID: <cf1003df0908220612u140d4fdj33af43722ca904e5@mail.gmail.com>

Hi,
I've made a patch fixing HDF5 API in octave 3.2.x. It could be applied
when HDF5 is not compiled with backwards compatibility instead of
dropping --with-hdf5.
Best regards,
Kacper Kowalik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave-3.2.x-hdf1.8.patch
Type: application/octet-stream
Size: 32759 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090822/f88742ec/attachment-0001.obj 

From dasergatskov at gmail.com  Sat Aug 22 09:05:23 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Sat, 22 Aug 2009 09:05:23 -0500
Subject: "panic" message during install of octave-forge-20090607 with 
	Octave 3.2.2
In-Reply-To: <xd8whckzvj.fsf@allele2.eebweb.arizona.edu>
References: <7ud46olqtc.fsf@allele2.eebweb.arizona.edu>
	<892b16670908211722u7286181cidafa83d8c1bfc988@mail.gmail.com>
	<xd8whckzvj.fsf@allele2.eebweb.arizona.edu>
Message-ID: <892b16670908220705i57c0b088l457e62bcfc7d997c@mail.gmail.com>

On Sat, Aug 22, 2009 at 3:37 AM, Alex
Lancaster<alexl at users.sourceforge.net> wrote:

> Thanks, but how did you replace lapack with atlas, did you modify the
> BuildRequires in the octave.spec file? ?If so, could you send me your
> changes.
>

The spec file attached (sorry no diff) -- esentially I added to the config file
--with-blas="-L/usr/lib64/atlas -llapack -lptf77blas -lptcblas -latlas
-lpthread" --with-lapack="-L/usr/lib64/atlas -llapack -lptf77blas
-lptcblas -latlas -lpthread

(using both --with-lapack and --with-blas seems redudndant though, just
specifying --with-blas seems to be sufficient)

And removed lapack-devel and blas-devel from build requirements.

> I'm not suprised that it worked in standalone mode, because the
> installation fails during the build at random places, not always in
> the financials package, but it seems after installing a number of
> packages in a row (which is what the .spec is effectively doing).

In my experience a buid crashing at random places is a usual indication
of infrastructure problems namely:

-- bad hardware (flaky memory, bad CPU cooling)
-- lack of resources (not enough memory+swap, not enough disk space in
   /tmp and /var/tmp )

Do you use your own computer to build this, or it was some build farm?

> http://koji.fedoraproject.org/koji/getfile?taskID=1616370&name=octave-forge-20090607-8.fc12.src.rpm
>

Thanks. It built fine on my computer (which is Fedora 11, rather than rawhide).

> Alex
>

Dmitri.
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave.spec
Type: application/octet-stream
Size: 25067 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090822/3d376dee/attachment-0001.obj 

From dbateman at dbateman.org  Sat Aug 22 14:52:49 2009
From: dbateman at dbateman.org (David Bateman)
Date: Sat, 22 Aug 2009 21:52:49 +0200
Subject: contourf and edgecolor
In-Reply-To: <425E1541-D3DC-4F73-BBBA-487B3ECA36E5@mac.com>
References: <alpine.DEB.1.00.0908211111010.425@profs.sci.univr.it>	<alpine.DEB.1.00.0908211453320.4380@profs.sci.univr.it>	<25079753.post@talk.nabble.com>
	<425E1541-D3DC-4F73-BBBA-487B3ECA36E5@mac.com>
Message-ID: <4A904C91.2060406@dbateman.org>

Ben Abbott wrote:
> On Aug 21, 2009, at 9:26 AM, dbateman wrote:
>
>   
>> Marco Caliari-4 wrote:
>>     
>>> Dear David,
>>>
>>> yes, 'LineColor' works. On the other hand, it does not work in Octave
>>> 3.0.5 (while 'EdgeColor' works) and 'EdgeColor', although not  
>>> mentioned in
>>> the docs, appears to be a synonym for 'LineColor' in Matlab (at  
>>> least for
>>> contourf). I would suggest to keep it as a synonym.
>>>
>>> Thanks,
>>>
>>> Marco
>>> _______________________________________________
>>> Bug-octave mailing list
>>> Bug-octave at octave.org
>>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>>>
>>>
>>>       
>> Ok, then a new patch is need for the contourgroup making edgecolor a  
>> synonym
>> to linecolor. I'll see what I can do over the weekend
>>
>> D.
>>     
>
> David, I have a faint recollection that you may no longer have access  
> to a current Matlab license (?).
>
> What I see is more complicated than I'd expected, but appears straight  
> forward (not for me as I've never bother to dig into the details of  
> the hggroup).
>
>  >> [c,h] = contour(rand(10,10));
>  >> get (h, 'linecolor')
>
> ans =
>
> auto
>
>  >> get (h, 'edgecolor')
>
> ans =
>
> flat
>
>  >> set (h, 'linecolor', 'b')
>  >> get (h, 'edgecolor')
>
> ans =
>
>       0     0     1
>
>  >> set (h, 'linecolor', 'auto')
>  >> get (h, 'edgecolor')
>
> ans =
>
> flat
>
>  >> set (h, 'edgecolor', [0 0 1])
>  >> get (h, 'linecolor')
>
> ans =
>
>       0     0     1
>
>  >> set (h, 'edgecolor', 'flat')
>  >> get (h, 'linecolor')
>
> ans =
>
> auto
>
>  >> set (h, 'edgecolor', [0 0 1])
>  >> set (h, 'linecolor', [0 0 1])
>  >> set (h, 'edgecolor', 'flat')
>  >> get (h, 'linecolor')
>
> ans =
>
> auto
>
> Ben
>   
The attached patch, that I pushed, seems to duplicate this behavior. 
Perhaps it should be applied to 3.2.x as well (at least the change to 
__add_datasource__ should as that is a real bug).

> p.s. This has to go under WWMTT ... maybe we should start a list for  
> "What Was MathWorks Thinking"? ;-)
>   
I thought is good geek style that should be WTFWMT ;-)

D.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090822/1c11b3c9/attachment.ksh 

From dbateman at dbateman.org  Sat Aug 22 15:12:50 2009
From: dbateman at dbateman.org (David Bateman)
Date: Sat, 22 Aug 2009 22:12:50 +0200
Subject: Fixing HDF-1.8 API for octave-3.2.x
In-Reply-To: <cf1003df0908220612u140d4fdj33af43722ca904e5@mail.gmail.com>
References: <cf1003df0908220612u140d4fdj33af43722ca904e5@mail.gmail.com>
Message-ID: <4A905142.8020308@dbateman.org>

Kacper Kowalik wrote:
> Hi,
> I've made a patch fixing HDF5 API in octave 3.2.x. It could be applied
> when HDF5 is not compiled with backwards compatibility instead of
> dropping --with-hdf5.
> Best regards,
> Kacper Kowalik
>   

This patch will make Octave incompatible with older versions of HDF5 and 
a minimum of HDF5 v1.8 will be required. Frankly, I don't see that as a 
really bad thing as Octave will still build on older systems, just  
without HDF5 support. However, if this is done there is some code that 
works around bugs or missing features in older versions of HDF5 that 
should go. Basically anycode in

#ifndef HAVE_H5GGET_NUM_OBJS
#endif

or the else clause of the logical inverse of the above, and any code 
that is run when the variable have_h5giterate_bug is true.

Also the autoconf test should be changed such that only HDF5 v1.8 or 
later is considered as support, probably with a test of a function with 
a v1.8 API..

Regards
David


-- 
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)


From dasergatskov at gmail.com  Sat Aug 22 15:37:55 2009
From: dasergatskov at gmail.com (Dmitri A. Sergatskov)
Date: Sat, 22 Aug 2009 15:37:55 -0500
Subject: print() leaking resourses
Message-ID: <892b16670908221337q55bbc327l9014d906349ae5d3@mail.gmail.com>

It appears that print() leaves defunct gnuplot proceses behind.
Since the number of process is limited print() would eventually fail.

This is with octave 3.2.2. I have not tried the recent tip.

perhaps the simplest code to demonstrate the problem:
(provided ulimis -u is 1024)

octave:1> plot(randn(10));
octave:2> for ii=1:1025; ii; print("-dpng", "random.png"); endfor
sh: fork: retry: Resource temporarily unavailable
sh: fork: retry: Resource temporarily unavailable
error: value on right hand side of assignment is undefined
error: called from:
error:   /usr/share/octave/3.2.2/m/plot/print.m at line 696, column 7

"ps axu | grep gnuplot"  (in a different terminal, before quitting the
octave) would show defunct gnuplots

This is on Fedora 11 / x86_64 but appears to be observed on MacOS
as well...

Sincerely,

Dmitri.
--

From xarthisius.kk at gmail.com  Sun Aug 23 04:32:33 2009
From: xarthisius.kk at gmail.com (Kacper Kowalik)
Date: Sun, 23 Aug 2009 11:32:33 +0200
Subject: Fixing HDF-1.8 API for octave-3.2.x
In-Reply-To: <4A905142.8020308@dbateman.org>
References: <cf1003df0908220612u140d4fdj33af43722ca904e5@mail.gmail.com>
	<4A905142.8020308@dbateman.org>
Message-ID: <cf1003df0908230232p73aef993jc56895e9d59a1c49@mail.gmail.com>

Hi,
as I understood there was some kind of problem in <=hdf5-1.2.2 with
groups indexing in H5Giterate. Now it's long gone and things like !
HAVE_H5GGET_NUM_OBJS are obsolete and have_h5giterate_bug is always
false.
Initial cleaning is rather straightforward, but there is a catch...
Functions like H5Gget_num_objs and H5Giterate are depreciated in
HDF5-1.8, so the right way to do it would be to migrate to H5Gget_info
and H5Literate, already. However it's not that simple anymore. I could
look into it, but I would need some example HDF5 files or some simple
scripts for octave to check whether or not I've messed something up.
Best regards,
Kacper Kowalik

2009/8/22 David Bateman <dbateman at dbateman.org>:
> This patch will make Octave incompatible with older versions of HDF5 and a
> minimum of HDF5 v1.8 will be required. Frankly, I don't see that as a really
> bad thing as Octave will still build on older systems, just ?without HDF5
> support. However, if this is done there is some code that works around bugs
> or missing features in older versions of HDF5 that should go. Basically
> anycode in
>
> #ifndef HAVE_H5GGET_NUM_OBJS
> #endif
>
> or the else clause of the logical inverse of the above, and any code that is
> run when the variable have_h5giterate_bug is true.
>
> Also the autoconf test should be changed such that only HDF5 v1.8 or later
> is considered as support, probably with a test of a function with a v1.8
> API..
>
> Regards
> David
>
>
> --
> 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)
>
>


From dbateman at dbateman.org  Sun Aug 23 15:13:33 2009
From: dbateman at dbateman.org (David Bateman)
Date: Sun, 23 Aug 2009 22:13:33 +0200
Subject: Fixing HDF-1.8 API for octave-3.2.x
In-Reply-To: <cf1003df0908230232p73aef993jc56895e9d59a1c49@mail.gmail.com>
References: <cf1003df0908220612u140d4fdj33af43722ca904e5@mail.gmail.com>	
	<4A905142.8020308@dbateman.org>
	<cf1003df0908230232p73aef993jc56895e9d59a1c49@mail.gmail.com>
Message-ID: <4A91A2ED.6010203@dbateman.org>

Kacper Kowalik wrote:
> Hi,
> as I understood there was some kind of problem in <=hdf5-1.2.2 with
> groups indexing in H5Giterate. Now it's long gone and things like !
> HAVE_H5GGET_NUM_OBJS are obsolete and have_h5giterate_bug is always
> false.
> Initial cleaning is rather straightforward, but there is a catch...
> Functions like H5Gget_num_objs and H5Giterate are depreciated in
> HDF5-1.8, so the right way to do it would be to migrate to H5Gget_info
> and H5Literate, already. However it's not that simple anymore. I could
> look into it, but I would need some example HDF5 files or some simple
> scripts for octave to check whether or not I've messed something up.
> Best regards,
> Kacper Kowalik
>
>   
Use the code is test/test_io.m in the testls function and modify it to 
save to an hdf5 file and not delete it.. This will test most of the 
types in octave with simple case and should catch most bugs if you port 
completely to the HDF5 v1.8 API

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)


From svabj at foi.se  Wed Aug 19 04:10:51 2009
From: svabj at foi.se (=?ISO-8859-1?Q?=22Svante_Bj=F6rklund=2C_FOI=22?=)
Date: Wed, 19 Aug 2009 11:10:51 +0200
Subject: Least squares problem
Message-ID: <4A8BC19B.1010900@foi.se>

To: bug at octave.org
Cc: svabj at foi.se
Subject: Least squares problem
--------
Bug report for Octave 3.2.0 configured for i686-suse-linux-gnu

Description:
-----------

  * Please replace this item with a detailed description of the
    problem.  Suggestions or general comments are also welcome.

When trying to solve a linear least squares problem with "Q = U2\U1" a
Fortran routine returns an error message. The Fortran routine apparently
is given incorrect input. See the code below. I attach a MAT file with
U1 and U2 which cause the problem.

I have also tried with Octave 3.2.2, which I have compiled by myself.
Then I got "panic: Illegal instruction -- stopping myself..." as I also
get in other cases. See my bug report with subject "Illegal instruction
graphics".

I use OpenSuse Linux 11.1. Octave 3.2.0 I have downloaded and installed
as an RPM from an OpenSuse repository.



Repeat-By:
---------

  * Please replace this item with a description of the sequence of
    events that causes the problem to occur.


magic(svabj)43> octave
GNU Octave, version 3.2.0
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 "i686-suse-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 <bug at octave.org> (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'.

warning: implicit conversion from scalar to string
octave:1> load doaparbug1.mat
octave:2> Q = U2\U1;
 ** On entry to DLASDA parameter number  2 had an illegal value
error: exception encountered in Fortran subroutine zgelsd_
octave:2>


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 magic 2.6.27.25-0.1-pae #1 SMP 2009-07-01
15:37:09 +0200 i686 i686 i386 GNU/Linux
configure opts:   '--host=i686-suse-linux-gnu'
'--build=i686-suse-linux-gnu' '--target=i586-suse-linux'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' 'build_alias=i686-suse-linux-gnu'
'host_alias=i686-suse-linux-gnu' 'target_alias=i586-suse-linux'
'CFLAGS=-march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables' 'CPPFLAGS=-DH5_USE_16_API'
'CXXFLAGS=-march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables' 'FFLAGS=-march=i586 -mtune=i686
-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
-funwind-tables -fasynchronous-unwind-tables'
Fortran compiler: gfortran
FFLAGS:           -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -mieee-fp
FLIBS:            -L/usr/lib/gcc/i586-suse-linux/4.3
-L/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/lib
-L/usr/lib/gcc/i586-suse-linux/4.3/../../.. -lhdf5 -lz -lgfortranbegin
-lgfortran -lm
CPPFLAGS:         -DH5_USE_16_API
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.2 [gcc-4_3-branch revision 141291]
(SUSE Linux)
CFLAGS:           -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables
CPICFLAG:         -fPIC
C++ compiler:     g++, version 4.3.2
CXXFLAGS:         -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables
CXXPICFLAG:       -fPIC
LD_CXX:           g++
LDFLAGS:
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib/octave-3.2.0
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lblas -lhdf5 -lz -lm
LEXLIB:
LIBGLOB:
SED:              /usr/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_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=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 = kwrite
  EXEC_PATH =
/usr/lib/octave/3.2.0/site/exec/i686-suse-linux-gnu:/usr/lib/octave/api-v37/site/exec/i686-suse-linux-gnu:/usr/lib/octave/site/exec/i686-suse-linux-gnu:/usr/lib/octave/3.2.0/exec/i686-suse-linux-gnu:/usr/bin:/home/svabj/bin:/home/svabj/local/bin:/opt/kde3/bin:/home/svabj/bin:/home/svabj/local/bin:/usr/lib/mpi/gcc/openmpi/bin:/home/svabj/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/X11R6/bin:/usr/bin/X11:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/gnome/bin:/usr/lib/qt3/bin:/export/usr/local/bin:/export/usr/local/bin
  IMAGE_PATH = .:/usr/share/octave/3.2.0/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/svabj/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = /usr/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 = <no value or error in displaying it>
  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doaparbug1.mat
Type: application/x-crossover-mat
Size: 2041 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090819/5247a54e/attachment-0001.bin 

From svabj at foi.se  Wed Aug 19 08:03:53 2009
From: svabj at foi.se (svabj at foi.se)
Date: Wed, 19 Aug 2009 15:03:53 +0200
Subject: inferiorto: precedence already set
Message-ID: <4a8bf839.TFTGhOqXY+6ijEje%svabj@magic.foi.se>

To: bug at octave.org
Cc: svabj at foi.se
Subject: inferiorto: precedence already set

Bug report for Octave 3.2.2 configured for i686-pc-linux-gnu

Description:
-----------

  * Please replace this item with a detailed description of the
    problem.  Suggestions or general comments are also welcome.

  This is probably a bug in Octave if Octave is trying to be compatible with Matlab:
  Using both "superiorto('tf')" in class "ss" and "inferiorto('ss')" in class "tf" gives an error message in Octave but not in Matlab.


Repeat-By:
---------

  * Please replace this item with a description of the sequence of
    events that causes the problem to occur. 

  * Octave 3.2.2 gives this result (Octave 3.2.0 gives the same):

magic(svabj)41>  /home/svabj/export/src/octave-3.2.2/run-octave
GNU Octave, version 3.2.2
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 "i686-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 <bug at octave.org> (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'.

warning: implicit conversion from scalar to string
octave:1> P = genpath('/export/opt/matlab/r2008b/toolbox/control');
octave:2> addpath(P)
octave:3> s = tf('s')
error: inferiorto: precedence already set for tf and ss
error: called from:
error:   /export/opt/matlab/r2008b/toolbox/control/control/@tf/tf.m at line 83, column 1
octave:3>


  * Matlab 7.7.0.471 (R2008b) with Control System Toolbox version 8.2 (R2008b) gives this result:

>> s = tf('s')

Transfer function:
s

>>



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).

  I suppose that the error check of whether precedence already is set should be changed and accept the code in Matlab Control System Toolbox. Maybe the check should be to ascertain that both inferiorto and superiorto have the same meaning and that there is no contradiction.

Matlab's tf.m looks like this (line numbers first on the lines):
83: inferiorto('ss','zpk')
84: superiorto('double')
85: sys = struct('Variable',[]);

and Matlab's ss.m looks like this:
    superiorto('tf','zpk','double')
    inferiorto('frd')
    sys = struct;




Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Linux magic 2.6.27.25-0.1-pae #1 SMP 2009-07-01 15:37:09 +0200 i686 i686 i386 GNU/Linux
configure opts:   
Fortran compiler: gfortran
FFLAGS:           -O -mieee-fp
FLIBS:            -L/usr/lib/gcc/i586-suse-linux/4.3 -L/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/lib -L/usr/lib/gcc/i586-suse-linux/4.3/../../.. -lhdf5 -lz -lgfortranbegin -lgfortran -lm
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       gcc, version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) 
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,/usr/local/lib/octave-3.2.2
BLAS_LIBS:        -llapack -lcblas -lf77blas -latlas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lcblas -lf77blas -latlas -lhdf5 -lz -lm 
LEXLIB:           
LIBGLOB:          
SED:              /usr/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_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_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_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 = kwrite
  EXEC_PATH = /usr/local/libexec/octave/3.2.2/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.2/exec/i686-pc-linux-gnu:/usr/local/bin:/home/svabj/bin:/home/svabj/local/bin:/opt/kde3/bin:/home/svabj/bin:/home/svabj/local/bin:/usr/lib/mpi/gcc/openmpi/bin:/home/svabj/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/X11R6/bin:/usr/bin/X11:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/gnome/bin:/usr/lib/qt3/bin:/export/usr/local/bin:/export/usr/local/bin
  IMAGE_PATH = .:/home/svabj/export/src/octave-3.2.2/scripts/image
  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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/svabj/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = /export/home/svabj/src/octave-3.2.2/doc/interpreter/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 = <no value or error in displaying it>
  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 ntargr at yahoo.com  Tue Aug 18 19:09:28 2009
From: ntargr at yahoo.com (Giannis Ntarladimas)
Date: Tue, 18 Aug 2009 17:09:28 -0700 (PDT)
Subject: bugs in rsdec.m (comm toolbox)
Message-ID: <199704.22040.qm@web110311.mail.gq1.yahoo.com>

bugs in reed solomon decoder

1. For shorten codes (where n != 2^m-1, for example m=8, n=207 , k=187) CANNOT correct ANY error

2.MSG = rsdec (CODE,N,K,G) For full codes and G generated by rsgenpoly it returns the message:

>rsdec(noisycode,255,235,rsgenpoly(255,235,285,0))
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Segmentation fault







      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090818/e7ce6031/attachment.html 

From lhorner at siue.edu  Wed Aug 19 13:45:16 2009
From: lhorner at siue.edu (Lenore Horner)
Date: Wed, 19 Aug 2009 13:45:16 -0500
Subject: cannot compile
Message-ID: <01E043B1-EF04-4C9F-8CDD-722044CDB139@siue.edu>

Octave version 3.2.2 being installed through MacPorts version 1.710 on  
a PPC (G4) Mac with Xcode 3.1.2 installed.  Everything is being  
installed using Quartz and not X11.

Here's the basic error.

make -C liboctave all
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include lo-specfun.cc -o lo-specfun.o
lo-specfun.cc: In function 'Complex xlgamma(const Complex&)':
lo-specfun.cc:327: error: 'lgamma_r' was not declared in this scope
make[2]: *** [lo-specfun.o] Error 1
make[1]: *** [liboctave] Error 2
make: *** [all] Error 2

Error: Status 1 encountered during processing.


I've compiled twice now and gotten that message.

more output from first time:
--->  Fetching octave
--->  Attempting to fetch octave-3.2.2.tar.gz from http://distfiles.macports.org/octave
--->  Verifying checksum(s) for octave
--->  Extracting octave
--->  Configuring octave
--->  Building octave
Error: Target org.macports.build returned: shell command " cd "/opt/ 
local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_math_octave/work/octave-3.2.2" && make all  
" returned error 2
Command output: making DASSL.d from DASSL.cc
making DASRT.d from DASRT.cc
making DASPK.d from DASPK.cc
making CollocWt.d from CollocWt.cc
making oct-locbuf.d from oct-locbuf.cc
mkdir pic
touch stmp-pic
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include oct-locbuf.cc -o oct-locbuf.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include CollocWt.cc -o CollocWt.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include DASPK.cc -o DASPK.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include DASRT.cc -o DASRT.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include DASSL.cc -o DASSL.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include LSODE.cc -o LSODE.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include ODES.cc -o ODES.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include Quad.cc -o Quad.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include Range.cc -o Range.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include data-conv.cc -o data-conv.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include dir-ops.cc -o dir-ops.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include file-ops.cc -o file-ops.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include file-stat.cc -o file-stat.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include glob-match.cc -o glob-match.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include idx-vector.cc -o idx-vector.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include lo-ieee.cc -o lo-ieee.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include lo-mappers.cc -o lo-mappers.o
/opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include  
-I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../ 
liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W - 
Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 - 
I/opt/local/include lo-specfun.cc -o lo-specfun.o
lo-specfun.cc: In function 'Complex xlgamma(const Complex&)':
lo-specfun.cc:327: error: 'lgamma_r' was not declared in this scope
make[2]: *** [lo-specfun.o] Error 1
make[1]: *** [liboctave] Error 2
make: *** [all] Error 2

Error: Status 1 encountered during processing.



From relgire at gmail.com  Wed Aug 19 20:16:35 2009
From: relgire at gmail.com (E. Joshua Rigler)
Date: Wed, 19 Aug 2009 19:16:35 -0600
Subject: datestr.m strangeness
Message-ID: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>

Running a custom compilation of Octave on Redhat Enterprise 5
(64-bit), I get the following:

octave:207> datestr(datenum(2009, 8, 19, 17, 27, 45))
ans = 19-Aug-2009 18:27:45

Note that the hour given by datestr.m is one larger than what I passed
to datenum.m.? What's weirder, this anomaly seems tied to dates in
some confusing fashion.? For example, the following tests one minute
after midnight on both March 8 and 9 in 2009:

octave:210> datestr(datenum(2009, 3, 8, 0, 0, 1))
ans = 08-Mar-2009 00:00:01
octave:211> datestr(datenum(2009, 3, 9, 0, 0, 1))
ans = 09-Mar-2009 01:00:01

The following tests one minute after midnight on March 14th in both
2006 and 2007:

octave:220> datestr(datenum(2006, 3, 14, 0, 0, 1))
ans = 14-Mar-2006 00:00:01
octave:221> datestr(datenum(2007, 3, 14, 0, 0, 1))
ans = 14-Mar-2007 01:00:01

Finally, if one passes no sub-daily information to datenum.m, or sets
the hour, minute, and second to zero, datestr.m always returns what is
expected.  I did confirm that datenum.m is returning expected results,
as is datevec.m, but trying to understand the source code in
datestr.m, or worse, time.cc (for mktime and strftime functions), just
makes my head hurt.

Can anyone confirm this behavior, or is it unique to my system?  Let
me know if you need additional info.

-EJR


From ibmason at grapevine.com.au  Thu Aug 20 20:47:03 2009
From: ibmason at grapevine.com.au (Ian Mason)
Date: Fri, 21 Aug 2009 11:47:03 +1000
Subject: meshc contours appear above XY plane
Message-ID: <4A8DFC97.8060307@grapevine.com.au>

Bug report for Octave 3.2.0 configured for i686-pc-mingw32

Description:
-----------

  * Not sure if this is a bug or just something I don't know how to do...

Using following code to produce a 3D plot with contours, the contours 
appear above the XY plane, rather than on it:

# plot Gilbert's skill score (ETS) for s = 0.5
1;
tx = ty = linspace(0.0,1.0,50)';
[xx,yy] = meshgrid(tx,ty);
tz = (yy - xx)./(((1-0.5*yy)/0.5) + xx);
clf();
meshc(tx,ty,tz);
xlabel ("false alarm rate");
ylabel ("hit rate");
zlabel ("     GSS");
title ("Gilbert's skill score");



Repeat-By:
---------

  * Straightforward run of above code in Octave 3.2 on HP desktop with 
Pentium 4 512K RAM at 3.06 GHz on Windows XP Home.

Fix:
---

  * No suggestions. I'm aware of the set contour instruction in Gnuplot 
which looks as if it should do what I want but can't make it work with 
meshc. Any suggestions gratefully received. Otherwise I'm very impressed 
with Octave, Thank You!



Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Windows
configure opts:   
Fortran compiler: mingw32-gfortran-4.3.0-dw2
FFLAGS:           -O -mieee-fp
FLIBS:            -lgfortran
CPPFLAGS:         -march=i686 -mtune=generic -O2
INCFLAGS:         -I. -I/octaveforge_mingw32/octave/octave-3.2.0 -I. 
-I./liboctave -I./src -I./libcruft/misc 
-I/octaveforge_mingw32/octave/octave-3.2.0 
-I/octaveforge_mingw32/octave/octave-3.2.0/liboctave 
-I/octaveforge_mingw32/octave/octave-3.2.0/src 
-I/octaveforge_mingw32/octave/octave-3.2.0/libcruft/misc
C compiler:       mingw32-gcc-4.3.0-dw2, version4.3.0-dw2 (GCC TDM-2 for 
MinGW)
CFLAGS:           -Wall
CPICFLAG:         
C++ compiler:     mingw32-g++-4.3.0-dw2, version4.3.0-dw2
CXXFLAGS:         -D_DLL -Wall
CXXPICFLAG:       
LD_CXX:           mingw32-g++-4.3.0-dw2
LDFLAGS:          -shared-libgcc -Wl,--exclude-libs=-lstdc++_s 
-Wl,--allow-multiple-definition
LIBFLAGS:         -L.
RLD_FLAG:         
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -liberty -lblas -lhdf5 -lz -lm  
-lgdi32 -lws2_32 -luser32 -lkernel32
LEXLIB:           
LIBGLOB:          -lglob
SED:              /usr/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_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_GLPK_H=1 
-DHAVE_GLPK=1 -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 
-DHAVE_WINDOWS_H=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 -Duid_t=int 
-Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_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=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_ASSERT_H=1 
-DHAVE_CURSES_H=1 -DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1 -DHAVE_PTHREAD_H=1 
-DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1 
-DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1 
-DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 
-DHAVE_EXPM1F=1 -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 
-DHAVE_GETTIMEOFDAY=1 -DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 
-DHAVE_LOG1P=1 -DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 
-DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 
-DHAVE_ROUNDL=1 -DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 
-DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 
-DHAVE_STRICMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 
-DHAVE_TGAMMAF=1 -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 
-DHAVE_USLEEP=1 -DHAVE_UTIME=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 
-DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1 -DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 
-DHAVE_DECL_ROUND=1 -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 
-DHAVE_TGAMMA=1 -DHAVE_MKSTEMPS=1 -DHAVE_STRFTIME=1 
-DHAVE_C99_VSNPRINTF=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1 
-D_WIN32_WINNT=0x0403 -DHAVE_LOADLIBRARY_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_COPYSIGN=1 -DHAVE_SIGNBIT=1 -DHAVE__FINITE=1 
-DHAVE__ISNAN=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_RDEV=1 -DHAVE_DECL_TZNAME=1 -DHAVE_TZNAME=1 
-DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void 
-DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1 
-DRETSIGTYPE_IS_VOID=1


User-preferences (please do not edit this section):

  EDITOR = C:\Octave\3.2.0_gcc-4.3.0\tools\notepad++\notepad++.exe
  EXEC_PATH = 
C:\Octave\3.2.0_gcc-4.3.0\MINGW32\bin;C:\Octave\3.2.0_gcc-4.3.0\MSYS\bin;C:\Octave\3.2.0_gcc-4.3.0\libexec\octave\3.2.0\site\exec\i686-pc-mingw32;C:\Octave\3.2.0_gcc-4.3.0\libexec\octave\api-v37\site\exec\i686-pc-mingw32;C:\Octave\3.2.0_gcc-4.3.0\libexec\octave\site\exec\i686-pc-mingw32;C:\Octave\3.2.0_gcc-4.3.0\libexec\octave\3.2.0\exec\i686-pc-mingw32;C:\Octave\3.2.0_gcc-4.3.0\bin;C:\Program 
Files\MiKTeX 
2.7\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\Python22;C:\Program 
Files\PC-Doctor for Windows\;C:\Program 
Files\QuickTime\QTSystem\;;C:\PROGRA~1\COMMON~1\MUVEET~1\030625
  IMAGE_PATH = .;C:\Octave\3.2.0_gcc-4.3.0\share\octave\3.2.0\imagelib
  PAGER = C:\Octave\3.2.0_gcc-4.3.0\bin\less.exe
  PS1 = \#:
  PS2 = >
  PS4 = +
  beep_on_error = 0
  completion_append_char =  
  crash_dumps_octave_core = 1
  echo_executing_commands = 0
  fixed_point_format = 0
  gnuplot_binary = C:\Octave\3.2.0_gcc-4.3.0\bin\gnuplot.exe
# gnuplot_command_end = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = C:\Documents and Settings\HP_Owner.HP-A1140A\.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = C:\Octave\3.2.0_gcc-4.3.0\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 = <no value or error in displaying it>
  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 salman.bashir at hotmail.com  Thu Aug 20 14:30:35 2009
From: salman.bashir at hotmail.com (salman)
Date: Fri, 21 Aug 2009 01:30:35 +0600
Subject: bug
Message-ID: <BLU0-SMTP25C750C3138852611E3120FEFD0@phx.gbl>

Hi

Today, I tried the following function to read data in variable c from a
text file:

[c]=textread("filename.txt", "%*, %*, %f);

Upon this command, Octave gave following warning:

"warning broken pipe: some output may be lost"

regards
Salman


From salman.bashir at hotmail.com  Thu Aug 20 14:37:00 2009
From: salman.bashir at hotmail.com (salman)
Date: Fri, 21 Aug 2009 01:37:00 +0600
Subject: bug while reading textfile
Message-ID: <BLU0-SMTP99FE93C01D9C9D921CA66DFEFD0@phx.gbl>

Hi

Please ignore the earlier mail I sent to you regarding subject.

Today, I tried the following function to read data in variable c from a
text file:

[c]=textread("filename.txt", "%*, %*, %f);

When I tried to display contents of c, I got following warning


"warning: broken pipe: some output may be lost"

regards
Salman



From splaywriter at gmail.com  Fri Aug 21 08:31:48 2009
From: splaywriter at gmail.com (Jerry Bouman)
Date: Fri, 21 Aug 2009 08:31:48 -0500
Subject: Bug: 3.0.1 (and maybe beyond?): edit testFile.m destroys original 
	testFile.m
Message-ID: <4f48acb0908210631sb6943aeh7e43a29d0007d233@mail.gmail.com>

Bug: 3.0.1 (and maybe beyond?):  edit testFile.m destroys original testFile.m

Conditions: OS=XP, Octave v3.0.1
1. Open octave by double clicking on Octave desktop icon
2. Execute
> edit testFile.m
3. Add text to testFile.m and save. Verify that new file is saved to
HOME (\octave). New date-time stamp.
4. Execute
> exit
5. Open octave by double clicking on Octave desktop icon
6. Execute
> edit testFile.m
testFile.m created in step #3 has been destroyed and replaced with new
version. Verify that new file is saved to HOME (\octave). New
date-time stamp.

Note: The 'help edit' states that testFile.m should have been
"...edited in place."
> help edit

 If `edit' is called with the name of a file or function as its
 argument it will be opened in a text editor.

    * If the function NAME is available in a file on your path and
      that file is modifiable, then it will be edited in place.
      If it is a system function, then it will first be copied to
      the directory `HOME' (see further down) and then edited.

    * If NAME is the name of a function defined in the interpreter
      but not in an m-file, then an m-file will be created in
      `HOME' to contain that function along with its current
      definition.

Regards,
Jerry Bouman

p.s.
Good work on Octave. Great project.

From skwong at alumni.cuhk.net  Sat Aug 22 19:53:48 2009
From: skwong at alumni.cuhk.net (Saikee Wong)
Date: Sun, 23 Aug 2009 08:53:48 +0800 (HKT)
Subject: May be a bug in vol.m
Message-ID: <20090823005348.BB016C7761D@postfix.alumni.cuhk.net>

To: bug at octave.org
Cc: skwong, saikee at gmail.com, Friedrich.Leisch at ci.tuwien.ac.at
Subject: May be a bug in vol.m

Bug report for Octave 2.9.13 configured for i386-apple-darwin8.9.1

Description:
-----------

I'm studying the code of vol.m to learn details of volatility. By comparing
the article http://www.quantonline.co.za/documents/Volatility.pdf
I suspect there may be problem in vol.m

The vol.m file I have looking at is
/Applications/developer/octave/Octave.app/Contents/Resources/share/octave/2.9.13/m/finance/vol.m

Line 62 is
    U = U - ones (xr - 1, 1) * sum (U) / (xr - 1);

where the summation is the whole matrix, but I think it should only be m
elements in the matrix.

Secondly,   

Line 72 is
    retval = sqrt (retval * m / (n * m - 1));

I doubt why the retval need to be multply by m

Thanks for your attention.

B.rgds

SK

Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Darwin mbook.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
configure opts:   'CFLAGS=' 'CPPFLAGS=' 'CXXFLAGS=' 'LDFLAGS=' '--prefix=/tmp/dependencies-i386' '--enable-shared' '--with-f2c'
Fortran compiler: 
FFLAGS:           -O
F2C:              f2c
F2CFLAGS:         
FLIBS:            -lf2c
CPPFLAGS:         
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc 
C compiler:       gcc, version 4.0.1 (Apple Computer, Inc. build 5367)
CFLAGS:           
CPICFLAG:         
C++ compiler:     g++, version 4.0.1
CXXFLAGS:         
CXXPICFLAG:       
LD_CXX:           g++
LDFLAGS:          
LIBFLAGS:         -L.
RLD_FLAG:         
BLAS_LIBS:        -framework vecLib
FFTW_LIBS:        -lfftw3
LIBS:             -lreadline  -lncurses -lhdf5 -lz -lm 
LEXLIB:           
LIBDLFCN:         
LIBGLOB:          
SED:              /usr/local/bin/sed
DEFS:


User-preferences (please do not edit this section):
--------------------------------------------------

  EDITOR = emacs
  EXEC_PATH = /Applications/developer/octave/Octave.app/Contents/Resources/libexec/octave/2.9.13/site/exec/i386-apple-darwin8.9.1:/Applications/developer/octave/Octave.app/Contents/Resources/libexec/octave/api-v25/site/exec/i386-apple-darwin8.9.1:/Applications/developer/octave/Octave.app/Contents/Resources/libexec/octave/site/exec/i386-apple-darwin8.9.1:/Applications/developer/octave/Octave.app/Contents/Resources/libexec/octave/2.9.13/exec/i386-apple-darwin8.9.1:/Applications/developer/octave/Octave.app/Contents/Resources/bin:/Applications/developer/octave/Octave.app/Contents/Resources/bin:/usr/local/qt/bin:/sw/bin:/sw/sbin:/Users/skwong/bin:/sw/bin:/Users/skwong/bin:/Users/skwong/bin:/usr/local/texlive/2007/bin/i386-darwin/:/usr/X11R6/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/mysql/bin
  IMAGE_PATH = .:/Applications/developer/octave/Octave.app/Contents/Resources/share/octave/2.9.13/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 = /Users/skwong/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = /Applications/developer/octave/Octave.app/Contents/Resources/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

From muhali at shaw.ca  Sun Aug 23 22:14:56 2009
From: muhali at shaw.ca (Muhali)
Date: Sun, 23 Aug 2009 20:14:56 -0700 (PDT)
Subject: segfault with eig(x)
Message-ID: <25109927.post@talk.nabble.com>


I get a segfault when using eig(x), as follows:

octave:> whos x
Variables in the current scope:

  Attr Name        Size                     Bytes  Class
  ==== ====        ====                     =====  ===== 
       x         135x135                   291600  double

Total is 18225 elements using 291600 bytes

octave:> eig(x)
warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb25893f710 (LWP 4531)]
warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

Array<std::complex<double> >::operator= (this=warning: (Internal error: pc
0x7fb256e407a0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

0x7fffd04e9190, a=@0x0) at Array.cc:88
88	      rep = a.rep;
warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

Current language:  auto; currently c++
warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

(gdb) where
warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

#0  Array<std::complex<double> >::operator= (this=0x7fffd04e9190, a=@0x0) at
Array.cc:88
#1  0x00007fb24d2abc0e in EIG::operator= (this=0x7fffd04e9190, a=@0x0) at
../liboctave/MArray.h:62
#2  0x00007fb24d2aa97a in Feig (args=<value optimized out>, nargout=0) at
./DLD-FUNCTIONS/eig.cc:208
#3  0x00007fb257f7d257 in octave_builtin::do_multi_index_op (this=0xc59f48,
nargout=0, args=@0xd2fe60) at ov-builtin.cc:107
#4  0x00007fb257f7cbdb in octave_builtin::subsref (this=0xc59f48,
type=@0x7fffd04ea020, idx=@0x7fffd04ea000, nargout=0) at ov-builtin.cc:55
#5  0x00007fb257f33b30 in octave_value::subsref (this=<value optimized out>,
type=@0x21, idx=@0x0, nargout=13794720) at ov.cc:1061
#6  0x00007fb258052f1a in tree_index_expression::rvalue (this=0xd45910,
nargout=0) at pt-idx.cc:387
#7  0x00007fb25805084c in tree_index_expression::rvalue1 (this=0xd45910,
nargout=0) at pt-idx.cc:398
#8  0x00007fb258044834 in tree_evaluator::visit_statement
(this=0x7fb258851678, stmt=<value optimized out>) at pt-eval.cc:695
#9  0x00007fb258042dd3 in tree_evaluator::visit_statement_list
(this=0x7fb258851678, lst=@0x11ae400) at pt-eval.cc:731
#10 0x00007fb257e7205a in main_loop () at toplev.cc:572
#11 0x00007fb257e09fe5 in octave_main (argc=1, argv=0x7fffd04ea838,
embedded=0) at octave.cc:877
#12 0x00007fb252b275c6 in __libc_start_main () from /lib/libc.so.6
#13 0x0000000000400789 in _start () at ../sysdeps/x86_64/elf/start.S:113
warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
symtab.)

----------------------------------------------------------------------
GNU Octave Version 3.2.2
GNU Octave License: GNU General Public License
Operating System: Linux 2.6.30-1-amd64 #1 SMP Wed Jul 8 12:20:34 UTC 2009
x86_64

-- 
View this message in context: http://www.nabble.com/segfault-with-eig%28x%29-tp25109927p25109927.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From gbohanno at netscape.net  Sun Aug 23 16:20:14 2009
From: gbohanno at netscape.net (George Bohannon)
Date: Sun, 23 Aug 2009 17:20:14 -0400
Subject: Cannot compile octave-3.2.2 on RHEL5
Message-ID: <8CBF24EA3805A88-1068-8F46@webmail-dh24.sysops.aol.com>

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<char, std::char_traits<char> >::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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090823/8ae5a469/attachment-0001.html 

From hjunes at gmail.com  Mon Aug 24 05:07:22 2009
From: hjunes at gmail.com (Heikki Johannes Junes)
Date: Mon, 24 Aug 2009 13:07:22 +0300
Subject: PDF printing creates empty pages around the actual output
Message-ID: <33cf4bba0908240307ka0cf8y541d9287028f9ba0@mail.gmail.com>

PDF printing creates empty pages around the actual output.


Steps to reproduce:


plot(sin(0:0.1:10));

print(gcf,'test.pdf','-dpdf');


The generated PDF output has

 - empty page 1,

 - plot in page 2, and

 - empty page 3.


The empty pages should not be there.


This is the only bug that prevents me shifting from 3.0.5 to 3.2.2.


Heikki Junes





Bug report for Octave 3.2.2 configured for i686-pc-mingw32



Description:

-----------



  * Please replace this item with a detailed description of the

    problem.  Suggestions or general comments are also welcome.



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:     Windows

configure opts:

Fortran compiler: mingw32-gfortran-4.3.0-dw2

FFLAGS:           -O -mieee-fp

FLIBS:            -lgfortran

CPPFLAGS:         -march=i686 -mtune=generic -O2

INCFLAGS:         -I. -I/octmgw32/octave/octave-3.2.2 -I. -I./liboctave
-I./src -I./libcruft/misc -I/octmgw32/octave/octave-3.2.2
-I/octmgw32/octave/octave-3.2.2/liboctave
-I/octmgw32/octave/octave-3.2.2/src
-I/octmgw32/octave/octave-3.2.2/libcruft/misc

C compiler:       mingw32-gcc-4.3.0-dw2, version4.3.0-dw2 (GCC TDM-2 for
MinGW)

CFLAGS:           -Wall

CPICFLAG:

C++ compiler:     mingw32-g++-4.3.0-dw2, version4.3.0-dw2

CXXFLAGS:         -D_DLL -Wall

CXXPICFLAG:

LD_CXX:           mingw32-g++-4.3.0-dw2

LDFLAGS:          -shared-libgcc -Wl,--exclude-libs=-lstdc++_s
-Wl,--allow-multiple-definition

LIBFLAGS:         -L.

RLD_FLAG:

BLAS_LIBS:        -llapack -lblas

FFTW_LIBS:        -lfftw3 -lfftw3f

LIBS:             -lreadline  -lncurses -liberty -lblas -lhdf5 -lz -lm  -lgdi32
-lws2_32 -luser32 -lkernel32

LEXLIB:

LIBGLOB:          -lglob

SED:              /usr/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_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_GLPK_H=1 -DHAVE_GLPK=1
-DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_WINDOWS_H=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 -Duid_t=int
-Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_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=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_ASSERT_H=1 -DHAVE_CURSES_H=1
-DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1
-DHAVE_PTHREAD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1
-DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1
-DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1
-DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1
-DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE_GETTIMEOFDAY=1
-DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LOG1P=1
-DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_PUTENV=1
-DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1
-DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1
-DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1
-DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1
-DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1
-DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1
-DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1
-DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1
-DHAVE_MKSTEMPS=1 -DHAVE_C99_VSNPRINTF=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1
-D_WIN32_WINNT=0x0403 -DHAVE_LOADLIBRARY_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_COPYSIGN=1
-DHAVE_SIGNBIT=1 -DHAVE__FINITE=1 -DHAVE__ISNAN=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_RDEV=1 -DHAVE_DECL_TZNAME=1
-DHAVE_TZNAME=1 -DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void
-DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1
-DRETSIGTYPE_IS_VOID=1





User-preferences (please do not edit this section):



  EDITOR = C:\Program
Files\Octave\3.2.2_gcc-4.3.0\tools\notepad++\notepad++.exe

  EXEC_PATH = C:\Program Files\Octave\3.2.2_gcc-4.3.0\MINGW32\bin;C:\Program
Files\Octave\3.2.2_gcc-4.3.0\MSYS\bin;C:\Program
Files\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\site\exec\i686-pc-mingw32;C:\Program
Files\Octave\3.2.2_gcc-4.3.0\libexec\octave\api-v37\site\exec\i686-pc-mingw32;C:\Program
Files\Octave\3.2.2_gcc-4.3.0\libexec\octave\site\exec\i686-pc-mingw32;C:\Program
Files\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\exec\i686-pc-mingw32;C:\Program
Files\Octave\3.2.2_gcc-4.3.0\bin;C:\Program Files\PC Connectivity
Solution\;C:\Program Files\Business Objects\common\3.5\bin\NOTES\;C:\Program
Files\Business
Objects\common\3.5\bin\NOTES\DATA\;C:\oracle\product\11.1.0\client_1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Intel\WiFi\bin\;C:\Program Files\Windows Imaging\;C:\Program
Files\TortoiseHg;C:\Program Files\gs\gs8.64\bin

  IMAGE_PATH = .;C:\Program
Files\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\imagelib

  PAGER = C:\Program Files\Octave\3.2.2_gcc-4.3.0\bin\less.exe

  PS1 = \s:\#:\w

>

  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 = <no value or error in displaying it>

# gnuplot_command_plot = <no value or error in displaying it>

# gnuplot_command_replot = <no value or error in displaying it>

# gnuplot_command_splot = <no value or error in displaying it>

# gnuplot_command_title = <no value or error in displaying it>

# gnuplot_command_using = <no value or error in displaying it>

# gnuplot_command_with = <no value or error in displaying it>

  history_file = C:\Documents and Settings\h.junes\.octave_hist

  history_size = 1024

  ignore_function_time_stamp = system

  info_file = C:\Program Files\Octave\3.2.2_gcc-4.3.0\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 = <no value or error in displaying it>

  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090824/cb131442/attachment-0001.html 

From lindnerben at gmx.net  Mon Aug 24 14:45:36 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 24 Aug 2009 21:45:36 +0200
Subject: PDF printing creates empty pages around the actual output
In-Reply-To: <33cf4bba0908240307ka0cf8y541d9287028f9ba0@mail.gmail.com>
References: <33cf4bba0908240307ka0cf8y541d9287028f9ba0@mail.gmail.com>
Message-ID: <4A92EDE0.1010504@gmx.net>

Heikki Johannes Junes wrote:
> PDF printing creates empty pages around the actual output.
> Steps to reproduce:
> 
> plot(sin(0:0.1:10));
> print(gcf,'test.pdf','-dpdf');
> 
> The generated PDF output has
>  - empty page 1,
>  - plot in page 2, and
>  - empty page 3.
> 
> The empty pages should not be there.
> This is the only bug that prevents me shifting from 3.0.5 to 3.2.2.

This is a bug in gnuplot which is fixed in gnuplot's CVS but not yet in 
any released version.

I'm afraid this bug will have to wait until gnuplot releases a recent 
enough version which includes the fix for this.

I can't provide a at-least-a-bit-clean workaround at the moment.
I'll give it a try though and report back.

benjamin


From kelk1 at hotmail.com  Mon Aug 24 15:26:17 2009
From: kelk1 at hotmail.com (Quel Qun)
Date: Mon, 24 Aug 2009 13:26:17 -0700
Subject: auto sets axis scale too large
Message-ID: <BAY107-W390605C81DE17E1AEC21CDF7F90@phx.gbl>




_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_online:082009

From kelk1 at hotmail.com  Mon Aug 24 15:42:32 2009
From: kelk1 at hotmail.com (Eric)
Date: Mon, 24 Aug 2009 20:42:32 +0000 (UTC)
Subject: auto sets axis scale too =?utf-8?b?bGFyZ2XigI8=?=
Message-ID: <loom.20090824T223645-136@post.gmane.org>

Hi,

octave:1> a=0.001 : .001 : 0.017
octave:2> plot(a)

- On FC7, octave-2.9.9-2.fc7, gnuplot-4.0.0-19.fc7, the x axis is nicely set
from 0 to 18 and the y axis from 0 to 0.018.

- On FC11, octave-3.0.5-1.fc11.x86_64, gnuplot-4.2.4-6.fc11.x86_64, it seems
that axis("auto") is forced to axis("tight").

- On Mandriva cooker, octave-3.2.2-1mdv2010.0, gnuplot-4.2.5-1mdv2010.0, the x
axis is set from 0 to 20 and the y axis from 0 to 0.05. This is far too large.

This is quite an annoying regression. I tried to find similar reports but could
not find any. 

Is there a way to control how tight auto-scale is?

Thanks,
--
Eric





From godfrey at isl.stanford.edu  Mon Aug 24 17:51:01 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Mon, 24 Aug 2009 15:51:01 -0700
Subject: Another WWMTT item.
Message-ID: <4A931955.4020405@isl.stanford.edu>

I just noticed that in Matlab (7.7.0 R2008b)

get(gcf,  'Render')

works, even though they only list 'Renderer' as a property.
And, using 'Render' acts as if you had used 'Renderer'.
Obviously, there was a time in Matlab when...

In Octave (current hg source), 'Renderer' is accepted, but 'Render' is not.
So, for compatibility,  implement 'Render' to mean 'Renderer'.

Thanks,
Michael

From bpabbott at mac.com  Mon Aug 24 18:12:18 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Mon, 24 Aug 2009 19:12:18 -0400
Subject: Another WWMTT item.
In-Reply-To: <4A931955.4020405@isl.stanford.edu>
References: <4A931955.4020405@isl.stanford.edu>
Message-ID: <186E458A-0B77-4847-8DD2-9AE43930D2B4@mac.com>


On Aug 24, 2009, at 6:51 PM, Michael D. Godfrey wrote:

> I just noticed that in Matlab (7.7.0 R2008b)
>
> get(gcf,  'Render')
>
> works, even though they only list 'Renderer' as a property.
> And, using 'Render' acts as if you had used 'Renderer'.
> Obviously, there was a time in Matlab when...
>
> In Octave (current hg source), 'Renderer' is accepted, but 'Render'  
> is not.
> So, for compatibility,  implement 'Render' to mean 'Renderer'.
>
> Thanks,
> Michael

If I infer correctly the property name is matched by something like ..

fields = fieldnames (get (gcf));
field_idx = strncmpi (prop_name, fieldnames);
if (numel (field_idx) == 1)
   set (gcf, fields{field_idx}, prop_value);
else
   error ("Error  using set()")
endif

In the examples below the match is to "ScreenSize" and  
"ScreenPixelsPerInch"

 >> get(0,'screens')

ans =          1           1        1440         878

 >> get(0,'screenp')

ans =    90

Ben


From jwleblan at gmail.com  Mon Aug 24 18:13:12 2009
From: jwleblan at gmail.com (Joel LeBlanc)
Date: Mon, 24 Aug 2009 19:13:12 -0400
Subject: Another WWMTT item.
In-Reply-To: <4A931955.4020405@isl.stanford.edu>
References: <4A931955.4020405@isl.stanford.edu>
Message-ID: <34716c2e0908241613w1664bde4l5e319dab27d3005e@mail.gmail.com>

There doing overall completion checking.  This is less a bug than a feature
request.
For example get(0,'L'), get(0,'La'), ..., get(0,'Language') will all return
the same thing.

It appears that they do a case-insensitive search of beginning of the
string.  Furthermore, this is only happening on graphics objects (or some
such nonsense).  It is not a general language attribute.  For example:

t = struct('a',1,'at',2,'atttribute',3);
t.attri

I think you could pretty easily fix this in m-code by overloading the get
method for graphics objects.  I can't even reproduce it because of some OSX
compilation issues (see the recent tread with me complaining).

Hope that at least clarifies what's going on.  See strncmpi if your going to
try to fix it via overloading.

Cheers,

~Joel

On Mon, Aug 24, 2009 at 6:51 PM, Michael D. Godfrey <
godfrey at isl.stanford.edu> wrote:

> I just noticed that in Matlab (7.7.0 R2008b)
>
> get(gcf,  'Render')
>
> works, even though they only list 'Renderer' as a property.
> And, using 'Render' acts as if you had used 'Renderer'.
> Obviously, there was a time in Matlab when...
>
> In Octave (current hg source), 'Renderer' is accepted, but 'Render' is not.
> So, for compatibility,  implement 'Render' to mean 'Renderer'.
>
> Thanks,
> 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/20090824/a16c5b7c/attachment.html 

From bpabbott at mac.com  Mon Aug 24 18:14:37 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Mon, 24 Aug 2009 19:14:37 -0400
Subject: cannot compile
In-Reply-To: <517B406E-B9F5-41F0-ADC7-8D5EBFB18C8E@siue.edu>
References: <01E043B1-EF04-4C9F-8CDD-722044CDB139@siue.edu>
	<ABB3C02A-BBE6-4C09-9A2D-E856FA2D8CF0@mac.com>
	<517B406E-B9F5-41F0-ADC7-8D5EBFB18C8E@siue.edu>
Message-ID: <25E57096-7C05-4A9B-99D8-471C32A4203C@mac.com>

On Aug 24, 2009, at 7:05 PM, Lenore Horner wrote:

>
> On Aug 24, 2009, at 13:06 , Ben Abbott wrote:
>
>>
>> On Aug 19, 2009, at 2:45 PM, Lenore Horner wrote:
>>
>>> Octave version 3.2.2 being installed through MacPorts version  
>>> 1.710 on
>>> a PPC (G4) Mac with Xcode 3.1.2 installed.  Everything is being
>>> installed using Quartz and not X11.
>>>
>>> Here's the basic error.
>>>
>>> make -C liboctave all
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include lo-specfun.cc -o lo-specfun.o
>>> lo-specfun.cc: In function 'Complex xlgamma(const Complex&)':
>>> lo-specfun.cc:327: error: 'lgamma_r' was not declared in this scope
>>> make[2]: *** [lo-specfun.o] Error 1
>>> make[1]: *** [liboctave] Error 2
>>> make: *** [all] Error 2
>>>
>>> Error: Status 1 encountered during processing.
>>>
>>>
>>> I've compiled twice now and gotten that message.
>>>
>>> more output from first time:
>>> --->  Fetching octave
>>> --->  Attempting to fetch octave-3.2.2.tar.gz from http://distfiles.macports.org/octave
>>> --->  Verifying checksum(s) for octave
>>> --->  Extracting octave
>>> --->  Configuring octave
>>> --->  Building octave
>>> Error: Target org.macports.build returned: shell command " cd "/opt/
>>> local/var/macports/build/
>>> _opt_local_var_macports_sources_rsync
>>> .macports.org_release_ports_math_octave/work/octave-3.2.2" && make  
>>> all
>>> " returned error 2
>>> Command output: making DASSL.d from DASSL.cc
>>> making DASRT.d from DASRT.cc
>>> making DASPK.d from DASPK.cc
>>> making CollocWt.d from CollocWt.cc
>>> making oct-locbuf.d from oct-locbuf.cc
>>> mkdir pic
>>> touch stmp-pic
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include oct-locbuf.cc -o oct-locbuf.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include CollocWt.cc -o CollocWt.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include DASPK.cc -o DASPK.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include DASRT.cc -o DASRT.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include DASSL.cc -o DASSL.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include LSODE.cc -o LSODE.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include ODES.cc -o ODES.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include Quad.cc -o Quad.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include Range.cc -o Range.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include data-conv.cc -o data-conv.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include dir-ops.cc -o dir-ops.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include file-ops.cc -o file-ops.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include file-stat.cc -o file-stat.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include glob-match.cc -o glob-match.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include idx-vector.cc -o idx-vector.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include lo-ieee.cc -o lo-ieee.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include lo-mappers.cc -o lo-mappers.o
>>> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/ 
>>> include
>>> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
>>> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
>>> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/ 
>>> freetype2 -
>>> I/opt/local/include lo-specfun.cc -o lo-specfun.o
>>> lo-specfun.cc: In function 'Complex xlgamma(const Complex&)':
>>> lo-specfun.cc:327: error: 'lgamma_r' was not declared in this scope
>>> make[2]: *** [lo-specfun.o] Error 1
>>> make[1]: *** [liboctave] Error 2
>>> make: *** [all] Error 2
>>>
>>> Error: Status 1 encountered during processing.
>>
>> Lenore,
>>
>> I apologize for giving  you the run around, but as the problem  
>> appears to be with MacPorts "port" of Octave, I suggest you report  
>> the problem to them
>>
>> Ben
>>
> Thanks Ben.  I had already done so, though nothing is happening  
> there.  Can you tell me what makes you think it's the port and not  
> octave itself?  I thought that this looked more like an octave  
> problem.  If it complained of a missing library, I'd expect it to be  
> a port problem.  What am I missing?
>
> Thanks,
> Lenore

Octave 3.2.2 builds for many others on Mac OSX (including me).  So I  
assume it is a problem specific to MacPorts.

Ben



From jwleblan at gmail.com  Mon Aug 24 18:21:06 2009
From: jwleblan at gmail.com (Joel LeBlanc)
Date: Mon, 24 Aug 2009 19:21:06 -0400
Subject: Another WWMTT item.
In-Reply-To: <186E458A-0B77-4847-8DD2-9AE43930D2B4@mac.com>
References: <4A931955.4020405@isl.stanford.edu>
	<186E458A-0B77-4847-8DD2-9AE43930D2B4@mac.com>
Message-ID: <34716c2e0908241621qe3bf1d3qaa6e49ca3432cb00@mail.gmail.com>

Yep, except the the "if" statement is broken out like this... (assume get is
being called on graphics object obj)
switch field_idx
case 0
    error('There is no ''%s' in the ''%s'' class.', prop_val, class(obj);
case 1
    result = obj.(fields{field_idx});
otherwise
    error('Ambiguous %s property: ''%s''.', class(obj), prop_val);
end

Cheers,

~Joel

On Mon, Aug 24, 2009 at 7:12 PM, Ben Abbott <bpabbott at mac.com> wrote:

>
> On Aug 24, 2009, at 6:51 PM, Michael D. Godfrey wrote:
>
> > I just noticed that in Matlab (7.7.0 R2008b)
> >
> > get(gcf,  'Render')
> >
> > works, even though they only list 'Renderer' as a property.
> > And, using 'Render' acts as if you had used 'Renderer'.
> > Obviously, there was a time in Matlab when...
> >
> > In Octave (current hg source), 'Renderer' is accepted, but 'Render'
> > is not.
> > So, for compatibility,  implement 'Render' to mean 'Renderer'.
> >
> > Thanks,
> > Michael
>
> If I infer correctly the property name is matched by something like ..
>
> fields = fieldnames (get (gcf));
> field_idx = strncmpi (prop_name, fieldnames);
> if (numel (field_idx) == 1)
>   set (gcf, fields{field_idx}, prop_value);
> else
>   error ("Error  using set()")
> endif
>
> In the examples below the match is to "ScreenSize" and
> "ScreenPixelsPerInch"
>
>  >> get(0,'screens')
>
> ans =          1           1        1440         878
>
>  >> get(0,'screenp')
>
> ans =    90
>
> Ben
>
> _______________________________________________
> 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/20090824/42e3cee4/attachment.html 

From jwleblan at gmail.com  Mon Aug 24 18:54:16 2009
From: jwleblan at gmail.com (Joel LeBlanc)
Date: Mon, 24 Aug 2009 19:54:16 -0400
Subject: warning silently passes invalid identifiers
Message-ID: <34716c2e0908241654n29b13c80vd00ca2d2e22e30fc@mail.gmail.com>

The warning function silently passes invalid warning_ids.  For example
warning('off','divide-by-zero')

I am working with octave 3.0.5 ... compilation issues  : (

Cheers,

~Joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090824/4da5e66c/attachment.html 

From rob at utk.edu  Mon Aug 24 19:30:46 2009
From: rob at utk.edu (Rob Mahurin)
Date: Mon, 24 Aug 2009 20:30:46 -0400
Subject: cannot compile
In-Reply-To: <01E043B1-EF04-4C9F-8CDD-722044CDB139@siue.edu>
References: <01E043B1-EF04-4C9F-8CDD-722044CDB139@siue.edu>
Message-ID: <7C20BAA3-9C5E-4132-B489-1A1F014CC42D@utk.edu>

On Aug 19, 2009, at 2:45 PM, Lenore Horner wrote:
> Octave version 3.2.2 being installed through MacPorts version 1.710 on
> a PPC (G4) Mac with Xcode 3.1.2 installed.  Everything is being
> installed using Quartz and not X11.
>
> Here's the basic error.
>
> make -C liboctave all
> /opt/local/bin/g++-mp-4.3 -c -I/opt/local/include -I/opt/local/include
> -I/opt/local/include/freetype2 -I/opt/local/include -I. -I.. -I../
> liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H  -Wall -W -
> Wshadow -Wold-style-cast -Wformat -O2 -I/opt/local/include/freetype2 -
> I/opt/local/include lo-specfun.cc -o lo-specfun.o
> lo-specfun.cc: In function 'Complex xlgamma(const Complex&)':
> lo-specfun.cc:327: error: 'lgamma_r' was not declared in this scope
> make[2]: *** [lo-specfun.o] Error 1
> make[1]: *** [liboctave] Error 2
> make: *** [all] Error 2


How does macports call configure?

I dimly remember seeing something like this on my 10.5 mac (which I  
can't currently access).  It took several tries to get common  
versions of gcc and gfortran and the right flags.  You might need  
FFLAGS=-ff2c.

I use macports for dependencies but I don't know how to tweak its  
build options.

Rob

-- 
Rob Mahurin
University of Manitoba, Dept. of Physics & Astronomy
at:	Oak Ridge National Laboratory	865 207 2594
	Oak Ridge, Tennessee		rob at utk.edu


From godfrey at isl.stanford.edu  Mon Aug 24 21:28:30 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Mon, 24 Aug 2009 19:28:30 -0700
Subject: Information about Matlab try; ... catch;
Message-ID: <4A934C4E.3070101@isl.stanford.edu>

Compatibility problems with: try; ... catch; ... end:

This is beyond the strictest "Matlab compatibility"
rule.  But, it can cause trouble.  There are a number
of differences between Matlab (7.7.0 R2208b) and the
current Octave development system for try; catch;.

First, the Matlab problem:

There are 2 scripts attached.  outer.m is the one to run.
It references inner_try.m.  Lines 5 and 6 of inner_try.m show the
Matlab problem.  If line 6 is used and line 5 commented out
Matlab does not show an error.  It runs as if the line
were correct (or as if GAmouse was defined).  Octave handles
this correctly: an error is raised and caught by outer.m.
(In the original code there was no disp(lasterr) in the
catch; end; so Octave just exited for no apparent reason.
Matlab ran OK.)

The only thing that I can think of to do about this (other
than an error report to the Mathworks...) is to somewhere
document this as Matlab behavior that is not compatible with
Octave.

Next, other differences:

1. In outer.m, Matlab will not allow the printf statement
    after the catch;  (line 19)

2. Even more odd, Matlab will not allow the printf statement at
    line 14 of outer.m.  With that line NOT commented Matlab says:
=======================================================
As we draw things, we will list the corresponding graphics
commands on lines starting with ' >> '

  >> printf
Undefined function or method 'printf' for input arguments of type 'char'.
 >>
========================================================
As a separate comment, this code was in with an interesting package
that does Geometric Algebra (called GABLE).  This package makes lots
of use of classes.  The code itself appears to work correctly in
the current Octave.

Michael
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: inner_try.m
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090824/147b0327/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: outer.m
Url: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090824/147b0327/attachment-0001.ksh 

From highegg at gmail.com  Tue Aug 25 01:05:56 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 08:05:56 +0200
Subject: Least squares problem
In-Reply-To: <4A8BC19B.1010900@foi.se>
References: <4A8BC19B.1010900@foi.se>
Message-ID: <69d8d540908242305w466d2e2bp456155adb63a004e@mail.gmail.com>

2009/8/19 "Svante Bj?rklund, FOI" <svabj at foi.se>:
> To: bug at octave.org
> Cc: svabj at foi.se
> Subject: Least squares problem
> --------
> Bug report for Octave 3.2.0 configured for i686-suse-linux-gnu
>
> Description:
> -----------
>
> ?* Please replace this item with a detailed description of the
> ? ?problem. ?Suggestions or general comments are also welcome.
>
> When trying to solve a linear least squares problem with "Q = U2\U1" a
> Fortran routine returns an error message. The Fortran routine apparently
> is given incorrect input. See the code below. I attach a MAT file with
> U1 and U2 which cause the problem.
>

As you probably expected, these data don't cause any problems for me.
Exceptions in LAPACK are usually caused by improper linking to
BLAS/LAPACK. Maybe something is wrong with the distro package.

> I have also tried with Octave 3.2.2, which I have compiled by myself.
> Then I got "panic: Illegal instruction -- stopping myself..." as I also
> get in other cases. See my bug report with subject "Illegal instruction
> graphics".

OK.


> I use OpenSuse Linux 11.1. Octave 3.2.0 I have downloaded and installed
> as an RPM from an OpenSuse repository.
>

Then maybe you could also report the problem to OpenSUSE.

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 Aug 25 01:09:47 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 08:09:47 +0200
Subject: bug while reading textfile
In-Reply-To: <BLU0-SMTP99FE93C01D9C9D921CA66DFEFD0@phx.gbl>
References: <BLU0-SMTP99FE93C01D9C9D921CA66DFEFD0@phx.gbl>
Message-ID: <69d8d540908242309m3cdb8cb6g14e3b47d1d9d205f@mail.gmail.com>

On Thu, Aug 20, 2009 at 9:37 PM, salman<salman.bashir at hotmail.com> wrote:
> Hi
>
> Please ignore the earlier mail I sent to you regarding subject.
>
> Today, I tried the following function to read data in variable c from a
> text file:
>
> [c]=textread("filename.txt", "%*, %*, %f);
>
> When I tried to display contents of c, I got following warning
>
>
> "warning: broken pipe: some output may be lost"
>
> regards
> Salman
>
>

That is most likely no bug. Octave tries to send larger outputs
through the pager (usually it's "less" or "more"), and it just warns
you if you quit the pager before it receives all the data (which of
course you often want to, but I don't think there's anything wrong
about the warning).

hth

-- 
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 Aug 25 01:33:14 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 08:33:14 +0200
Subject: datestr.m strangeness
In-Reply-To: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>
References: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>
Message-ID: <69d8d540908242333q7367d9a1jdff6c4a9aec7011d@mail.gmail.com>

On Thu, Aug 20, 2009 at 3:16 AM, E. Joshua Rigler<relgire at gmail.com> wrote:
> Running a custom compilation of Octave on Redhat Enterprise 5
> (64-bit), I get the following:
>
> octave:207> datestr(datenum(2009, 8, 19, 17, 27, 45))
> ans = 19-Aug-2009 18:27:45
>
> Note that the hour given by datestr.m is one larger than what I passed
> to datenum.m.? What's weirder, this anomaly seems tied to dates in
> some confusing fashion.? For example, the following tests one minute
> after midnight on both March 8 and 9 in 2009:
>
> octave:210> datestr(datenum(2009, 3, 8, 0, 0, 1))
> ans = 08-Mar-2009 00:00:01
> octave:211> datestr(datenum(2009, 3, 9, 0, 0, 1))
> ans = 09-Mar-2009 01:00:01
>
> The following tests one minute after midnight on March 14th in both
> 2006 and 2007:
>
> octave:220> datestr(datenum(2006, 3, 14, 0, 0, 1))
> ans = 14-Mar-2006 00:00:01
> octave:221> datestr(datenum(2007, 3, 14, 0, 0, 1))
> ans = 14-Mar-2007 01:00:01
>
> Finally, if one passes no sub-daily information to datenum.m, or sets
> the hour, minute, and second to zero, datestr.m always returns what is
> expected. ?I did confirm that datenum.m is returning expected results,
> as is datevec.m, but trying to understand the source code in
> datestr.m, or worse, time.cc (for mktime and strftime functions), just
> makes my head hurt.
>
> Can anyone confirm this behavior, or is it unique to my system? ?Let
> me know if you need additional info.
>
> -EJR
>

At this point it's just guessing, but I think this is because datenum
ignores summer time (it's just plain linear date) whereas datestr uses
localtime, which attempts to account for time zone, and summer time.
The rules for switching to summer time are obscure (at least in my
country) - typically it's the first Sunday after equinox.
I suggest you try whether this explains your results - when moving
through the year, you should see exactly two jumps, one forward and
one backward. I can't tell, however, what behavior is Matlab
compatible.

-- 
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 Aug 25 01:37:14 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 08:37:14 +0200
Subject: segfault with eig(x)
In-Reply-To: <25109927.post@talk.nabble.com>
References: <25109927.post@talk.nabble.com>
Message-ID: <69d8d540908242337j20c40066va287ac618682d1be@mail.gmail.com>

On Mon, Aug 24, 2009 at 5:14 AM, Muhali<muhali at shaw.ca> wrote:
>
> I get a segfault when using eig(x), as follows:
>
> octave:> whos x
> Variables in the current scope:
>
> ?Attr Name ? ? ? ?Size ? ? ? ? ? ? ? ? ? ? Bytes ?Class
> ?==== ==== ? ? ? ?==== ? ? ? ? ? ? ? ? ? ? ===== ?=====
> ? ? ? x ? ? ? ? 135x135 ? ? ? ? ? ? ? ? ? 291600 ?double
>
> Total is 18225 elements using 291600 bytes
>
> octave:> eig(x)
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fb25893f710 (LWP 4531)]
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> Array<std::complex<double> >::operator= (this=warning: (Internal error: pc
> 0x7fb256e407a0 in read in psymtab, but not in symtab.)
>
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> 0x7fffd04e9190, a=@0x0) at Array.cc:88
> 88 ? ? ? ? ? ?rep = a.rep;
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> Current language: ?auto; currently c++
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> (gdb) where
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> #0 ?Array<std::complex<double> >::operator= (this=0x7fffd04e9190, a=@0x0) at
> Array.cc:88
> #1 ?0x00007fb24d2abc0e in EIG::operator= (this=0x7fffd04e9190, a=@0x0) at
> ../liboctave/MArray.h:62
> #2 ?0x00007fb24d2aa97a in Feig (args=<value optimized out>, nargout=0) at
> ./DLD-FUNCTIONS/eig.cc:208
> #3 ?0x00007fb257f7d257 in octave_builtin::do_multi_index_op (this=0xc59f48,
> nargout=0, args=@0xd2fe60) at ov-builtin.cc:107
> #4 ?0x00007fb257f7cbdb in octave_builtin::subsref (this=0xc59f48,
> type=@0x7fffd04ea020, idx=@0x7fffd04ea000, nargout=0) at ov-builtin.cc:55
> #5 ?0x00007fb257f33b30 in octave_value::subsref (this=<value optimized out>,
> type=@0x21, idx=@0x0, nargout=13794720) at ov.cc:1061
> #6 ?0x00007fb258052f1a in tree_index_expression::rvalue (this=0xd45910,
> nargout=0) at pt-idx.cc:387
> #7 ?0x00007fb25805084c in tree_index_expression::rvalue1 (this=0xd45910,
> nargout=0) at pt-idx.cc:398
> #8 ?0x00007fb258044834 in tree_evaluator::visit_statement
> (this=0x7fb258851678, stmt=<value optimized out>) at pt-eval.cc:695
> #9 ?0x00007fb258042dd3 in tree_evaluator::visit_statement_list
> (this=0x7fb258851678, lst=@0x11ae400) at pt-eval.cc:731
> #10 0x00007fb257e7205a in main_loop () at toplev.cc:572
> #11 0x00007fb257e09fe5 in octave_main (argc=1, argv=0x7fffd04ea838,
> embedded=0) at octave.cc:877
> #12 0x00007fb252b275c6 in __libc_start_main () from /lib/libc.so.6
> #13 0x0000000000400789 in _start () at ../sysdeps/x86_64/elf/start.S:113
> warning: (Internal error: pc 0x7fb256e407cf in read in psymtab, but not in
> symtab.)
>
> ----------------------------------------------------------------------
> GNU Octave Version 3.2.2
> GNU Octave License: GNU General Public License
> Operating System: Linux 2.6.30-1-amd64 #1 SMP Wed Jul 8 12:20:34 UTC 2009
> x86_64
>

A miscompilation, most likely. If you compiled Octave yourself, you'll
need to share the config info to get any further help.
Also, please read the manual on how to submit a useful bug report.

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 Aug 25 01:41:56 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 08:41:56 +0200
Subject: Bug: 3.0.1 (and maybe beyond?): edit testFile.m destroys original
	testFile.m
In-Reply-To: <4f48acb0908210631sb6943aeh7e43a29d0007d233@mail.gmail.com>
References: <4f48acb0908210631sb6943aeh7e43a29d0007d233@mail.gmail.com>
Message-ID: <69d8d540908242341m474e227ekffe5ee493420edfb@mail.gmail.com>

On Fri, Aug 21, 2009 at 3:31 PM, Jerry Bouman<splaywriter at gmail.com> wrote:
> Bug: 3.0.1 (and maybe beyond?): ?edit testFile.m destroys original testFile.m
>
> Conditions: OS=XP, Octave v3.0.1
> 1. Open octave by double clicking on Octave desktop icon
> 2. Execute
>> edit testFile.m
> 3. Add text to testFile.m and save. Verify that new file is saved to
> HOME (\octave). New date-time stamp.
> 4. Execute
>> exit
> 5. Open octave by double clicking on Octave desktop icon
> 6. Execute
>> edit testFile.m
> testFile.m created in step #3 has been destroyed and replaced with new
> version. Verify that new file is saved to HOME (\octave). New
> date-time stamp.
>
> Note: The 'help edit' states that testFile.m should have been
> "...edited in place."
>> help edit
>
> ?If `edit' is called with the name of a file or function as its
> ?argument it will be opened in a text editor.
>
> ? ?* If the function NAME is available in a file on your path and
> ? ? ?that file is modifiable, then it will be edited in place.
> ? ? ?If it is a system function, then it will first be copied to
> ? ? ?the directory `HOME' (see further down) and then edited.
>
> ? ?* If NAME is the name of a function defined in the interpreter
> ? ? ?but not in an m-file, then an m-file will be created in
> ? ? ?`HOME' to contain that function along with its current
> ? ? ?definition.
>
> Regards,
> Jerry Bouman
>
> p.s.
> Good work on Octave. Great project.
> _______________________________________________

Does not seem to happen for me. Please verify that $HOME/octave is on
your path. Does the new version really execute at points 4. and 6. in
your above list? Anyway, I'd suggest an upgrade.

hth

-- 
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 Aug 25 02:27:33 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 09:27:33 +0200
Subject: warning silently passes invalid identifiers
In-Reply-To: <34716c2e0908241654n29b13c80vd00ca2d2e22e30fc@mail.gmail.com>
References: <34716c2e0908241654n29b13c80vd00ca2d2e22e30fc@mail.gmail.com>
Message-ID: <69d8d540908250027p2eac06dfm9f62036581d757ad@mail.gmail.com>

On Tue, Aug 25, 2009 at 1:54 AM, Joel LeBlanc<jwleblan at gmail.com> wrote:
> The warning function silently passes invalid warning_ids. ?For example
> warning('off','divide-by-zero')
> I am working with octave 3.0.5 ... compilation issues ?: (
> Cheers,
> ~Joel

And what should it do? I always thought user warning ids are meant to
be supported.

-- 
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 Aug 25 02:35:34 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 09:35:34 +0200
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: <69d8d540908250035k4fc2495v48e7fcb5665273bb@mail.gmail.com>

On Sun, Aug 23, 2009 at 11:20 PM, George Bohannon<gbohanno at netscape.net> 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<char,
> std::char_traits<char> >::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
>

The fact that you use gcc 4.1.2 yet the link command above contains
references to gcc 3.4.6 runtime is highly suspicious. Probably you're
linking the wrong C++ runtime library.in. Is the configuration below
really from your new build? What about the RLD_FLAG pointing to 3.0.1?


>
> 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:
>



-- 
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 Aug 25 02:46:33 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 09:46:33 +0200
Subject: Information about Matlab try; ... catch;
In-Reply-To: <4A934C4E.3070101@isl.stanford.edu>
References: <4A934C4E.3070101@isl.stanford.edu>
Message-ID: <69d8d540908250046v5b19d05cud9c236d51544d24d@mail.gmail.com>

On Tue, Aug 25, 2009 at 4:28 AM, Michael D
Godfrey<godfrey at isl.stanford.edu> wrote:
> Compatibility problems with: try; ... catch; ... end:
>
> This is beyond the strictest "Matlab compatibility"
> rule. ?But, it can cause trouble. ?There are a number
> of differences between Matlab (7.7.0 R2208b) and the
> current Octave development system for try; catch;.
>
> First, the Matlab problem:
>
> There are 2 scripts attached. ?outer.m is the one to run.
> It references inner_try.m. ?Lines 5 and 6 of inner_try.m show the
> Matlab problem. ?If line 6 is used and line 5 commented out
> Matlab does not show an error. ?It runs as if the line
> were correct (or as if GAmouse was defined). ?Octave handles
> this correctly: an error is raised and caught by outer.m.
> (In the original code there was no disp(lasterr) in the
> catch; end; so Octave just exited for no apparent reason.
> Matlab ran OK.)
>

This is the now famous short-circuiting behavior of element-wise
logical operators. In Matlab, they short-circuit in if clauses, and
not elsewhere. This has been discussed mutliple times and the general
agreement is that it was bad design decision and Octave needs not copy
it. Just use && (which I'd recommend in Matlab as well).

> The only thing that I can think of to do about this (other
> than an error report to the Mathworks...) is to somewhere
> document this as Matlab behavior that is not compatible with
> Octave.
>

I believe it is documented somewhere, but I may be wrong.

> Next, other differences:
>
> 1. In outer.m, Matlab will not allow the printf statement
> ? after the catch; ?(line 19)
>
> 2. Even more odd, Matlab will not allow the printf statement at
> ? line 14 of outer.m. ?With that line NOT commented Matlab says:
> =======================================================
> As we draw things, we will list the corresponding graphics
> commands on lines starting with ' >> '
>
> ?>> printf
> Undefined function or method 'printf' for input arguments of type 'char'.
>>>

Huh? Probably a bug in Matlab, then.

> ========================================================
> As a separate comment, this code was in with an interesting package
> that does Geometric Algebra (called GABLE). ?This package makes lots
> of use of classes. ?The code itself appears to work correctly in
> the current Octave.
>
> Michael
>

That's cool :) Though I have but a dim understanding what "Geometric
Algebra" is about.

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 Aug 25 03:27:42 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 10:27:42 +0200
Subject: imgwrite/imfinfo fail in octave 3.2.x
In-Reply-To: <4A8956B2.4040500@gmx.net>
References: <20090817103626.30974.qmail@web3808.mail.bbt.yahoo.co.jp>
	<4A8936CC.7050307@gmx.net> <4A8956B2.4040500@gmx.net>
Message-ID: <69d8d540908250127v4997d279p7f575d9465439cd4@mail.gmail.com>

On Mon, Aug 17, 2009 at 3:10 PM, Benjamin Lindner<lindnerben at gmx.net> wrote:
> Benjamin Lindner wrote:
>>>> Hello,
>>>>
>>>> I am building a 3.2.2 mingw32 binary and during testing I get the
>>>> following error when calling imwrite.
>>>>
>>>> octave.exe:1> a = uint16([12340,12341,12342]);
>>>> octave.exe:2> imwrite("test16.tif", a);
>> ? ? ? ? ? ? ? ? ? ^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> this should read of course
>> octave.exe:2> imwrite(a, "test16.tif");
>>
>>>> error: `__magick_write__' undefined near line 124 column 7
>>>> error: called from:
>>>> error:
>>>>
>>> D:\build\octave32\3.2.x\msys\opt\octave_mingw32_gcc-4.3.0-dw2\3.2.x-3\share\octave\3.2.2\m\image\imwrite.m
>>>> at line 124, column 7
>>>>
>
> The problem is the following changeset
> http://hg.tw-math.de/release-3-2-x/rev/44300eb51817
> which changes the names of the DLD functions in __magick_read__.cc but
> does not appropriately change the function names in the scripts where
> they are called.
> It changes, however, in imread.m the call to __magick_read__ into a call
> to magick_read_internal, which seems wrong.
>
> Now on the development branch, the unintended changes were undone by the
> two changesets
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/3ca88e72f0e8
> http://hg.savannah.gnu.org/hgweb/octave/rev/5302df15ad76
>
> So these two should also be transplanted to the 3.2.x branch!
>
> benjamin
>

Transplanted. Please CC me when a conclusion like this for 3.2.x is
reached in a message.

thanks

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From jwleblan at gmail.com  Tue Aug 25 07:27:14 2009
From: jwleblan at gmail.com (Joel LeBlanc)
Date: Tue, 25 Aug 2009 08:27:14 -0400
Subject: warning silently passes invalid identifiers
In-Reply-To: <69d8d540908250027p2eac06dfm9f62036581d757ad@mail.gmail.com>
References: <34716c2e0908241654n29b13c80vd00ca2d2e22e30fc@mail.gmail.com>
	<69d8d540908250027p2eac06dfm9f62036581d757ad@mail.gmail.com>
Message-ID: <34716c2e0908250527p56fc5b5elf30e67fbdcee0e48@mail.gmail.com>

Now I don't know.  I think what Matlab is doing is checking for
<this>:<that> type syntax in the warning identifier.  So
warning('query','this:that')

works fine while

warning('query','Thisthat')

throws an error.  (Unknown setting or incorrect message identifier
'thisthat').  This makes no sense to me, so I'd say octave is actually doing
it better than Matlab right now.  I don't see any benefit to enforcing this
type of syntax.

Thanks for the feedback, and sorry I missed that.

~Joel

On Tue, Aug 25, 2009 at 3:27 AM, Jaroslav Hajek <highegg at gmail.com> wrote:

> On Tue, Aug 25, 2009 at 1:54 AM, Joel LeBlanc<jwleblan at gmail.com> wrote:
> > The warning function silently passes invalid warning_ids.  For example
> > warning('off','divide-by-zero')
> > I am working with octave 3.0.5 ... compilation issues  : (
> > Cheers,
> > ~Joel
>
> And what should it do? I always thought user warning ids are meant to
> be supported.
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090825/fd2229c1/attachment-0001.html 

From dbateman at free.fr  Tue Aug 25 10:07:29 2009
From: dbateman at free.fr (dbateman)
Date: Tue, 25 Aug 2009 08:07:29 -0700 (PDT)
Subject: Information about Matlab try; ... catch;
In-Reply-To: <69d8d540908250046v5b19d05cud9c236d51544d24d@mail.gmail.com>
References: <4A934C4E.3070101@isl.stanford.edu>
	<69d8d540908250046v5b19d05cud9c236d51544d24d@mail.gmail.com>
Message-ID: <25136223.post@talk.nabble.com>




Jaroslav Hajek-2 wrote:
> 
> On Tue, Aug 25, 2009 at 4:28 AM, Michael D
> Godfrey<godfrey at isl.stanford.edu> wrote:
>> Compatibility problems with: try; ... catch; ... end:
>>
>> This is beyond the strictest "Matlab compatibility"
>> rule. ?But, it can cause trouble. ?There are a number
>> of differences between Matlab (7.7.0 R2208b) and the
>> current Octave development system for try; catch;.
>>
>> First, the Matlab problem:
>>
>> There are 2 scripts attached. ?outer.m is the one to run.
>> It references inner_try.m. ?Lines 5 and 6 of inner_try.m show the
>> Matlab problem. ?If line 6 is used and line 5 commented out
>> Matlab does not show an error. ?It runs as if the line
>> were correct (or as if GAmouse was defined). ?Octave handles
>> this correctly: an error is raised and caught by outer.m.
>> (In the original code there was no disp(lasterr) in the
>> catch; end; so Octave just exited for no apparent reason.
>> Matlab ran OK.)
>>
> 
> This is the now famous short-circuiting behavior of element-wise
> logical operators. In Matlab, they short-circuit in if clauses, and
> not elsewhere. This has been discussed mutliple times and the general
> agreement is that it was bad design decision and Octave needs not copy
> it. Just use && (which I'd recommend in Matlab as well).
> 
>> The only thing that I can think of to do about this (other
>> than an error report to the Mathworks...) is to somewhere
>> document this as Matlab behavior that is not compatible with
>> Octave.
>>
> 
> I believe it is documented somewhere, but I may be wrong.
> 
> 

Please check the FAQ and in particular the section

http://www.gnu.org/software/octave/FAQ.html#MATLAB-compatibility

This has a good explanation why short circuiting & and | are a bad idea..

D.



-- 
View this message in context: http://www.nabble.com/Information-about-Matlab-try--...-catch--tp25127292p25136223.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.



From lindnerben at gmx.net  Tue Aug 25 09:37:44 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 25 Aug 2009 16:37:44 +0200
Subject: imgwrite/imfinfo fail in octave 3.2.x
In-Reply-To: <69d8d540908250127v4997d279p7f575d9465439cd4@mail.gmail.com>
References: <20090817103626.30974.qmail@web3808.mail.bbt.yahoo.co.jp>	
	<4A8936CC.7050307@gmx.net> <4A8956B2.4040500@gmx.net>
	<69d8d540908250127v4997d279p7f575d9465439cd4@mail.gmail.com>
Message-ID: <4A93F738.1030805@gmx.net>

> 
> Transplanted. Please CC me when a conclusion like this for 3.2.x is
> reached in a message.
> 

thanks.
I'll try to remember next time :)

benjamin


From jwe at octave.org  Tue Aug 25 10:30:14 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 25 Aug 2009 11:30:14 -0400
Subject: Information about Matlab try; ... catch;
In-Reply-To: <4A934C4E.3070101@isl.stanford.edu>
References: <4A934C4E.3070101@isl.stanford.edu>
Message-ID: <19092.902.444594.943448@segfault.lan>

On 24-Aug-2009, Michael D Godfrey wrote:

| Next, other differences:
| 
| 1. In outer.m, Matlab will not allow the printf statement
|     after the catch;  (line 19)
| 
| 2. Even more odd, Matlab will not allow the printf statement at
|     line 14 of outer.m.  With that line NOT commented Matlab says:

Matlab does not have printf.  It provides

  fprintf (FID, FMT, ...)
  fprintf (FMT, ...)

and Octave is compatible with this, so just use fprintf and it should
work in both.

jwe

From godfrey at isl.stanford.edu  Tue Aug 25 11:39:12 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Tue, 25 Aug 2009 09:39:12 -0700
Subject: Information about Matlab try; ... catch;
In-Reply-To: <19092.902.444594.943448@segfault.lan>
References: <4A934C4E.3070101@isl.stanford.edu>
	<19092.902.444594.943448@segfault.lan>
Message-ID: <4A9413B0.7010104@isl.stanford.edu>

On 08/25/2009 08:30 AM, John W. Eaton wrote:
> Matlab does not have printf.

Oops!  I forgot that.  Thanks.
One less "bug" for Matlab.

Michael

From relgire at gmail.com  Tue Aug 25 14:57:37 2009
From: relgire at gmail.com (E. Joshua Rigler)
Date: Tue, 25 Aug 2009 13:57:37 -0600
Subject: datestr.m strangeness
In-Reply-To: <69d8d540908242333q7367d9a1jdff6c4a9aec7011d@mail.gmail.com>
References: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>
	<69d8d540908242333q7367d9a1jdff6c4a9aec7011d@mail.gmail.com>
Message-ID: <6b48db1f0908251257g4a1bb02bq3272086e5136061@mail.gmail.com>

On Tue, Aug 25, 2009 at 12:33 AM, Jaroslav Hajek<highegg at gmail.com> wrote:
> On Thu, Aug 20, 2009 at 3:16 AM, E. Joshua Rigler<relgire at gmail.com> wrote:
>> Running a custom compilation of Octave on Redhat Enterprise 5
>> (64-bit), I get the following:
>>
>> octave:207> datestr(datenum(2009, 8, 19, 17, 27, 45))
>> ans = 19-Aug-2009 18:27:45
>>
>> Note that the hour given by datestr.m is one larger than what I passed
>> to datenum.m.? What's weirder, this anomaly seems tied to dates in
>> some confusing fashion.? For example, the following tests one minute
>> after midnight on both March 8 and 9 in 2009:
>>
>> octave:210> datestr(datenum(2009, 3, 8, 0, 0, 1))
>> ans = 08-Mar-2009 00:00:01
>> octave:211> datestr(datenum(2009, 3, 9, 0, 0, 1))
>> ans = 09-Mar-2009 01:00:01
>>
>> The following tests one minute after midnight on March 14th in both
>> 2006 and 2007:
>>
>> octave:220> datestr(datenum(2006, 3, 14, 0, 0, 1))
>> ans = 14-Mar-2006 00:00:01
>> octave:221> datestr(datenum(2007, 3, 14, 0, 0, 1))
>> ans = 14-Mar-2007 01:00:01
>>
>> Finally, if one passes no sub-daily information to datenum.m, or sets
>> the hour, minute, and second to zero, datestr.m always returns what is
>> expected. ?I did confirm that datenum.m is returning expected results,
>> as is datevec.m, but trying to understand the source code in
>> datestr.m, or worse, time.cc (for mktime and strftime functions), just
>> makes my head hurt.
>>
>> Can anyone confirm this behavior, or is it unique to my system? ?Let
>> me know if you need additional info.
>>
>> -EJR
>>
>
> At this point it's just guessing, but I think this is because datenum
> ignores summer time (it's just plain linear date) whereas datestr uses
> localtime, which attempts to account for time zone, and summer time.
> The rules for switching to summer time are obscure (at least in my
> country) - typically it's the first Sunday after equinox.
> I suggest you try whether this explains your results - when moving
> through the year, you should see exactly two jumps, one forward and
> one backward. I can't tell, however, what behavior is Matlab
> compatible.
>
> --
> RNDr. Jaroslav Hajek


I agree, this definitely seems related to daylight savings time (i.e.,
"summer" time).  I still think there is something wrong with Octave.
To demonstrate, first note that my Linux system's time seems to be set
properly:

  <~> date -u; date
  Tue Aug 25 19:25:18 UTC 2009
  Tue Aug 25 13:25:18 MDT 2009

  <~> echo $TZ
  America/Denver

As you can see, assuming UTC is correct, the Gnu date function
properly accounts for the correct 6-hour differential between UTC and
my local daylight savings time (i.e., MDT, or U.S. "Mountain Daylight
Time").  However, if I type the following into Octave, I get a 7-hour
differential:

  octave:110> (mktime(gmtime(time)) - mktime(localtime(time)))/3600
  ans =  7.0000

Since the results of "localtime(time())" are correct, this seems to
indicate that something is wrong with the mktime function in time.oct.
 I'm afraid I just don't have the skill or experience with Octave's
C++ source code to track this much farther.

-EJR


From sleffler at avophotonics.com  Tue Aug 25 17:00:54 2009
From: sleffler at avophotonics.com (Steven Leffler)
Date: Tue, 25 Aug 2009 18:00:54 -0400
Subject: Reversed arguments to function fmod?
Message-ID: <079950E0D1BC4B60A71CAEF7F0C71D9D@SLeffler>

Bug report for Octave 3.2.0 configured for i686-pc-mingw32

Description:
-----------
I'm not sure if this is a bug, or just my being new to Octave. The built-in
function fmod seems to have its arguments switched, compared to what is
stated in the documentation and the behavior of the c library function. 

Repeat-By:
---------

Running Octave and entering "fmod(5.3,2)" returns "ans=2". Entering "fmod
(18.5,4.2)" returns "ans =  4.2000". I believe the correct answers should be
1.3 and 1.7, respectively.

Reversing the arguments gives the expected results: "fmod(2,5.3)" returns
"ans =  1.3000", while "fmod(4.2,18.5)" returns "ans =  1.7000". Am I
missing something here, or is this correct behavior?


Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Windows
configure opts:   
Fortran compiler: mingw32-gfortran-4.3.0-dw2
FFLAGS:           -O -mieee-fp
FLIBS:            -lgfortran
CPPFLAGS:         -march=i686 -mtune=generic -O2 
INCFLAGS:         -I. -I/octaveforge_mingw32/octave/octave-3.2.0 -I.
-I./liboctave -I./src -I./libcruft/misc
-I/octaveforge_mingw32/octave/octave-3.2.0
-I/octaveforge_mingw32/octave/octave-3.2.0/liboctave
-I/octaveforge_mingw32/octave/octave-3.2.0/src
-I/octaveforge_mingw32/octave/octave-3.2.0/libcruft/misc
C compiler:       mingw32-gcc-4.3.0-dw2, version4.3.0-dw2 (GCC TDM-2 for
MinGW) 
CFLAGS:           -Wall
CPICFLAG:         
C++ compiler:     mingw32-g++-4.3.0-dw2, version4.3.0-dw2
CXXFLAGS:         -D_DLL -Wall
CXXPICFLAG:       
LD_CXX:           mingw32-g++-4.3.0-dw2
LDFLAGS:          -shared-libgcc -Wl,--exclude-libs=-lstdc++_s
-Wl,--allow-multiple-definition
LIBFLAGS:         -L.
RLD_FLAG:         
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -liberty -lblas -lhdf5 -lz -lm
-lgdi32 -lws2_32 -luser32 -lkernel32
LEXLIB:           
LIBGLOB:          -lglob
SED:              /usr/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_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_GLPK_H=1 -DHAVE_GLPK=1
-DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_WINDOWS_H=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 -Duid_t=int
-Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_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=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_ASSERT_H=1 -DHAVE_CURSES_H=1
-DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1
-DHAVE_PTHREAD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1
-DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1
-DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1
-DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1
-DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE_GETTIMEOFDAY=1
-DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LOG1P=1
-DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_PUTENV=1
-DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1
-DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1
-DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1
-DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1
-DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1
-DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1
-DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1
-DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1
-DHAVE_MKSTEMPS=1 -DHAVE_STRFTIME=1 -DHAVE_C99_VSNPRINTF=1
-DOCTAVE_HAVE_BROKEN_STRPTIME=1 -D_WIN32_WINNT=0x0403
-DHAVE_LOADLIBRARY_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_COPYSIGN=1 -DHAVE_SIGNBIT=1
-DHAVE__FINITE=1 -DHAVE__ISNAN=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_RDEV=1 -DHAVE_DECL_TZNAME=1 -DHAVE_TZNAME=1
-DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void
-DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1
-DRETSIGTYPE_IS_VOID=1


User-preferences (please do not edit this section):

  EDITOR = C:\Octave\3.2.0_gcc-4.3.0\tools\notepad++\notepad++.exe
  EXEC_PATH =
C:\Octave\3.2.0_gcc-4.3.0\MINGW32\bin;C:\Octave\3.2.0_gcc-4.3.0\MSYS\bin;C:\
Octave\3.2.0_gcc-4.3.0\libexec\octave\3.2.0\site\exec\i686-pc-mingw32;C:\Oct
ave\3.2.0_gcc-4.3.0\libexec\octave\api-v37\site\exec\i686-pc-mingw32;C:\Octa
ve\3.2.0_gcc-4.3.0\libexec\octave\site\exec\i686-pc-mingw32;C:\Octave\3.2.0_
gcc-4.3.0\libexec\octave\3.2.0\exec\i686-pc-mingw32;C:\Octave\3.2.0_gcc-4.3.
0\bin;C:\GTK\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
  IMAGE_PATH = .;C:\Octave\3.2.0_gcc-4.3.0\share\octave\3.2.0\imagelib
  PAGER = C:\Octave\3.2.0_gcc-4.3.0\bin\less.exe
  PS1 = \#>
  PS2 = > 
  PS4 = + 
  beep_on_error = 0
  completion_append_char =  
  crash_dumps_octave_core = 1
  echo_executing_commands = 0
  fixed_point_format = 0
  gnuplot_binary = C:\Octave\3.2.0_gcc-4.3.0\bin\gnuplot.exe
# gnuplot_command_end = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = C:\Documents and Settings\Steven Leffler\.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = C:\Octave\3.2.0_gcc-4.3.0\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 = <no value or error in displaying it>
  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  Wed Aug 26 01:20:51 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 26 Aug 2009 08:20:51 +0200
Subject: Reversed arguments to function fmod?
In-Reply-To: <079950E0D1BC4B60A71CAEF7F0C71D9D@SLeffler>
References: <079950E0D1BC4B60A71CAEF7F0C71D9D@SLeffler>
Message-ID: <69d8d540908252320r55b983a3j2e2ecd1db529a16f@mail.gmail.com>

On Wed, Aug 26, 2009 at 12:00 AM, Steven
Leffler<sleffler at avophotonics.com> wrote:
> Bug report for Octave 3.2.0 configured for i686-pc-mingw32
>
> Description:
> -----------
> I'm not sure if this is a bug, or just my being new to Octave. The built-in
> function fmod seems to have its arguments switched, compared to what is
> stated in the documentation and the behavior of the c library function.
>
> Repeat-By:
> ---------
>
> Running Octave and entering "fmod(5.3,2)" returns "ans=2". Entering "fmod
> (18.5,4.2)" returns "ans = ?4.2000". I believe the correct answers should be
> 1.3 and 1.7, respectively.
>
> Reversing the arguments gives the expected results: "fmod(2,5.3)" returns
> "ans = ?1.3000", while "fmod(4.2,18.5)" returns "ans = ?1.7000". Am I
> missing something here, or is this correct behavior?
>
>

No, I think it's a bug. Please try
http://hg.savannah.gnu.org/hgweb/octave/rev/b8db3595f706

thanks

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From grb at tf.uni-kiel.de  Wed Aug 26 02:03:42 2009
From: grb at tf.uni-kiel.de (grb at tf.uni-kiel.de)
Date: Wed, 26 Aug 2009 09:03:42 +0200 (CEST)
Subject: int2str doesn't work with int's
Message-ID: <53583.91.43.109.179.1251270222.squirrel@webmail.tf.uni-kiel.de>

--------
Bug report for Octave 3.1.55 configured for i686-pc-linux-gnu

Repeat-By:
---------
octave:1> int2str (int32(42))
error: octave_base_value::log10 (): wrong type argument `int32 scalar'
error: evaluating argument list element number 1
error: called from:
error:   /usr/local/share/octave/3.1.55/m/general/int2str.m at line 105,
column 5
error: evaluating argument list element number 1
error:   /usr/local/share/octave/3.1.55/m/general/int2str.m at line 69,
column 11

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 Snoopy 2.6.24-24-generic #1 SMP Fri Jul 24
22:46:06 UTC 2009 i686 GNU/Linux
configure opts:   'F77=gfortran' 'LIBS=-lgfortran'
Fortran compiler: gfortran
FFLAGS:           -O -mieee-fp
FLIBS:            -L/usr/local/lib/../lib
-L/usr/lib/gcc/i486-linux-gnu/4.2.4
-L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/local/lib
-L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../.. -lgfortranbegin -lgfortran
-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.1.55
BLAS_LIBS:        -llapack -lcblas -lf77blas -latlas
FFTW_LIBS:        %OCTAVE_CONF_FFTW_LIBS%
LIBS:             -llapack -lcblas -lf77blas -latlas 
-L/usr/local/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.4
-L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/local/lib
-L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../.. -lgfortranbegin -lgfortran
-lm -lcblas -lf77blas -latlas -lm -lgfortran
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_PTHREAD=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=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_ZLIB=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_CURL_CURL_H=1 -DHAVE_CURL=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_UPPERCASE=1
  -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL=1
  -DHAVE_FONTCONFIG=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_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

User-preferences (please do not edit this section):
--------------------------------------------------

  EDITOR = /usr/bin/dtemacs
  EXEC_PATH =
/usr/local/libexec/octave/3.1.55/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.1.55/exec/i686-pc-linux-gnu:/usr/local/bin:/home/grb/bin:/opt/maple12/bin/:/opt/pgi/linux86/7.2/bin:/home/grb/work/galene/bin:/usr/totalview/bin:/opt/intel/idb/9.1.049/bin:/opt/intel/fc/9.1.045/bin:/opt/intel/cc/9.1.049/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
  IMAGE_PATH = .:/usr/local/share/octave/3.1.55/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/grb/.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 = <no value or error in displaying it>
  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  Wed Aug 26 05:45:16 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 26 Aug 2009 12:45:16 +0200
Subject: datestr.m strangeness
In-Reply-To: <6b48db1f0908251257g4a1bb02bq3272086e5136061@mail.gmail.com>
References: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>
	<69d8d540908242333q7367d9a1jdff6c4a9aec7011d@mail.gmail.com>
	<6b48db1f0908251257g4a1bb02bq3272086e5136061@mail.gmail.com>
Message-ID: <69d8d540908260345u1df93fe0of39fc1137bd2422d@mail.gmail.com>

On Tue, Aug 25, 2009 at 9:57 PM, E. Joshua Rigler<relgire at gmail.com> wrote:
> On Tue, Aug 25, 2009 at 12:33 AM, Jaroslav Hajek<highegg at gmail.com> wrote:
>> On Thu, Aug 20, 2009 at 3:16 AM, E. Joshua Rigler<relgire at gmail.com> wrote:
>>> Running a custom compilation of Octave on Redhat Enterprise 5
>>> (64-bit), I get the following:
>>>
>>> octave:207> datestr(datenum(2009, 8, 19, 17, 27, 45))
>>> ans = 19-Aug-2009 18:27:45
>>>
>>> Note that the hour given by datestr.m is one larger than what I passed
>>> to datenum.m.? What's weirder, this anomaly seems tied to dates in
>>> some confusing fashion.? For example, the following tests one minute
>>> after midnight on both March 8 and 9 in 2009:
>>>
>>> octave:210> datestr(datenum(2009, 3, 8, 0, 0, 1))
>>> ans = 08-Mar-2009 00:00:01
>>> octave:211> datestr(datenum(2009, 3, 9, 0, 0, 1))
>>> ans = 09-Mar-2009 01:00:01
>>>
>>> The following tests one minute after midnight on March 14th in both
>>> 2006 and 2007:
>>>
>>> octave:220> datestr(datenum(2006, 3, 14, 0, 0, 1))
>>> ans = 14-Mar-2006 00:00:01
>>> octave:221> datestr(datenum(2007, 3, 14, 0, 0, 1))
>>> ans = 14-Mar-2007 01:00:01
>>>
>>> Finally, if one passes no sub-daily information to datenum.m, or sets
>>> the hour, minute, and second to zero, datestr.m always returns what is
>>> expected. ?I did confirm that datenum.m is returning expected results,
>>> as is datevec.m, but trying to understand the source code in
>>> datestr.m, or worse, time.cc (for mktime and strftime functions), just
>>> makes my head hurt.
>>>
>>> Can anyone confirm this behavior, or is it unique to my system? ?Let
>>> me know if you need additional info.
>>>
>>> -EJR
>>>
>>
>> At this point it's just guessing, but I think this is because datenum
>> ignores summer time (it's just plain linear date) whereas datestr uses
>> localtime, which attempts to account for time zone, and summer time.
>> The rules for switching to summer time are obscure (at least in my
>> country) - typically it's the first Sunday after equinox.
>> I suggest you try whether this explains your results - when moving
>> through the year, you should see exactly two jumps, one forward and
>> one backward. I can't tell, however, what behavior is Matlab
>> compatible.
>>
>> --
>> RNDr. Jaroslav Hajek
>
>
> I agree, this definitely seems related to daylight savings time (i.e.,
> "summer" time). ?I still think there is something wrong with Octave.
> To demonstrate, first note that my Linux system's time seems to be set
> properly:
>
> ?<~> date -u; date
> ?Tue Aug 25 19:25:18 UTC 2009
> ?Tue Aug 25 13:25:18 MDT 2009
>
> ?<~> echo $TZ
> ?America/Denver
>
> As you can see, assuming UTC is correct, the Gnu date function
> properly accounts for the correct 6-hour differential between UTC and
> my local daylight savings time (i.e., MDT, or U.S. "Mountain Daylight
> Time"). ?However, if I type the following into Octave, I get a 7-hour
> differential:
>
> ?octave:110> (mktime(gmtime(time)) - mktime(localtime(time)))/3600
> ?ans = ?7.0000
>

Actually, this is the correct value. Octave's mktime inherits the
weirdness of ISO C's mktime: tm.isdst is taken into account, tm.zone
isn't (in fact that's not ISO at all).

hth

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From c.belotti at imperial.ac.uk  Wed Aug 26 05:58:44 2009
From: c.belotti at imperial.ac.uk (Claudio Belotti)
Date: Wed, 26 Aug 2009 11:58:44 +0100
Subject: pcolor doesn't plot the last column and row
Message-ID: <E1MgGDE-00044B-93@berillio.sp.ph.ic.ac.uk>

To: bug at octave.org
Cc: claudio.belotti at octave.org
Subject: pcolor doesn't plot the last column and row

Bug report for Octave 3.2.0 configured for x86_64-pc-linux-gnu

Description:
-----------
  
  when plotting a matrix with pcolor the last row and columns are not plotted

Repeat-By:
---------

    pcolor(eye(4))
    only shwos 9 squares and not 16 as expected    

Fix:
---
	
    a workaraund is to add an empty row and column to the matrix
    pcolor([[eye(4),zeros(4,1)]; zeros(1,5)])




Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Linux berillio 2.6.30-1-amd64 #1 SMP Mon Aug 3 12:28:22 UTC 2009 x86_64 GNU/Linux
configure opts:   '--build=x86_64-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=x86_64-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
FLIBS:            -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../.. -L/usr/lib/x86_64-linux-gnu -lhdf5 -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-11) 
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.2.0
BLAS_LIBS:        -llapackgf-3 -lblas-3gf
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -ldl -lblas-3gf -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 -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_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=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=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 = /usr/bin/emacs -nw
  EXEC_PATH = /usr/lib/octave/3.2.0/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/api-v37/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/site/exec/x86_64-pc-linux-gnu:/usr/lib/octave/3.2.0/exec/x86_64-pc-linux-gnu:/usr/bin:/home/bel8/sci/EdwardsSlingo/esrad/bin:/home/bel8/sci/EdwardsSlingo/esrad/sbin:/opt/intel/idbe/10.1.008/bin:/opt/intel/fce/10.1.008/bin:/home/bel8/bin:/usr/local/lf9561/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
  IMAGE_PATH = .:/usr/share/octave/3.2.0/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/bel8/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = /usr/share/info/octave3.2.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 = <no value or error in displaying it>
  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 bpabbott at mac.com  Wed Aug 26 08:25:31 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 26 Aug 2009 09:25:31 -0400
Subject: pcolor doesn't plot the last column and row
In-Reply-To: <E1MgGDE-00044B-93@berillio.sp.ph.ic.ac.uk>
References: <E1MgGDE-00044B-93@berillio.sp.ph.ic.ac.uk>
Message-ID: <152565525128571556630131292641541655982-Webmail@me.com>

On Wednesday, August 26, 2009, at 06:58AM, "Claudio Belotti" <c.belotti at imperial.ac.uk> wrote:
>To: bug at octave.org
>Cc: claudio.belotti at octave.org
>Subject: pcolor doesn't plot the last column and row
>
>Bug report for Octave 3.2.0 configured for x86_64-pc-linux-gnu
>
>Description:
>-----------
>  
>  when plotting a matrix with pcolor the last row and columns are not plotted
>
>Repeat-By:
>---------
>
>    pcolor(eye(4))
>    only shwos 9 squares and not 16 as expected    
>

pcolor() is intended to produce one vertex for each matrix element (see "help pcolor"). What is happening is clearer if you try ...

    pcolor(eye(4))
    shading interp

The currrent implementation is consistent with Matlab's, so I don't think there is a bug here.

Ben


From relgire at gmail.com  Wed Aug 26 12:27:45 2009
From: relgire at gmail.com (E. Joshua Rigler)
Date: Wed, 26 Aug 2009 11:27:45 -0600
Subject: datestr.m strangeness
In-Reply-To: <69d8d540908260345u1df93fe0of39fc1137bd2422d@mail.gmail.com>
References: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>
	<69d8d540908242333q7367d9a1jdff6c4a9aec7011d@mail.gmail.com>
	<6b48db1f0908251257g4a1bb02bq3272086e5136061@mail.gmail.com>
	<69d8d540908260345u1df93fe0of39fc1137bd2422d@mail.gmail.com>
Message-ID: <6b48db1f0908261027v7bb448b4u864d296a752c1190@mail.gmail.com>

On Wed, Aug 26, 2009 at 4:45 AM, Jaroslav Hajek<highegg at gmail.com> wrote:
> On Tue, Aug 25, 2009 at 9:57 PM, E. Joshua Rigler<relgire at gmail.com> wrote:
>> On Tue, Aug 25, 2009 at 12:33 AM, Jaroslav Hajek<highegg at gmail.com> wrote:
>>> On Thu, Aug 20, 2009 at 3:16 AM, E. Joshua Rigler<relgire at gmail.com> wrote:
>>>> Running a custom compilation of Octave on Redhat Enterprise 5
>>>> (64-bit), I get the following:
>>>>
>>>> octave:207> datestr(datenum(2009, 8, 19, 17, 27, 45))
>>>> ans = 19-Aug-2009 18:27:45
>>>>
>>>> Note that the hour given by datestr.m is one larger than what I passed
>>>> to datenum.m.? What's weirder, this anomaly seems tied to dates in
>>>> some confusing fashion.? For example, the following tests one minute
>>>> after midnight on both March 8 and 9 in 2009:
>>>>
>>>> octave:210> datestr(datenum(2009, 3, 8, 0, 0, 1))
>>>> ans = 08-Mar-2009 00:00:01
>>>> octave:211> datestr(datenum(2009, 3, 9, 0, 0, 1))
>>>> ans = 09-Mar-2009 01:00:01
>>>>
>>>> The following tests one minute after midnight on March 14th in both
>>>> 2006 and 2007:
>>>>
>>>> octave:220> datestr(datenum(2006, 3, 14, 0, 0, 1))
>>>> ans = 14-Mar-2006 00:00:01
>>>> octave:221> datestr(datenum(2007, 3, 14, 0, 0, 1))
>>>> ans = 14-Mar-2007 01:00:01
>>>>
>>>> Finally, if one passes no sub-daily information to datenum.m, or sets
>>>> the hour, minute, and second to zero, datestr.m always returns what is
>>>> expected. ?I did confirm that datenum.m is returning expected results,
>>>> as is datevec.m, but trying to understand the source code in
>>>> datestr.m, or worse, time.cc (for mktime and strftime functions), just
>>>> makes my head hurt.
>>>>
>>>> Can anyone confirm this behavior, or is it unique to my system? ?Let
>>>> me know if you need additional info.
>>>>
>>>> -EJR
>>>>
>>>
>>> At this point it's just guessing, but I think this is because datenum
>>> ignores summer time (it's just plain linear date) whereas datestr uses
>>> localtime, which attempts to account for time zone, and summer time.
>>> The rules for switching to summer time are obscure (at least in my
>>> country) - typically it's the first Sunday after equinox.
>>> I suggest you try whether this explains your results - when moving
>>> through the year, you should see exactly two jumps, one forward and
>>> one backward. I can't tell, however, what behavior is Matlab
>>> compatible.
>>>
>>> --
>>> RNDr. Jaroslav Hajek
>>
>>
>> I agree, this definitely seems related to daylight savings time (i.e.,
>> "summer" time). ?I still think there is something wrong with Octave.
>> To demonstrate, first note that my Linux system's time seems to be set
>> properly:
>>
>> ?<~> date -u; date
>> ?Tue Aug 25 19:25:18 UTC 2009
>> ?Tue Aug 25 13:25:18 MDT 2009
>>
>> ?<~> echo $TZ
>> ?America/Denver
>>
>> As you can see, assuming UTC is correct, the Gnu date function
>> properly accounts for the correct 6-hour differential between UTC and
>> my local daylight savings time (i.e., MDT, or U.S. "Mountain Daylight
>> Time"). ?However, if I type the following into Octave, I get a 7-hour
>> differential:
>>
>> ?octave:110> (mktime(gmtime(time)) - mktime(localtime(time)))/3600
>> ?ans = ?7.0000
>>
>
> Actually, this is the correct value. Octave's mktime inherits the
> weirdness of ISO C's mktime: tm.isdst is taken into account, tm.zone
> isn't (in fact that's not ISO at all).
>
> hth

Ah, I understand why mktime is not broken now.  Thanks for the clarification.

But, datestr.m is still broken (or at least incompatible with m**lab),
because it does not set tm.isdst before passing tm to mktime.  ISO C
states that setting tm.isdst=-1will force mktime to determine whether
the time in question falls during daylight savings or not.  I made
this change to my local copy of datestr.m, and everything now works as
expected (i.e., datestr(datenum(2009,8,26,12,0,0)) actually returns
the desired date string).

-EJR


From jwe at octave.org  Wed Aug 26 12:48:49 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 13:48:49 -0400
Subject: datestr.m strangeness
In-Reply-To: <6b48db1f0908261027v7bb448b4u864d296a752c1190@mail.gmail.com>
References: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>
	<69d8d540908242333q7367d9a1jdff6c4a9aec7011d@mail.gmail.com>
	<6b48db1f0908251257g4a1bb02bq3272086e5136061@mail.gmail.com>
	<69d8d540908260345u1df93fe0of39fc1137bd2422d@mail.gmail.com>
	<6b48db1f0908261027v7bb448b4u864d296a752c1190@mail.gmail.com>
Message-ID: <19093.30081.486771.612893@segfault.lan>

On 26-Aug-2009, E. Joshua Rigler wrote:

| Ah, I understand why mktime is not broken now.  Thanks for the clarification.
| 
| But, datestr.m is still broken (or at least incompatible with m**lab),
| because it does not set tm.isdst before passing tm to mktime.  ISO C
| states that setting tm.isdst=-1will force mktime to determine whether
| the time in question falls during daylight savings or not.  I made
| this change to my local copy of datestr.m, and everything now works as
| expected (i.e., datestr(datenum(2009,8,26,12,0,0)) actually returns
| the desired date string).

How about submitting a changeset, or at least a context diff?

jwe

From lindnerben at gmx.net  Wed Aug 26 14:18:19 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Wed, 26 Aug 2009 21:18:19 +0200
Subject: PDF printing creates empty pages around the actual output
In-Reply-To: <4A92EDE0.1010504@gmx.net>
References: <33cf4bba0908240307ka0cf8y541d9287028f9ba0@mail.gmail.com>
	<4A92EDE0.1010504@gmx.net>
Message-ID: <4A958A7B.3050408@gmx.net>

Benjamin Lindner wrote:
> Heikki Johannes Junes wrote:
>> PDF printing creates empty pages around the actual output.
>> Steps to reproduce:
>>
>> plot(sin(0:0.1:10));
>> print(gcf,'test.pdf','-dpdf');
>>
>> The generated PDF output has
>>  - empty page 1,
>>  - plot in page 2, and
>>  - empty page 3.
>>
>> The empty pages should not be there.
>> This is the only bug that prevents me shifting from 3.0.5 to 3.2.2.
> 
> This is a bug in gnuplot which is fixed in gnuplot's CVS but not yet in 
> any released version.

I stand corrected. There *is* a new CVS snapshot available which I did 
not realize. It contains the fix for the cairopdf terminal removing the 
reported bug.

I updated to the new snapshot and it will be included in the next 
octave/mingw32 release.

Apologies and thanks for bringing it up.

benjamin

From relgire at gmail.com  Wed Aug 26 16:32:38 2009
From: relgire at gmail.com (E. Joshua Rigler)
Date: Wed, 26 Aug 2009 15:32:38 -0600
Subject: datestr.m strangeness
In-Reply-To: <19093.30081.486771.612893@segfault.lan>
References: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>
	<69d8d540908242333q7367d9a1jdff6c4a9aec7011d@mail.gmail.com>
	<6b48db1f0908251257g4a1bb02bq3272086e5136061@mail.gmail.com>
	<69d8d540908260345u1df93fe0of39fc1137bd2422d@mail.gmail.com>
	<6b48db1f0908261027v7bb448b4u864d296a752c1190@mail.gmail.com>
	<19093.30081.486771.612893@segfault.lan>
Message-ID: <6b48db1f0908261432y4d0b9a11gfbe7b93ea294a718@mail.gmail.com>

On Wed, Aug 26, 2009 at 11:48 AM, John W. Eaton<jwe at octave.org> wrote:
> On 26-Aug-2009, E. Joshua Rigler wrote:
>
> | Ah, I understand why mktime is not broken now. ?Thanks for the clarification.
> |
> | But, datestr.m is still broken (or at least incompatible with m**lab),
> | because it does not set tm.isdst before passing tm to mktime. ?ISO C
> | states that setting tm.isdst=-1will force mktime to determine whether
> | the time in question falls during daylight savings or not. ?I made
> | this change to my local copy of datestr.m, and everything now works as
> | expected (i.e., datestr(datenum(2009,8,26,12,0,0)) actually returns
> | the desired date string).
>
> How about submitting a changeset, or at least a context diff?
>
> jwe
>

I'm not sure what a changeset is, but please find the attached context diff.

-EJR
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datestr.patch
Type: application/octet-stream
Size: 532 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090826/b9b00376/attachment.obj 

From jwe at octave.org  Wed Aug 26 16:47:11 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 17:47:11 -0400
Subject: datestr.m strangeness
In-Reply-To: <6b48db1f0908261432y4d0b9a11gfbe7b93ea294a718@mail.gmail.com>
References: <6b48db1f0908191816w1809caabw8c51f9bdc058a18e@mail.gmail.com>
	<69d8d540908242333q7367d9a1jdff6c4a9aec7011d@mail.gmail.com>
	<6b48db1f0908251257g4a1bb02bq3272086e5136061@mail.gmail.com>
	<69d8d540908260345u1df93fe0of39fc1137bd2422d@mail.gmail.com>
	<6b48db1f0908261027v7bb448b4u864d296a752c1190@mail.gmail.com>
	<19093.30081.486771.612893@segfault.lan>
	<6b48db1f0908261432y4d0b9a11gfbe7b93ea294a718@mail.gmail.com>
Message-ID: <19093.44383.566576.988102@segfault.lan>

On 26-Aug-2009, E. Joshua Rigler wrote:

| On Wed, Aug 26, 2009 at 11:48 AM, John W. Eaton<jwe at octave.org> wrote:
| > On 26-Aug-2009, E. Joshua Rigler wrote:
| >
| > | Ah, I understand why mktime is not broken now. ?Thanks for the clarification.
| > |
| > | But, datestr.m is still broken (or at least incompatible with m**lab),
| > | because it does not set tm.isdst before passing tm to mktime. ?ISO C
| > | states that setting tm.isdst=-1will force mktime to determine whether
| > | the time in question falls during daylight savings or not. ?I made
| > | this change to my local copy of datestr.m, and everything now works as
| > | expected (i.e., datestr(datenum(2009,8,26,12,0,0)) actually returns
| > | the desired date string).
| >
| > How about submitting a changeset, or at least a context diff?
| >
| > jwe
| >
| 
| I'm not sure what a changeset is, but please find the attached context diff.

I checked in this change, attributed to you:

  http://hg.savannah.gnu.org/hgweb/octave/rev/19124db6fc1c

Jaroslav, this could probably go in the 3.2.x branch.

Thanks,

jwe


From jwe at octave.org  Wed Aug 26 20:00:50 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 21:00:50 -0400
Subject: Another WWMTT item.
In-Reply-To: <186E458A-0B77-4847-8DD2-9AE43930D2B4@mac.com>
References: <4A931955.4020405@isl.stanford.edu>
	<186E458A-0B77-4847-8DD2-9AE43930D2B4@mac.com>
Message-ID: <19093.56002.24843.253524@segfault.lan>

On 24-Aug-2009, Ben Abbott wrote:

| On Aug 24, 2009, at 6:51 PM, Michael D. Godfrey wrote:
| 
| > I just noticed that in Matlab (7.7.0 R2008b)
| >
| > get(gcf,  'Render')
| >
| > works, even though they only list 'Renderer' as a property.
| > And, using 'Render' acts as if you had used 'Renderer'.
| > Obviously, there was a time in Matlab when...
| >
| > In Octave (current hg source), 'Renderer' is accepted, but 'Render'  
| > is not.
| > So, for compatibility,  implement 'Render' to mean 'Renderer'.
| >
| > Thanks,
| > Michael
| 
| If I infer correctly the property name is matched by something like ..
| 
| fields = fieldnames (get (gcf));
| field_idx = strncmpi (prop_name, fieldnames);
| if (numel (field_idx) == 1)
|    set (gcf, fields{field_idx}, prop_value);
| else
|    error ("Error  using set()")
| endif

Yes, we could do something like this.  Part of the implementation
needs to be done by changing the genprops.awk script, because that is
I think the only place where we currently have a list of all the
property names for a given graphics object (i.e., we need to have it
generate a functions like

  std::set<std::string> line_properties::all_properties (void) const;

so that the get/set functions for the property classes can first check
to see that the given property name will match uniquely in the list,
then go on and look up the name using the equivalent of strncmpi.

But I don't much like this feature because it can lead to code
breaking in the future if a property name is added that generates a
conflict.  For example, today 'Render' is sufficient to match the
'Renderer' property, but that will break in the future if a
'RenderFoo' property is added.  So should we really encourage this
kind of sloppy programming?  How essential is it for compatibility?

jwe

From jwe at octave.org  Wed Aug 26 20:52:56 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 21:52:56 -0400
Subject: auto sets axis scale too =?iso-2022-jp?Q?large=1B$,1ro=1B(B?=
In-Reply-To: <loom.20090824T223645-136@post.gmane.org>
References: <loom.20090824T223645-136@post.gmane.org>
Message-ID: <19093.59128.237407.234177@segfault.lan>

On 24-Aug-2009, Eric wrote:

| octave:1> a=0.001 : .001 : 0.017
| octave:2> plot(a)
| 
| - On FC7, octave-2.9.9-2.fc7, gnuplot-4.0.0-19.fc7, the x axis is nicely set
| from 0 to 18 and the y axis from 0 to 0.018.
| 
| - On FC11, octave-3.0.5-1.fc11.x86_64, gnuplot-4.2.4-6.fc11.x86_64, it seems
| that axis("auto") is forced to axis("tight").
| 
| - On Mandriva cooker, octave-3.2.2-1mdv2010.0, gnuplot-4.2.5-1mdv2010.0, the x
| axis is set from 0 to 20 and the y axis from 0 to 0.05. This is far too large.

On my system with Octave 3.2.2 I see the y limit going from 0 to 0.02,
which doesn't seem too bad to me.

| This is quite an annoying regression.

Saying that things are "quite annoying" is not a great way to motivate
people to help you out.

| I tried to find similar
| reports but could not find any. 
| 
| Is there a way to control how tight auto-scale is?

Octave 2.9.9 left the axis scaling to gnuplot.  With the new graphics
system, Octave computes the extents of the axes, and sets them
explicitly.  If you want to improve how that works, then I think the
functions to look at are

  axes::properties::get_axis_limits (double xmin, double xmax,
  axes::properties::calc_ticks_and_lims (array_property& lims,

in src/graphics.cc.

If you just want a quick fix for a particular plot, then you can
set the xlim and ylim properties directly.

jwe

From jwe at octave.org  Wed Aug 26 20:55:37 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 21:55:37 -0400
Subject: Fixing HDF-1.8 API for octave-3.2.x
In-Reply-To: <cf1003df0908230232p73aef993jc56895e9d59a1c49@mail.gmail.com>
References: <cf1003df0908220612u140d4fdj33af43722ca904e5@mail.gmail.com>
	<4A905142.8020308@dbateman.org>
	<cf1003df0908230232p73aef993jc56895e9d59a1c49@mail.gmail.com>
Message-ID: <19093.59289.539983.77168@segfault.lan>

On 23-Aug-2009, Kacper Kowalik wrote:

| as I understood there was some kind of problem in <=hdf5-1.2.2 with
| groups indexing in H5Giterate. Now it's long gone and things like !
| HAVE_H5GGET_NUM_OBJS are obsolete and have_h5giterate_bug is always
| false.
| Initial cleaning is rather straightforward, but there is a catch...
| Functions like H5Gget_num_objs and H5Giterate are depreciated in
| HDF5-1.8, so the right way to do it would be to migrate to H5Gget_info
| and H5Literate, already. However it's not that simple anymore. I could
| look into it, but I would need some example HDF5 files or some simple
| scripts for octave to check whether or not I've messed something up.

I would be in favor of cleaning things up.  How about doing it
incrementally, if possible, instead of submitting a jumbo patch that
tries to do everything at once?  How hard would it be to preserve
compatibility with older versions of HDF5?

jwe

From jwe at octave.org  Wed Aug 26 21:01:19 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 22:01:19 -0400
Subject: May be a bug in vol.m
In-Reply-To: <20090823005348.BB016C7761D@postfix.alumni.cuhk.net>
References: <20090823005348.BB016C7761D@postfix.alumni.cuhk.net>
Message-ID: <19093.59631.574908.201169@segfault.lan>

On 23-Aug-2009, Saikee Wong wrote:

| Bug report for Octave 2.9.13 configured for i386-apple-darwin8.9.1

Octave 2.9.13 is quite old.  I recommend upgrading to the current
version, 3.2.2.

| Description:
| -----------
| 
| I'm studying the code of vol.m to learn details of volatility. By comparing
| the article http://www.quantonline.co.za/documents/Volatility.pdf
| I suspect there may be problem in vol.m
| 
| The vol.m file I have looking at is
| /Applications/developer/octave/Octave.app/Contents/Resources/share/octave/2.9.13/m/finance/vol.m
| 
| Line 62 is
|     U = U - ones (xr - 1, 1) * sum (U) / (xr - 1);
| 
| where the summation is the whole matrix, but I think it should only be m
| elements in the matrix.
| 
| Secondly,   
| 
| Line 72 is
|     retval = sqrt (retval * m / (n * m - 1));
| 
| I doubt why the retval need to be multply by m
| 
| Thanks for your attention.

The vol.m function is now part of the Octave Forge finance package.
Problems with it should be reported to the
octave-dev at lists.sourceforge.net mailing list.

jwe

From jwe at octave.org  Wed Aug 26 21:04:48 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 22:04:48 -0400
Subject: axis colors override xrdb
In-Reply-To: <C94965D2-FFC8-4EB0-BB8B-8336F20FCC12@mac.com>
References: <25010647.post@talk.nabble.com> <25067791.post@talk.nabble.com>
	<C94965D2-FFC8-4EB0-BB8B-8336F20FCC12@mac.com>
Message-ID: <19093.59840.232270.523020@segfault.lan>

On 21-Aug-2009, Ben Abbott wrote:

| Regarding how to produce a plot on a black background, we'd prefer to  
| find a solution that is compatible with Matlab. With Matlab, the  
| following produces a blue line on a black background with the axes'  
| lines and labels drawn in white..
| 
| plot (1:10)
| set (gca, 'color', [0 0 0])
| set (gcf, 'color', [0 0 0])
| set (gca,'xcolor',[1 1 1],'ycolor',[1 1 1])
| 
| None of the "set" commands result in the compatible changes for Octave  
| (perhaps 3 patches are needed?).
| 
| If you have the time, your help in fixing this problem would be  
| appreciated.

If you want this to work when using the gnuplot backend, I suspect it
will require some changes to gnuplot.  Or is there already some way to
change the terminal background color using gnuplot commands that I'm
not aware of?

The gnuplot backend is pretty good, but has some serious limitations.
Maybe it is time to start putting more thought and effort into the
OpenGL backend instead?

jwe

From bpabbott at mac.com  Wed Aug 26 21:16:14 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 26 Aug 2009 22:16:14 -0400
Subject: axis colors override xrdb
In-Reply-To: <19093.59840.232270.523020@segfault.lan>
References: <25010647.post@talk.nabble.com> <25067791.post@talk.nabble.com>
	<C94965D2-FFC8-4EB0-BB8B-8336F20FCC12@mac.com>
	<19093.59840.232270.523020@segfault.lan>
Message-ID: <2CB70477-11F7-48B0-8632-4CD361466E14@mac.com>


On Aug 26, 2009, at 10:04 PM, John W. Eaton wrote:

> On 21-Aug-2009, Ben Abbott wrote:
>
> | Regarding how to produce a plot on a black background, we'd prefer  
> to
> | find a solution that is compatible with Matlab. With Matlab, the
> | following produces a blue line on a black background with the axes'
> | lines and labels drawn in white..
> |
> | plot (1:10)
> | set (gca, 'color', [0 0 0])
> | set (gcf, 'color', [0 0 0])
> | set (gca,'xcolor',[1 1 1],'ycolor',[1 1 1])
> |
> | None of the "set" commands result in the compatible changes for  
> Octave
> | (perhaps 3 patches are needed?).
> |
> | If you have the time, your help in fixing this problem would be
> | appreciated.
>
> If you want this to work when using the gnuplot backend, I suspect it
> will require some changes to gnuplot.  Or is there already some way to
> change the terminal background color using gnuplot commands that I'm
> not aware of?
>
> The gnuplot backend is pretty good, but has some serious limitations.
> Maybe it is time to start putting more thought and effort into the
> OpenGL backend instead?
>
> jwe

Regarding the gnuplot backend, Petr Mikulik emailed me the suggestion  
below.

> This functionality can be implemented by the following gnuplot  
> commands:
>
> # Screen background:
> # set (gcf, 'color', [0 1 0])
> set object 1 rect from screen 0,screen 0 to screen 1,screen 1 back
> set object 1 rect fc rgb "#00FF00" fillstyle solid 1.0
>
> # Graph background:
> # set (gca, 'color', [1 0 0])
> set object 2 rect from graph 0,graph 0 to graph 1,graph 1 back
> set object 2 rect fc rgb "#FF0000" fillstyle solid 1.0
>
> plot x with line lt 3

Ben




From jwe at octave.org  Wed Aug 26 21:28:53 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 22:28:53 -0400
Subject: axis colors override xrdb
In-Reply-To: <2CB70477-11F7-48B0-8632-4CD361466E14@mac.com>
References: <25010647.post@talk.nabble.com> <25067791.post@talk.nabble.com>
	<C94965D2-FFC8-4EB0-BB8B-8336F20FCC12@mac.com>
	<19093.59840.232270.523020@segfault.lan>
	<2CB70477-11F7-48B0-8632-4CD361466E14@mac.com>
Message-ID: <19093.61285.348008.708652@segfault.lan>

On 26-Aug-2009, Ben Abbott wrote:

| Regarding the gnuplot backend, Petr Mikulik emailed me the suggestion  
| below.
| 
| > This functionality can be implemented by the following gnuplot  
| > commands:
| >
| > # Screen background:
| > # set (gcf, 'color', [0 1 0])
| > set object 1 rect from screen 0,screen 0 to screen 1,screen 1 back
| > set object 1 rect fc rgb "#00FF00" fillstyle solid 1.0
| >
| > # Graph background:
| > # set (gca, 'color', [1 0 0])
| > set object 2 rect from graph 0,graph 0 to graph 1,graph 1 back
| > set object 2 rect fc rgb "#FF0000" fillstyle solid 1.0
| >
| > plot x with line lt 3

When I do this with gnuplot 4.2.5, the tics and labels don't appear,
at least with the wxt terminal.

BTW, your earlier commands

  plot (1:10)
  set (gca, 'color', [0 0 0])
  set (gcf, 'color', [0 0 0])
  set (gca,'xcolor',[1 1 1],'ycolor',[1 1 1])

already appear to work correctly with the fltk/opengl backend in
Octave 3.2.2.

With the current development sources, the axis labels are also
rendered in the correct color (they are not implemented in 3.2.2).

So I'd still like to see us putting more work into the fltk/opengl
backend as it is nearly usable now, and with a little work could be
very nice, probably faster than the gnuplot backend, would allow for
easier direct interaction with the plot using the mouse (for example,
it should be easier to update axes properties when the plot is changed
interactively with the mouse).

jwe

From godfrey at isl.stanford.edu  Thu Aug 27 00:08:39 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 26 Aug 2009 22:08:39 -0700
Subject: Another WWMTT item.
In-Reply-To: <19093.56002.24843.253524@segfault.lan>
References: <4A931955.4020405@isl.stanford.edu>	<186E458A-0B77-4847-8DD2-9AE43930D2B4@mac.com>
	<19093.56002.24843.253524@segfault.lan>
Message-ID: <4A9614D7.8070700@isl.stanford.edu>

On 08/26/2009 06:00 PM, John W. Eaton wrote:
> So should we really encourage this
> kind of sloppy programming?  How essential is it for compatibility?
>
>    
I am a bit sorry that I started this.  I did not intend that
matching Matlab in their sloppy matching should be
implemented.  I agree that this would likely lead to
problems in the future that would be worse than any
benefit now.  The diagnostic when a property match fails
could be improved though...  The stem match could be done
and then fail with a diagnostic like:  for Render, did you
really mean Renderer?   (Learn from Google???)

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090826/928f5537/attachment.html 

From mikulik at physics.muni.cz  Thu Aug 27 01:38:47 2009
From: mikulik at physics.muni.cz (Petr Mikulik)
Date: Thu, 27 Aug 2009 08:38:47 +0200 (CEST)
Subject: axis colors override xrdb
In-Reply-To: <19093.61285.348008.708652@segfault.lan>
References: <25010647.post@talk.nabble.com> <25067791.post@talk.nabble.com>
	<C94965D2-FFC8-4EB0-BB8B-8336F20FCC12@mac.com>
	<19093.59840.232270.523020@segfault.lan>
	<2CB70477-11F7-48B0-8632-4CD361466E14@mac.com>
	<19093.61285.348008.708652@segfault.lan>
Message-ID: <Pine.LNX.4.64.0908270837230.30361@monoceros.physics.muni.cz>

> | Regarding the gnuplot backend, Petr Mikulik emailed me the suggestion  
> | below.
> | 
> | > This functionality can be implemented by the following gnuplot  
> | > commands:
> | >
> | > # Screen background:
> | > # set (gcf, 'color', [0 1 0])
> | > set object 1 rect from screen 0,screen 0 to screen 1,screen 1 back
> | > set object 1 rect fc rgb "#00FF00" fillstyle solid 1.0
> | >
> | > # Graph background:
> | > # set (gca, 'color', [1 0 0])
> | > set object 2 rect from graph 0,graph 0 to graph 1,graph 1 back
> | > set object 2 rect fc rgb "#FF0000" fillstyle solid 1.0
> | >
> | > plot x with line lt 3
> 
> When I do this with gnuplot 4.2.5, the tics and labels don't appear,
> at least with the wxt terminal.

Then the following is needed as well:
  set grid front; unset grid

---
PM

From xarthisius.kk at gmail.com  Thu Aug 27 03:50:39 2009
From: xarthisius.kk at gmail.com (Kacper Kowalik)
Date: Thu, 27 Aug 2009 10:50:39 +0200
Subject: Fixing HDF-1.8 API for octave-3.2.x
In-Reply-To: <19093.59289.539983.77168@segfault.lan>
References: <cf1003df0908220612u140d4fdj33af43722ca904e5@mail.gmail.com>
	<4A905142.8020308@dbateman.org>
	<cf1003df0908230232p73aef993jc56895e9d59a1c49@mail.gmail.com>
	<19093.59289.539983.77168@segfault.lan>
Message-ID: <cf1003df0908270150m1fa05775q42d9e88fe1fd71bc@mail.gmail.com>

2009/8/27 John W. Eaton <jwe at octave.org>:
> I would be in favor of cleaning things up. ?How about doing it
> incrementally, if possible, instead of submitting a jumbo patch that
> tries to do everything at once? ?How hard would it be to preserve
> compatibility with older versions of HDF5?

If you would like to preserve compatibility with 1.6 API it's rather
simple and I will do it that way.
As for the earlier versions (1.4, 1.2) I don't know, I haven't used
them but I would really recommend to drop the support for <1.6.
I'll try to divide changes into several patches.

Best regards,
Kacper Kowalik


From grb at tf.uni-kiel.de  Thu Aug 27 05:54:05 2009
From: grb at tf.uni-kiel.de (grb at tf.uni-kiel.de)
Date: Thu, 27 Aug 2009 12:54:05 +0200 (CEST)
Subject: octave panic calling builtin('subsref', ...)
Message-ID: <58373.91.43.109.157.1251370445.squirrel@webmail.tf.uni-kiel.de>

Bug report for Octave 3.1.55 configured for i686-pc-linux-gnu

Description:
-----------

builtin('subsref', ...) gives unexpected results or fails at all

Repeat-By:
---------

@bar/bar.m
function this = bar(a,b)
  this = class(struct('a',a,'b',b), 'bar');

@bar/subsref.m
function r = subsref(this,idx)
  r = builtin('subsref', this, idx);

octave:1> b = bar(42, 'foo')
octave:2> assert(class(b(1)),'bar')
error: assert (class (b (1)),'bar') expected
bar
but got
struct
error: called from:
error:   /usr/local/share/octave/3.1.55/m/testfun/assert.m at line 234,
column 5
octave:2> assert( b.a, 42 )
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr
panic: Aborted -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Aborted





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 Snoopy 2.6.24-24-generic #1 SMP Fri Jul 24
22:46:06 UTC 2009 i686 GNU/Linux
configure opts:   'F77=gfortran' 'LIBS=-lgfortran'
Fortran compiler: gfortran
FFLAGS:           -O -mieee-fp
FLIBS:            -L/usr/local/lib/../lib
-L/usr/lib/gcc/i486-linux-gnu/4.2.4
-L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/local/lib
-L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../.. -lgfortranbegin -lgfortran
-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.1.55
BLAS_LIBS:        -llapack -lcblas -lf77blas -latlas
FFTW_LIBS:        %OCTAVE_CONF_FFTW_LIBS%
LIBS:             -llapack -lcblas -lf77blas -latlas 
-L/usr/local/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.4
-L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/local/lib
-L/usr/lib/gcc/i486-linux-gnu/4.2.4/../../.. -lgfortranbegin -lgfortran
-lm -lcblas -lf77blas -latlas -lm -lgfortran
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_PTHREAD=1 -DHAVE_X_WINDOWS=1 -DHAVE_LIBM=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_ZLIB=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_CURL_CURL_H=1 -DHAVE_CURL=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_UPPERCASE=1
  -DHAVE_FTGL_FTGL_H=1 -DHAVE_FTGL_UPPERCASE=1 -DHAVE_FTGL=1
  -DHAVE_FONTCONFIG=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_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

User-preferences (please do not edit this section):
--------------------------------------------------

  EDITOR = /usr/bin/dtemacs
  EXEC_PATH =
/usr/local/libexec/octave/3.1.55/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.1.55/exec/i686-pc-linux-gnu:/usr/local/bin:/home/grb/bin:/opt/maple12/bin/:/opt/pgi/linux86/7.2/bin:/home/grb/work/galene/bin:/usr/totalview/bin:/opt/intel/idb/9.1.049/bin:/opt/intel/fc/9.1.045/bin:/opt/intel/cc/9.1.049/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
  IMAGE_PATH = .:/usr/local/share/octave/3.1.55/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
  history_file = /home/grb/.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 = <no value or error in displaying it>
  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  Thu Aug 27 05:56:50 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 27 Aug 2009 12:56:50 +0200
Subject: int2str doesn't work with int's
In-Reply-To: <53583.91.43.109.179.1251270222.squirrel@webmail.tf.uni-kiel.de>
References: <53583.91.43.109.179.1251270222.squirrel@webmail.tf.uni-kiel.de>
Message-ID: <69d8d540908270356w5901d531pf90219f411f3c616@mail.gmail.com>

On Wed, Aug 26, 2009 at 9:03 AM, <grb at tf.uni-kiel.de> wrote:
> --------
> Bug report for Octave 3.1.55 configured for i686-pc-linux-gnu
>
> Repeat-By:
> ---------
> octave:1> int2str (int32(42))
> error: octave_base_value::log10 (): wrong type argument `int32 scalar'
> error: evaluating argument list element number 1
> error: called from:
> error: ? /usr/local/share/octave/3.1.55/m/general/int2str.m at line 105,
> column 5
> error: evaluating argument list element number 1
> error: ? /usr/local/share/octave/3.1.55/m/general/int2str.m at line 69,
> column 11
>

Please see
http://hg.savannah.gnu.org/hgweb/octave/rev/d73c9bd101ef

thanks

-- 
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  Thu Aug 27 07:07:06 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 27 Aug 2009 14:07:06 +0200
Subject: octave panic calling builtin('subsref', ...)
In-Reply-To: <58373.91.43.109.157.1251370445.squirrel@webmail.tf.uni-kiel.de>
References: <58373.91.43.109.157.1251370445.squirrel@webmail.tf.uni-kiel.de>
Message-ID: <69d8d540908270507i6c47de37q83f947d69676ea63@mail.gmail.com>

On Thu, Aug 27, 2009 at 12:54 PM, <grb at tf.uni-kiel.de> wrote:
> Bug report for Octave 3.1.55 configured for i686-pc-linux-gnu
>
> Description:
> -----------
>
> builtin('subsref', ...) gives unexpected results or fails at all
>
> Repeat-By:
> ---------
>
> @bar/bar.m
> function this = bar(a,b)
> ?this = class(struct('a',a,'b',b), 'bar');
>
> @bar/subsref.m
> function r = subsref(this,idx)
> ?r = builtin('subsref', this, idx);
>
> octave:1> b = bar(42, 'foo')
> octave:2> assert(class(b(1)),'bar')
> error: assert (class (b (1)),'bar') expected
> bar
> but got
> struct
> error: called from:
> error: ? /usr/local/share/octave/3.1.55/m/testfun/assert.m at line 234,
> column 5
> octave:2> assert( b.a, 42 )
> terminate called after throwing an instance of 'std::out_of_range'
> ?what(): ?basic_string::substr
> panic: Aborted -- stopping myself...
> attempting to save variables to `octave-core'...
> save to `octave-core' complete
> Aborted
>
>
>
>
>

please try
http://hg.savannah.gnu.org/hgweb/octave/rev/8bf27324a9d0

-- 
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  Thu Aug 27 09:18:24 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 27 Aug 2009 16:18:24 +0200
Subject: octave panic calling builtin('subsref', ...)
In-Reply-To: <69d8d540908270507i6c47de37q83f947d69676ea63@mail.gmail.com>
References: <58373.91.43.109.157.1251370445.squirrel@webmail.tf.uni-kiel.de>
	<69d8d540908270507i6c47de37q83f947d69676ea63@mail.gmail.com>
Message-ID: <69d8d540908270718u214f3039s52f4c0c3e7999e2@mail.gmail.com>

On Thu, Aug 27, 2009 at 2:07 PM, Jaroslav Hajek<highegg at gmail.com> wrote:
> On Thu, Aug 27, 2009 at 12:54 PM, <grb at tf.uni-kiel.de> wrote:
>> Bug report for Octave 3.1.55 configured for i686-pc-linux-gnu
>>
>> Description:
>> -----------
>>
>> builtin('subsref', ...) gives unexpected results or fails at all
>>
>> Repeat-By:
>> ---------
>>
>> @bar/bar.m
>> function this = bar(a,b)
>> ?this = class(struct('a',a,'b',b), 'bar');
>>
>> @bar/subsref.m
>> function r = subsref(this,idx)
>> ?r = builtin('subsref', this, idx);
>>
>> octave:1> b = bar(42, 'foo')
>> octave:2> assert(class(b(1)),'bar')
>> error: assert (class (b (1)),'bar') expected
>> bar
>> but got
>> struct
>> error: called from:
>> error: ? /usr/local/share/octave/3.1.55/m/testfun/assert.m at line 234,
>> column 5
>> octave:2> assert( b.a, 42 )
>> terminate called after throwing an instance of 'std::out_of_range'
>> ?what(): ?basic_string::substr
>> panic: Aborted -- stopping myself...
>> attempting to save variables to `octave-core'...
>> save to `octave-core' complete
>> Aborted
>>
>>
>>
>>
>>
>
> please try
> http://hg.savannah.gnu.org/hgweb/octave/rev/8bf27324a9d0
>

Oops. Apparently there was a deeper problem behind - see following
patch(es). 3.2.x will get a separate simplistic fix.

John, Robert, does either of you want to look at this?
http://hg.savannah.gnu.org/hgweb/octave/rev/3d0d2bda3a0f

Apparently prior to this patch the dispatch_type stored in
octave_function was allowed to be different from the actual class as
given by pathname. The reason was that only load_path was able to
search parent classes (because it was storing the mappings) and
symbol_table loaded a separate copy for each descendant class, meaning
that a duplicate of the method body (parse tree) was created for each
descendant class (!). This is clearly undesirable, I think.
I think I essentially got that fixed by moving the parent_map to
symbol_table and handling it there. I'm not yet sure, however, whether
this doesn't break something else.
`make check' passes for me.

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From xarthisius.kk at gmail.com  Thu Aug 27 12:59:17 2009
From: xarthisius.kk at gmail.com (Kacper Kowalik)
Date: Thu, 27 Aug 2009 19:59:17 +0200
Subject: Fixing HDF-1.8 API for octave-3.2.x
In-Reply-To: <cf1003df0908270150m1fa05775q42d9e88fe1fd71bc@mail.gmail.com>
References: <cf1003df0908220612u140d4fdj33af43722ca904e5@mail.gmail.com>
	<4A905142.8020308@dbateman.org>
	<cf1003df0908230232p73aef993jc56895e9d59a1c49@mail.gmail.com>
	<19093.59289.539983.77168@segfault.lan>
	<cf1003df0908270150m1fa05775q42d9e88fe1fd71bc@mail.gmail.com>
Message-ID: <cf1003df0908271059x425863ebh9d8e63f4b5c3a4a6@mail.gmail.com>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave-3.2.2-drop-ancient-hdf5.diff
Type: application/octet-stream
Size: 26571 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090827/06ccc499/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave-3.2.2-add-hdf5_18.diff
Type: application/octet-stream
Size: 42383 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090827/06ccc499/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave-3.2.2-simplify_and_prep_for_hdf5-18.diff
Type: application/octet-stream
Size: 2847 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090827/06ccc499/attachment-0005.obj 

From jwe at octave.org  Thu Aug 27 14:43:55 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 27 Aug 2009 15:43:55 -0400
Subject: Another WWMTT item.
In-Reply-To: <4A9614D7.8070700@isl.stanford.edu>
References: <4A931955.4020405@isl.stanford.edu>
	<186E458A-0B77-4847-8DD2-9AE43930D2B4@mac.com>
	<19093.56002.24843.253524@segfault.lan>
	<4A9614D7.8070700@isl.stanford.edu>
Message-ID: <19094.57851.71396.202725@segfault.lan>

On 26-Aug-2009, Michael D Godfrey wrote:

| On 08/26/2009 06:00 PM, John W. Eaton wrote:
| > So should we really encourage this
| > kind of sloppy programming?  How essential is it for compatibility?
| >
| >    
| I am a bit sorry that I started this.  I did not intend that
| matching Matlab in their sloppy matching should be
| implemented.  I agree that this would likely lead to
| problems in the future that would be worse than any
| benefit now.  The diagnostic when a property match fails
| could be improved though...  The stem match could be done
| and then fail with a diagnostic like:  for Render, did you
| really mean Renderer?   (Learn from Google???)

OK, I checked in the following change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/bdcfb756d721

With it, I see

  octave:1> get (gcf, 'x')
  error: get: ambiguous property name x; possible matches:

  xdisplay     xvisual      xvisualmode

  octave:1> get (gcf, 'create')
  error: get: instead of create, did you mean createfcn?

It would be easy enough to modify this so that in the latter case, we
could just accept the short version in place of the full property
name.  But I'm still not convinced that is good behavior.  If we do
decide to be Matlab compatible here, then I think we should at least
emit an optional warning.  I'd vote for it being on by default.

Thanks,

jwe

From godfrey at isl.stanford.edu  Thu Aug 27 15:00:41 2009
From: godfrey at isl.stanford.edu (Michael Godfrey)
Date: Thu, 27 Aug 2009 13:00:41 -0700
Subject: Another WWMTT item.
In-Reply-To: <19094.57851.71396.202725@segfault.lan>
References: <4A931955.4020405@isl.stanford.edu>	<186E458A-0B77-4847-8DD2-9AE43930D2B4@mac.com>	<19093.56002.24843.253524@segfault.lan>	<4A9614D7.8070700@isl.stanford.edu>
	<19094.57851.71396.202725@segfault.lan>
Message-ID: <4A96E5E9.3070607@isl.stanford.edu>

On 08/27/2009 12:43 PM, John W. Eaton wrote:
> OK, I checked in the following change.
>
>    http://hg.savannah.gnu.org/hgweb/octave/rev/bdcfb756d721
>
> With it, I see
>
>    octave:1>  get (gcf, 'x')
>    error: get: ambiguous property name x; possible matches:
>
>    xdisplay     xvisual      xvisualmode
>
>    octave:1>  
This looks great to me.  This is the right thing to do, and will also help
users who just get a property a bit wrong in any case.

Thanks very much,
Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090827/3ec1d8b3/attachment.html 

From godfrey at isl.stanford.edu  Thu Aug 27 15:09:11 2009
From: godfrey at isl.stanford.edu (Michael Godfrey)
Date: Thu, 27 Aug 2009 13:09:11 -0700
Subject: gnuplot 4.3 question
In-Reply-To: <4A96DE4F.9040306@dbateman.org>
References: <4A947231.3070303@isl.stanford.edu>
	<F5BFE3EC-916D-4F6E-8D42-959678CF841C@mac.com>
	<4A95B082.9060604@dbateman.org> <4A95B0F2.3090500@isl.stanford.edu>
	<4A95C129.50002@dbateman.org> <4A9615FF.8040203@isl.stanford.edu>
	<4A96DE4F.9040306@dbateman.org>
Message-ID: <4A96E7E7.9000105@isl.stanford.edu>

On 08/27/2009 12:28 PM, David Bateman wrote:
> The only thing I can think of is to modify the error message like
>
> error("filled polygon with %d sides detected. gnuplot (as of v4.2) 
> only supports 3D filled triangular patches", numel (xcol)) 
In the meantime I tried  backend ("fltk").   This seems to do several of 
the plots
that gnuplot could not handle.  However, it tends to seg fault so I had 
to run it
under gdb.  In this case the plot stayed on the screen after the seg 
fault so I could
see how it looked.  The seg fault was always at the same place and I 
thing I can
get a simple case that causes seg fault and will send it in.

It may be that some time spent on fltk would be helpful.

More as soon as I can get test case together.

Michael


From godfrey at isl.stanford.edu  Thu Aug 27 22:06:55 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Thu, 27 Aug 2009 20:06:55 -0700
Subject: A backend("fltk") problem
Message-ID: <4A9749CF.6030708@isl.stanford.edu>

When experimenting with the current fltk I have found that
it often seg faults at the same place.  In some complicated
plots the fault occurs without use of "title" commands.  However,
these cases would require a lot of code and setup.
The plot has been drawn by the time the seg fault occurs in
all cases.

This happened using yesterday's hg repository.

I noticed that the same seg fault occurs in this simple
example:
============================================
[godfrey-pbdsl3.stanford.edu:godfrey] gdb octave
GNU gdb (GDB) Fedora (6.8.50.20090302-37.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
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 "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) run
Starting program: /usr/local/bin/octave
[Thread debugging using libthread_db enabled]
GNU Octave, version 3.1.55
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 <bug at octave.org> (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> backend("fltk");
octave:2> plot([1:20])
octave:3> title("123");
octave:4> error: could not match any font: *-normal-normal-12
error: ft_manager: unable to load font:
error: ft_render: unable to load appropriate font
error: could not match any font: *-normal-normal-12
error: ft_manager: unable to load font:
error: ft_render: unable to load appropriate font
error: ft_render: font not initialized

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7329273 in octave_value::~octave_value (this=<value optimized 
out>, __in_chrg=<value optimized out>)
     at ov.h:297
297        if (--rep->count == 0)
Current language:  auto; currently c++
Missing separate debuginfos, use: debuginfo-install 
arpack-2.1-11.fc11.x86_64 atlas-3.8.3-4.fc11.x86_64 
blas-3.1.1-5.fc11.x86_64 expat-2.0.1-6.x86_64 fftw-3.2.1-2.fc11.x86_64 
fltk-1.1.9-4.fc11.x86_64 fontconfig-2.7.1-1.fc11.x86_64 
freetype-2.3.9-5.fc11.x86_64 ftgl-2.1.2-10.fc11.x86_64 
glibc-2.10.1-4.x86_64 hdf5-1.8.3-1.fc11.x86_64 
libX11-1.2.2-1.fc11.x86_64 libXau-1.0.4-5.fc11.x86_64 
libXext-1.0.99.1-2.fc11.x86_64 libXft-2.1.13-2.fc11.x86_64 
libXinerama-1.0.3-4.fc11.x86_64 libXrender-0.9.4-5.fc11.x86_64 
libgcc-4.4.1-2.fc11.x86_64 libgfortran-4.4.1-2.fc11.x86_64 
libstdc++-4.4.1-2.fc11.x86_64 libxcb-1.2-4.fc11.x86_64 
mesa-libGLU-7.6-0.1.fc11.x86_64 ncurses-libs-5.7-2.20090207.fc11.x86_64 
pcre-7.8-2.fc11.x86_64 readline-5.2-14.fc11.x86_64 
suitesparse-3.2.0-6.fc11.x86_64 zlib-1.2.3-22.fc11.x86_64
(gdb)
===============================================
In the other cases the font errors also do not occur, but the seg
fault is exactly the same line 297 of ov.h.

Due to optimization, I could not get much useful information from
gdb, but this example should be easily reproduced.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090827/362fda93/attachment.html 

From godfrey at isl.stanford.edu  Thu Aug 27 22:59:02 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Thu, 27 Aug 2009 20:59:02 -0700
Subject: property name handling
Message-ID: <4A975606.5020501@isl.stanford.edu>

John,

You may have already noticed this minor problem
with your new property name handling.  This happened during
a build from current hg.

../../run-octave -f -q -H -p . --eval "plotimages ('plot', 'txt');"
error: get: ambiguous property name paperposition; possible matches:

paperposition      paperpositionmode


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090827/aa002281/attachment.html 

From jwe at octave.org  Thu Aug 27 23:09:29 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 28 Aug 2009 00:09:29 -0400
Subject: property name handling
In-Reply-To: <4A975606.5020501@isl.stanford.edu>
References: <4A975606.5020501@isl.stanford.edu>
Message-ID: <19095.22649.874705.430025@segfault.lan>

On 27-Aug-2009, Michael D Godfrey wrote:

| You may have already noticed this minor problem
| with your new property name handling.  This happened during
| a build from current hg.
| 
| ../../run-octave -f -q -H -p . --eval "plotimages ('plot', 'txt');"
| error: get: ambiguous property name paperposition; possible matches:
| 
| paperposition      paperpositionmode

Yes, oops.  I'll fix this tomorrow if someone doesn't beat me to it.
I think the fix is:

  each time there is a match, check to see whether the match is
  exact.  If it is, return immediately.

jwe

From jpswensen at comcast.net  Fri Aug 28 00:35:42 2009
From: jpswensen at comcast.net (John Swensen)
Date: Fri, 28 Aug 2009 01:35:42 -0400
Subject: property name handling
In-Reply-To: <19095.22649.874705.430025@segfault.lan>
References: <4A975606.5020501@isl.stanford.edu>
	<19095.22649.874705.430025@segfault.lan>
Message-ID: <7B449A8C-2347-46E9-8ED7-6E7F19A9D76B@comcast.net>


On Aug 28, 2009, at 12:09 AM, John W. Eaton wrote:

> On 27-Aug-2009, Michael D Godfrey wrote:
>
> | You may have already noticed this minor problem
> | with your new property name handling.  This happened during
> | a build from current hg.
> |
> | ../../run-octave -f -q -H -p . --eval "plotimages ('plot', 'txt');"
> | error: get: ambiguous property name paperposition; possible matches:
> |
> | paperposition      paperpositionmode
>
> Yes, oops.  I'll fix this tomorrow if someone doesn't beat me to it.
> I think the fix is:
>
>  each time there is a match, check to see whether the match is
>  exact.  If it is, return immediately.
>
> jwe
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

As a related sidenote (and I know we don't always match Matlab  
"features"), but a labmate of mine commented to me the other day that  
to set a handle property in Matlab, you really only need the first  
unique set of characters for a given property.  That is, if the  
property is 'Renderer' and there are no other properties that start  
with 'Re', then you can use 'Re' instead of 'Renderer'.  Not that this  
ends up being useful for anything other than confusing any other  
person to ever look at your code, but interesting nonetheless.

John Swensen

From jwe at octave.org  Fri Aug 28 04:43:02 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 28 Aug 2009 05:43:02 -0400
Subject: property name handling
In-Reply-To: <7B449A8C-2347-46E9-8ED7-6E7F19A9D76B@comcast.net>
References: <4A975606.5020501@isl.stanford.edu>
	<19095.22649.874705.430025@segfault.lan>
	<7B449A8C-2347-46E9-8ED7-6E7F19A9D76B@comcast.net>
Message-ID: <19095.42662.785654.798607@segfault.lan>

On 28-Aug-2009, John Swensen wrote:

| As a related sidenote (and I know we don't always match Matlab  
| "features"), but a labmate of mine commented to me the other day that  
| to set a handle property in Matlab, you really only need the first  
| unique set of characters for a given property.  That is, if the  
| property is 'Renderer' and there are no other properties that start  
| with 'Re', then you can use 'Re' instead of 'Renderer'.  Not that this  
| ends up being useful for anything other than confusing any other  
| person to ever look at your code, but interesting nonetheless.

Yes, I think that's why this problem was originally reported.

I made the following additional change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/0fcbfddaa87f

Now I see

  octave:1> plot (1:20)
  octave:2> get (gca, 'xlim')
  ans =

      0   20

  octave:3> get (gca, 'xlimmode')
  ans = auto
  octave:4> get (gcf, 'create')
  warning: get: allowing create to match createfcn
  ans = [](0x0)
  octave:5> warning off Octave:abbreviated-property-match
  octave:6> get (gcf, 'create')
  ans = [](0x0)
  octave:7> get (gcf, 'x')
  error: get: ambiguous property name x; possible matches:

  xdisplay     xvisual      xvisualmode

  octave:7> get (gcf, 'foobar')
  error: get: unknown property foobar

The check is the same in the set function.  So now

  * things work properly again for exact matches, even when there is a
    long name that would also match

  * we get a warning by default if the property name is abbreviated

  * the warning can be disabled (and is disabled by --traditional)

  * an error is issued if the property name is ambiguous

  * a separate error is issued if the property name does not exist

Does that cover all the cases?

jwe

From bpabbott at mac.com  Fri Aug 28 08:08:59 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Fri, 28 Aug 2009 09:08:59 -0400
Subject: property name handling
In-Reply-To: <19095.42662.785654.798607@segfault.lan>
References: <4A975606.5020501@isl.stanford.edu>
	<19095.22649.874705.430025@segfault.lan>
	<7B449A8C-2347-46E9-8ED7-6E7F19A9D76B@comcast.net>
	<19095.42662.785654.798607@segfault.lan>
Message-ID: <65B7AD43-C86C-4412-9093-740B6008B3CC@mac.com>


On Aug 28, 2009, at 5:43 AM, John W. Eaton wrote:

> On 28-Aug-2009, John Swensen wrote:
>
> | As a related sidenote (and I know we don't always match Matlab
> | "features"), but a labmate of mine commented to me the other day  
> that
> | to set a handle property in Matlab, you really only need the first
> | unique set of characters for a given property.  That is, if the
> | property is 'Renderer' and there are no other properties that start
> | with 'Re', then you can use 'Re' instead of 'Renderer'.  Not that  
> this
> | ends up being useful for anything other than confusing any other
> | person to ever look at your code, but interesting nonetheless.
>
> Yes, I think that's why this problem was originally reported.
>
> I made the following additional change.
>
>  http://hg.savannah.gnu.org/hgweb/octave/rev/0fcbfddaa87f
>
> Now I see
>
>  octave:1> plot (1:20)
>  octave:2> get (gca, 'xlim')
>  ans =
>
>      0   20
>
>  octave:3> get (gca, 'xlimmode')
>  ans = auto
>  octave:4> get (gcf, 'create')
>  warning: get: allowing create to match createfcn
>  ans = [](0x0)
>  octave:5> warning off Octave:abbreviated-property-match
>  octave:6> get (gcf, 'create')
>  ans = [](0x0)
>  octave:7> get (gcf, 'x')
>  error: get: ambiguous property name x; possible matches:
>
>  xdisplay     xvisual      xvisualmode
>
>  octave:7> get (gcf, 'foobar')
>  error: get: unknown property foobar
>
> The check is the same in the set function.  So now
>
>  * things work properly again for exact matches, even when there is a
>    long name that would also match
>
>  * we get a warning by default if the property name is abbreviated
>
>  * the warning can be disabled (and is disabled by --traditional)
>
>  * an error is issued if the property name is ambiguous
>
>  * a separate error is issued if the property name does not exist
>
> Does that cover all the cases?
>
> jwe

I have a new build failure ... perhaps it is related?

./munge-texi  -d ../../src/DOCSTRINGS  -d ../../scripts/DOCSTRINGS <  
var.txi > var.texi-t
mv var.texi-t var.texi
gawk -f ./mkcontrib.awk ./contributors.in > contributors.texi-t
mv contributors.texi-t contributors.texi
makeinfo -I.. -I. -I./.. ./octave.texi
../../run-octave -f -q -H -p . --eval "sparseimages ('gplot', 'eps');"
error: get: unknown property __pixels_per_inch__
error: called from:
error:   /Users/bpabbott/Development/mercurial/local_clone/scripts/ 
plot/print.m at line 707, column 7
error:   /Users/bpabbott/Development/mercurial/local_clone/doc/ 
interpreter/sparseimages.m at line 54, column 3
error:   /Users/bpabbott/Development/mercurial/local_clone/doc/ 
interpreter/sparseimages.m at line 30, column 2

make[3]: *** [gplot.eps] Error 1
make[2]: *** [interpreter] Error 2
make[1]: *** [doc] Error 2
make: *** [all] Error 2

Ben


From jwe at octave.org  Fri Aug 28 17:39:09 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 28 Aug 2009 18:39:09 -0400
Subject: property name handling
In-Reply-To: <65B7AD43-C86C-4412-9093-740B6008B3CC@mac.com>
References: <4A975606.5020501@isl.stanford.edu>
	<19095.22649.874705.430025@segfault.lan>
	<7B449A8C-2347-46E9-8ED7-6E7F19A9D76B@comcast.net>
	<19095.42662.785654.798607@segfault.lan>
	<65B7AD43-C86C-4412-9093-740B6008B3CC@mac.com>
Message-ID: <19096.23693.416624.418340@segfault.lan>

On 28-Aug-2009, Ben Abbott wrote:

| I have a new build failure ... perhaps it is related?
| 
| ./munge-texi  -d ../../src/DOCSTRINGS  -d ../../scripts/DOCSTRINGS <  
| var.txi > var.texi-t
| mv var.texi-t var.texi
| gawk -f ./mkcontrib.awk ./contributors.in > contributors.texi-t
| mv contributors.texi-t contributors.texi
| makeinfo -I.. -I. -I./.. ./octave.texi
| ../../run-octave -f -q -H -p . --eval "sparseimages ('gplot', 'eps');"
| error: get: unknown property __pixels_per_inch__
| error: called from:
| error:   /Users/bpabbott/Development/mercurial/local_clone/scripts/ 
| plot/print.m at line 707, column 7
| error:   /Users/bpabbott/Development/mercurial/local_clone/doc/ 
| interpreter/sparseimages.m at line 54, column 3
| error:   /Users/bpabbott/Development/mercurial/local_clone/doc/ 
| interpreter/sparseimages.m at line 30, column 2
| 
| make[3]: *** [gplot.eps] Error 1
| make[2]: *** [interpreter] Error 2
| make[1]: *** [doc] Error 2
| make: *** [all] Error 2

I checked in an additional change that seems to fix this problem.

  http://hg.savannah.gnu.org/hgweb/octave/rev/06b8b51dca48

With some luck, maybe I didn't introduce any other new problems.

jwe

From bpabbott at mac.com  Fri Aug 28 20:52:36 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Fri, 28 Aug 2009 21:52:36 -0400
Subject: property name handling
In-Reply-To: <19096.23693.416624.418340@segfault.lan>
References: <4A975606.5020501@isl.stanford.edu>
	<19095.22649.874705.430025@segfault.lan>
	<7B449A8C-2347-46E9-8ED7-6E7F19A9D76B@comcast.net>
	<19095.42662.785654.798607@segfault.lan>
	<65B7AD43-C86C-4412-9093-740B6008B3CC@mac.com>
	<19096.23693.416624.418340@segfault.lan>
Message-ID: <29540C1A-233E-4F42-8118-47DF2F4C9AEB@mac.com>


On Aug 28, 2009, at 6:39 PM, John W. Eaton wrote:

> On 28-Aug-2009, Ben Abbott wrote:
>
> | I have a new build failure ... perhaps it is related?
> |
> | ./munge-texi  -d ../../src/DOCSTRINGS  -d ../../scripts/DOCSTRINGS <
> | var.txi > var.texi-t
> | mv var.texi-t var.texi
> | gawk -f ./mkcontrib.awk ./contributors.in > contributors.texi-t
> | mv contributors.texi-t contributors.texi
> | makeinfo -I.. -I. -I./.. ./octave.texi
> | ../../run-octave -f -q -H -p . --eval "sparseimages ('gplot',  
> 'eps');"
> | error: get: unknown property __pixels_per_inch__
> | error: called from:
> | error:   /Users/bpabbott/Development/mercurial/local_clone/scripts/
> | plot/print.m at line 707, column 7
> | error:   /Users/bpabbott/Development/mercurial/local_clone/doc/
> | interpreter/sparseimages.m at line 54, column 3
> | error:   /Users/bpabbott/Development/mercurial/local_clone/doc/
> | interpreter/sparseimages.m at line 30, column 2
> |
> | make[3]: *** [gplot.eps] Error 1
> | make[2]: *** [interpreter] Error 2
> | make[1]: *** [doc] Error 2
> | make: *** [all] Error 2
>
> I checked in an additional change that seems to fix this problem.
>
>  http://hg.savannah.gnu.org/hgweb/octave/rev/06b8b51dca48
>
> With some luck, maybe I didn't introduce any other new problems.
>
> jwe

In what may have been a gross error of judgement, I upgraded to  
Apple's new OS today. Now I get the error below.

checking whether closedir returns void... no
checking for struct group.gr_passwd... no
checking if mkdir takes one argument... no
checking for tputs in -lncurses... no
checking for tputs in -lcurses... no
checking for tputs in -ltermcap... no
checking for tputs in -lterminfo... no
checking for tputs in -ltermlib... no
configure: WARNING: I couldn't find -ltermcap, -lterminfo, -lncurses, - 
lcurses, or -ltermlib!
checking for rl_set_keyboard_input_timeout in -lreadline... no
configure: WARNING: I need GNU Readline 4.2 or later
configure: error: this is fatal unless you specify --disable-readline

Thus, I cannot confirm John's changeset fixed the problem for me. Can  
someone else check?

Ben




From godfrey at isl.stanford.edu  Fri Aug 28 21:43:32 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Fri, 28 Aug 2009 19:43:32 -0700
Subject: property name handling
In-Reply-To: <29540C1A-233E-4F42-8118-47DF2F4C9AEB@mac.com>
References: <4A975606.5020501@isl.stanford.edu>
	<19095.22649.874705.430025@segfault.lan>
	<7B449A8C-2347-46E9-8ED7-6E7F19A9D76B@comcast.net>
	<19095.42662.785654.798607@segfault.lan>
	<65B7AD43-C86C-4412-9093-740B6008B3CC@mac.com>
	<19096.23693.416624.418340@segfault.lan>
	<29540C1A-233E-4F42-8118-47DF2F4C9AEB@mac.com>
Message-ID: <4A9895D4.5020103@isl.stanford.edu>

On 08/28/2009 06:52 PM, Ben Abbott wrote:
> Thus, I cannot confirm John's changeset fixed the problem for me. Can 
> someone else check? 

The latest patch works for me (linux FC11x86_64).  I  also tried a few 
"Matlab"
properties and got the expected (and clear) results.

Thanks very much John!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090828/2afd3ff3/attachment.html 

From christophe.tournery at illusonic.com  Sat Aug 29 04:46:50 2009
From: christophe.tournery at illusonic.com (Christophe Tournery)
Date: Sat, 29 Aug 2009 11:46:50 +0200
Subject: wavread(..., 'size') bug in 3.2.0
In-Reply-To: <F610C3E8-DFFD-43DC-81DF-346E9A6B3948@illusonic.com>
References: <F610C3E8-DFFD-43DC-81DF-346E9A6B3948@illusonic.com>
Message-ID: <615AE594-8CF3-4E04-BB5B-DB9F7966C771@illusonic.com>

Hi Octave developers,

Attached is a hg patch for wavread in order to restore the  
functionality wavread("filename.wav", "size").
This applies to Octave 3.2.2.
See previous bug description below.

Bests,
Christophe

On Jul 6, 2009, at 11:32 AM, Christophe Tournery wrote:

> Bug report for Octave 3.2.0 configured for i386-apple-darwin9.7.0
>
> Description:
> -----------
>
>  * The new version of wavread in octave 3.2.0 does not work anymore  
> for
>    querying the size of a wavfile. Here is the error message:
>
> octave:1> [nsamp, nchan] = wavread('../audio/in.wav', 'size')
> error: `ck_size' undefined near line 172 column 12
> error: called from:
> error:   /opt/local/share/octave/3.2.0/m/audio/wavread.m at line 172,
> column 9
>
>
> Repeat-By:
> ---------
>
>  * [nsamp, nchan] = wavread('path_to_wavfile.wav', 'size')


-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave_wavread_size.patch
Type: application/octet-stream
Size: 3734 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090829/56c683c5/attachment.obj 

From stefan at konink.de  Sat Aug 29 18:51:01 2009
From: stefan at konink.de (Stefan de Konink)
Date: Sun, 30 Aug 2009 01:51:01 +0200
Subject: Incorrect large number computation
Message-ID: <4A99BEE5.3020105@konink.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Description:
- -----------

I was trying to do some simple big number computations around 2^64 but
for some reason adding did not work. 2^63 + 1 for example results in the
same value. While increasing it with a larger value does increases it.

So tried some other values after the people on IRC pointed me out octave
is correct up to 16 values.


Repeat-By:
- ---------

(01:19:04) Skinkie: ans =  4503599627370496
(01:19:04) Skinkie: octave:88> (2^52) + 1
(01:19:04) Skinkie: ans =  4.50359962737050e+15
(01:19:04) Skinkie: octave:89> (2^52) + 2
(01:19:04) Skinkie: ans =  4503599627370498
(01:19:04) Skinkie: octave:90> (2^52) + 3
(01:19:04) Skinkie: ans =  4.50359962737050e+15


Configuration (please do not edit this section):
- -----------------------------------------------

uname output:     Linux nemesis 2.6.30-gentoo-r1 #2 SMP PREEMPT Sat Aug
15 16:34:20 CEST 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor
5200+ AuthenticAMD GNU/Linux
configure opts:   '--prefix=/usr' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--libdir=/usr/lib64' '--localstatedir=/var/state/octave'
'--enable-shared' '--with-blas=-lblas -latlas -lpthread  '
'--with-lapack=-llapack -lblas -lpthread -lcblas -latlas  '
'--without-hdf5' '--with-curl' '--with-zlib' '--without-fftw'
'--without-umfpack' '--without-colamd' '--without-ccolamd'
'--without-cholmod' '--without-cxsparse' '--enable-readline'
'--build=x86_64-pc-linux-gnu' 'build_alias=x86_64-pc-linux-gnu'
'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=athlon64 -O2 -pipe
- -msse3' 'CXXFLAGS=-march=athlon64 -O2 -pipe -msse3'
Fortran compiler: x86_64-pc-linux-gnu-gfortran
FFLAGS:           -O
F2C:              @F2C@
F2CFLAGS:         @F2CFLAGS@
FLIBS:            -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2
- -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib64
- -L/lib/../lib64 -L/usr/lib/../lib64
-
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib
- -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. -lz -lgfortranbegin
- -lgfortran -lm
CPPFLAGS:
INCFLAGS:         -I. -I. -I./liboctave -I./src -I./libcruft/misc
C compiler:       x86_64-pc-linux-gnu-gcc, version 4.3.2 (Gentoo 4.3.2 p1.0)
CFLAGS:           -march=athlon64 -O2 -pipe -msse3
CPICFLAG:         -fPIC
C++ compiler:     x86_64-pc-linux-gnu-g++, version 4.3.2
CXXFLAGS:         -march=athlon64 -O2 -pipe -msse3
CXXPICFLAG:       -fPIC
LD_CXX:           x86_64-pc-linux-gnu-g++
LDFLAGS:
LIBFLAGS:         -L.
RLD_FLAG:         -Wl,-rpath -Wl,/usr/lib64/octave-3.0.3
BLAS_LIBS:        -llapack -lblas -lpthread -lcblas -latlas   -lblas
- -latlas -lpthread
FFTW_LIBS:
LIBS:             -lreadline  -lncurses -ldl -lz -lm
LEXLIB:
LIBGLOB:
SED:              /usr/libexec/paludis/utils/sed
DEFS:


User-preferences (please do not edit this section):
- --------------------------------------------------
  EDITOR = /bin/nano
  EXEC_PATH =
/usr/libexec/octave/3.0.3/site/exec/x86_64-pc-linux-gnu:/usr/libexec/octave/api-v32/site/exec/x86_64-pc-linux-gnu:/usr/libexec/octave/site/exec/x86_64-pc-linux-gnu:/usr/libexec/octave/3.0.3/exec/x86_64-pc-linux-gnu:/usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/mnt/dv/cris/bin:/usr/x86_64-pc-linux-gnu/crisv32-axis-linux-gnu/gcc-bin/4.3.1:/usr/x86_64-pc-linux-gnu/crisv32-axis-linux-uclibc/gcc-bin/4.3.1:/usr/x86_64-pc-linux-gnu/i686-mingw32/gcc-bin/4.3.2:/usr/x86_64-pc-linux-gnu/mipsel-linux-uclibc/gcc-bin/3.4.6:/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.1:/usr/games/bin:/opt/cherokee/bin
  IMAGE_PATH = .:/usr/share/octave/3.0.3/imagelib
  PAGER = /usr/bin/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/skinkie/.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = /usr/share/info/octave.info
  info_program = info
  makeinfo_program = makeinfo
  max_recursion_depth = 256
  output_max_field_width = 15
  output_precision = 15
  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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkqZvuUACgkQYH1+F2Rqwn2f4wCdHBD6GJZCnXxjl0vTilmZO6Zv
XJIAnRn0a1+mKgjn+hQFnytLOBnpxNiA
=cdHm
-----END PGP SIGNATURE-----

From jwe at octave.org  Sat Aug 29 21:26:32 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 29 Aug 2009 22:26:32 -0400
Subject: Incorrect large number computation
In-Reply-To: <4A99BEE5.3020105@konink.de>
References: <4A99BEE5.3020105@konink.de>
Message-ID: <19097.58200.766963.14616@segfault.lan>

On 30-Aug-2009, Stefan de Konink wrote:

| Description:
| - -----------
| 
| I was trying to do some simple big number computations around 2^64 but
| for some reason adding did not work. 2^63 + 1 for example results in the
| same value. While increasing it with a larger value does increases it.
| 
| So tried some other values after the people on IRC pointed me out octave
| is correct up to 16 values.
| 
| 
| Repeat-By:
| - ---------
| 
| (01:19:04) Skinkie: ans =  4503599627370496
| (01:19:04) Skinkie: octave:88> (2^52) + 1
| (01:19:04) Skinkie: ans =  4.50359962737050e+15
| (01:19:04) Skinkie: octave:89> (2^52) + 2
| (01:19:04) Skinkie: ans =  4503599627370498
| (01:19:04) Skinkie: octave:90> (2^52) + 3
| (01:19:04) Skinkie: ans =  4.50359962737050e+15

This is not a bug.  Values in Octave are double precision floating
point values by default, and Octave is not intended to do arbitrary
precision calculations.

jwe

From stefan at konink.de  Sat Aug 29 22:04:41 2009
From: stefan at konink.de (Stefan de Konink)
Date: Sun, 30 Aug 2009 05:04:41 +0200
Subject: Incorrect large number computation
In-Reply-To: <19097.58200.766963.14616@segfault.lan>
References: <4A99BEE5.3020105@konink.de>
	<19097.58200.766963.14616@segfault.lan>
Message-ID: <4A99EC49.3050808@konink.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

John W. Eaton schreef:
> | (01:19:04) Skinkie: ans =  4503599627370496
> | (01:19:04) Skinkie: octave:88> (2^52) + 1
> | (01:19:04) Skinkie: ans =  4.50359962737050e+15
> | (01:19:04) Skinkie: octave:89> (2^52) + 2
> | (01:19:04) Skinkie: ans =  4503599627370498
> | (01:19:04) Skinkie: octave:90> (2^52) + 3
> | (01:19:04) Skinkie: ans =  4.50359962737050e+15
> 
> This is not a bug.  Values in Octave are double precision floating
> point values by default, and Octave is not intended to do arbitrary
> precision calculations.

Though I find the above behavior, not showing 4503599627370497 rather
odd. You mention 'by default', is there a way to get it to operate in a
broader range of values?


Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkqZ7EkACgkQYH1+F2Rqwn3BNACfVK3aFqTXGPfz4bEcEs9VfswF
0/MAn2hOwD6RYur73H71WttwvUxV+zWY
=FODY
-----END PGP SIGNATURE-----

From highegg at gmail.com  Sun Aug 30 03:00:25 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sun, 30 Aug 2009 10:00:25 +0200
Subject: Incorrect large number computation
In-Reply-To: <4A99EC49.3050808@konink.de>
References: <4A99BEE5.3020105@konink.de>
	<19097.58200.766963.14616@segfault.lan> <4A99EC49.3050808@konink.de>
Message-ID: <69d8d540908300100u6ccf474bh6770f998cd31c577@mail.gmail.com>

On Sun, Aug 30, 2009 at 5:04 AM, Stefan de Konink<stefan at konink.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> John W. Eaton schreef:
>> | (01:19:04) Skinkie: ans = ?4503599627370496
>> | (01:19:04) Skinkie: octave:88> (2^52) + 1
>> | (01:19:04) Skinkie: ans = ?4.50359962737050e+15
>> | (01:19:04) Skinkie: octave:89> (2^52) + 2
>> | (01:19:04) Skinkie: ans = ?4503599627370498
>> | (01:19:04) Skinkie: octave:90> (2^52) + 3
>> | (01:19:04) Skinkie: ans = ?4.50359962737050e+15
>>
>> This is not a bug. ?Values in Octave are double precision floating
>> point values by default, and Octave is not intended to do arbitrary
>> precision calculations.
>
> Though I find the above behavior, not showing 4503599627370497 rather
> odd. You mention 'by default', is there a way to get it to operate in a
> broader range of values?
>
>

You can work with 64-bit integers, if that's enough for you.

octave:1> a = int64(2^52)
a = 4503599627370496
octave:2> a+1
ans = 4503599627370497
octave:3> a+a+1
ans = 9007199254740993

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


From sergstesh at yahoo.com  Sun Aug 30 08:38:06 2009
From: sergstesh at yahoo.com (Sergei Steshenko)
Date: Sun, 30 Aug 2009 06:38:06 -0700 (PDT)
Subject: Incorrect large number computation
In-Reply-To: <4A99EC49.3050808@konink.de>
Message-ID: <563393.53756.qm@web35203.mail.mud.yahoo.com>



--- On Sat, 8/29/09, Stefan de Konink <stefan at konink.de> wrote:

> From: Stefan de Konink <stefan at konink.de>
> Subject: Re: Incorrect large number computation
> To: "John W. Eaton" <jwe at octave.org>
> Cc: bug at octave.org
> Date: Saturday, August 29, 2009, 8:04 PM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> John W. Eaton schreef:
> > | (01:19:04) Skinkie: ans =? 4503599627370496
> > | (01:19:04) Skinkie: octave:88> (2^52) + 1
> > | (01:19:04) Skinkie: ans =?
> 4.50359962737050e+15
> > | (01:19:04) Skinkie: octave:89> (2^52) + 2
> > | (01:19:04) Skinkie: ans =? 4503599627370498
> > | (01:19:04) Skinkie: octave:90> (2^52) + 3
> > | (01:19:04) Skinkie: ans =?
> 4.50359962737050e+15
> > 
> > This is not a bug.? Values in Octave are double
> precision floating
> > point values by default, and Octave is not intended to
> do arbitrary
> > precision calculations.
> 
> Though I find the above behavior, not showing
> 4503599627370497 rather
> odd. You mention 'by default', is there a way to get it to
> operate in a
> broader range of values?
> 
> 
> Stefan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEAREKAAYFAkqZ7EkACgkQYH1+F2Rqwn3BNACfVK3aFqTXGPfz4bEcEs9VfswF
> 0/MAn2hOwD6RYur73H71WttwvUxV+zWY
> =FODY
> -----END PGP SIGNATURE-----


Not by default the values can become single precision floating point 
numbers.

...

Before filing such bugs one should carefully read, say,

http://en.wikipedia.org/wiki/Floating-point_number
.

...

Various languages have various higher precision packages which work slower.

Examples:

http://perldoc.perl.org/Math/BigFloat.html
http://search.cpan.org/~tels/Math-Big-1.12/lib/Math/Big.pm
http://perldoc.perl.org/Math/BigInt.html
http://search.cpan.org/~tels/Math-BigRat-0.22/lib/Math/BigRat.pm

Regards,
  Sergei.


      


From felix.buehlmann at acousticimplants.com  Mon Aug 31 00:35:33 2009
From: felix.buehlmann at acousticimplants.com (=?UTF-8?Q?F=C3=A9lixB?=)
Date: Sun, 30 Aug 2009 22:35:33 -0700 (PDT)
Subject: Error in wavread
Message-ID: <25218546.post@talk.nabble.com>


Bug report for Octave 3.2.2 configured for i686-pc-mingw32

Description:
-----------
Hello

I get an error when using wavread with the argument 'size' 

This error is also in Octave 3.2.0, but not in 3.0.5

Calling : Ns = wavread(Fname,'size') ;

error: `ck_size' undefined near line 172 column 12
error: called from:
error:   C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\audio\wavread.m at
line 172, column 9

Thank's for you help

Felix

Configuration (please do not edit this section):
-----------------------------------------------

uname output:     Windows
configure opts:   
Fortran compiler: mingw32-gfortran-4.3.0-dw2
FFLAGS:           -O -mieee-fp
FLIBS:            -lgfortran
CPPFLAGS:         -march=i686 -mtune=generic -O2 
INCFLAGS:         -I. -I/octmgw32/octave/octave-3.2.2 -I. -I./liboctave
-I./src -I./libcruft/misc -I/octmgw32/octave/octave-3.2.2
-I/octmgw32/octave/octave-3.2.2/liboctave
-I/octmgw32/octave/octave-3.2.2/src
-I/octmgw32/octave/octave-3.2.2/libcruft/misc
C compiler:       mingw32-gcc-4.3.0-dw2, version4.3.0-dw2 (GCC TDM-2 for
MinGW) 
CFLAGS:           -Wall
CPICFLAG:         
C++ compiler:     mingw32-g++-4.3.0-dw2, version4.3.0-dw2
CXXFLAGS:         -D_DLL -Wall
CXXPICFLAG:       
LD_CXX:           mingw32-g++-4.3.0-dw2
LDFLAGS:          -shared-libgcc -Wl,--exclude-libs=-lstdc++_s
-Wl,--allow-multiple-definition
LIBFLAGS:         -L.
RLD_FLAG:         
BLAS_LIBS:        -llapack -lblas
FFTW_LIBS:        -lfftw3 -lfftw3f
LIBS:             -lreadline  -lncurses -liberty -lblas -lhdf5 -lz -lm 
-lgdi32 -lws2_32 -luser32 -lkernel32
LEXLIB:           
LIBGLOB:          -lglob
SED:              /usr/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_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_GLPK_H=1 -DHAVE_GLPK=1
-DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_WINDOWS_H=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 -Duid_t=int
-Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_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=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_ASSERT_H=1 -DHAVE_CURSES_H=1
-DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NCURSES_H=1
-DHAVE_PTHREAD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1
-DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1
-DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1
-DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 -DHAVE_EXPM1F=1
-DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE_GETTIMEOFDAY=1
-DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LOG1P=1
-DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_PUTENV=1
-DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1
-DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1
-DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1
-DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 -DHAVE_TGAMMAF=1
-DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_UTIME=1
-DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1
-DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1
-DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1
-DHAVE_MKSTEMPS=1 -DHAVE_C99_VSNPRINTF=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1
-D_WIN32_WINNT=0x0403 -DHAVE_LOADLIBRARY_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_COPYSIGN=1
-DHAVE_SIGNBIT=1 -DHAVE__FINITE=1 -DHAVE__ISNAN=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_RDEV=1 -DHAVE_DECL_TZNAME=1
-DHAVE_TZNAME=1 -DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void
-DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1
-DRETSIGTYPE_IS_VOID=1


User-preferences (please do not edit this section):

  EDITOR = C:\Octave\3.2.2_gcc-4.3.0\tools\notepad++\notepad++.exe
  EXEC_PATH =
C:\Octave\3.2.2_gcc-4.3.0\MINGW32\bin;C:\Octave\3.2.2_gcc-4.3.0\MSYS\bin;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\site\exec\i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\api-v37\site\exec\i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\site\exec\i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\exec\i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\bin;C:\Program
Files\MiKTeX
2.7\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\Program
Files\Common Files\Roxio Shared\DLLShared\;C:\Program
Files\Hewlett-Packard\IAM\bin;C:\Program
Files\QuickTime\QTSystem\;C:\Program Files\Perforce\;c:\Program
Files\Microsoft SQL Server\90\Tools\binn\;C:\Program
Files\Octave\3.2.0_gcc-4.3.0\mingw32\bin;c:\documents and
settings\16deploy\perforce\
  IMAGE_PATH = .;C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\imagelib
  PAGER = C:\Octave\3.2.2_gcc-4.3.0\bin\less.exe
  PS1 = octave:\#>
  PS2 =
  PS4 = +
  beep_on_error = 0
  completion_append_char =
  crash_dumps_octave_core = 1
  echo_executing_commands = 4
  fixed_point_format = 0
  gnuplot_binary = C:\Octave\3.2.2_gcc-4.3.0\bin\gnuplot.exe
# gnuplot_command_end = <no value or error in displaying it> #
gnuplot_command_plot = <no value or error in displaying it> #
gnuplot_command_replot = <no value or error in displaying it> #
gnuplot_command_splot = <no value or error in displaying it> #
gnuplot_command_title = <no value or error in displaying it> #
gnuplot_command_using = <no value or error in displaying it> #
gnuplot_command_with = <no value or error in displaying it>
  history_file = P:\.octave_hist
  history_size = 1024
  ignore_function_time_stamp = system
  info_file = C:\Octave\3.2.2_gcc-4.3.0\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 = <no value or error in displaying it>
  print_empty_dimensions = 1
  save_precision = 16
  saving_history = 0
  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


-- 
View this message in context: http://www.nabble.com/Error-in-wavread-tp25218546p25218546.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From marco_atzeri at yahoo.it  Mon Aug 31 03:54:30 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Mon, 31 Aug 2009 08:54:30 +0000 (GMT)
Subject: quadgk test fault or comparing complex
Message-ID: <114761.44018.qm@web25501.mail.ukl.yahoo.com>

Hi,
on latest hg source , built on cygwin-1.7 and gcc-4.3.2 
one of the test on quadgk is failing

quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
error: max_recursion_limit exceeded
error: called from:
error:   /pub/hg/octave_build/../octave_clone/scripts/general/quadgk.m at line 124, column 15

No problem on octave 3.2.2 
octave:2> quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
ans = 3.5607e-12 - 3.1416e+00i

So it seems related on comparing 2 complex numbers

octave:1> 1+1i < 1+1i
ans =  1
octave:2> 1+1i > 1+1i
ans = 0

Regards
Marco


      



From olaf.till at uni-jena.de  Mon Aug 31 03:06:38 2009
From: olaf.till at uni-jena.de (Olaf Till)
Date: Mon, 31 Aug 2009 10:06:38 +0200
Subject: 3.2.2: pkg load crashes after addpath ("current_directory")
Message-ID: <20090831080638.GA4483@olaf>

Octave-version: 3.2.2
Description: see subject and next lines
Reproduce with:

olaf at olaf:~$ mkdir temp
olaf at olaf:~$ cd temp
olaf at olaf:~/temp$ octave
GNU Octave, version 3.2.2
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 <bug at octave.org> (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'.

warning: mark_as_command is obsolete and will be removed from a future version of Octave
octave:1> addpath ("~/temp/")
octave:2> pkg load benchmark # is not loaded at startup
panic: impossible state reached in file `load-path.cc' at line 657
panic: Aborted -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Aborted
olaf at olaf:~/temp$ 

From christophe.tournery at illusonic.com  Mon Aug 31 04:15:53 2009
From: christophe.tournery at illusonic.com (Christophe Tournery)
Date: Mon, 31 Aug 2009 11:15:53 +0200
Subject: Error in wavread
In-Reply-To: <25218546.post@talk.nabble.com>
References: <25218546.post@talk.nabble.com>
Message-ID: <47AD6A04-7C54-4DD3-AACB-5C916806E1B4@illusonic.com>

Hi Felix,

I submitted a patch to this on this mailing list last Saturday.  
Subject: wavread(...,'size') bug in 3.2.0.
Hopefully it will be included in the next update.

In the meantime I suggest you patch your own version of wavread.m. The  
file is in /path-to-octave-install/octave/3.2.2/m/audio/wavread.m.
All you need to change is replace 'ck_size' with 'data_size'.

Bests,
Christophe


On Aug 31, 2009, at 7:35 AM, F?lixB wrote:

>
> Bug report for Octave 3.2.2 configured for i686-pc-mingw32
>
> Description:
> -----------
> Hello
>
> I get an error when using wavread with the argument 'size'
>
> This error is also in Octave 3.2.0, but not in 3.0.5
>
> Calling : Ns = wavread(Fname,'size') ;
>
> error: `ck_size' undefined near line 172 column 12
> error: called from:
> error:   C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\audio 
> \wavread.m at
> line 172, column 9
>
> Thank's for you help
>
> Felix
>
> Configuration (please do not edit this section):
> -----------------------------------------------
>
> uname output:     Windows
> configure opts:
> Fortran compiler: mingw32-gfortran-4.3.0-dw2
> FFLAGS:           -O -mieee-fp
> FLIBS:            -lgfortran
> CPPFLAGS:         -march=i686 -mtune=generic -O2
> INCFLAGS:         -I. -I/octmgw32/octave/octave-3.2.2 -I. -I./ 
> liboctave
> -I./src -I./libcruft/misc -I/octmgw32/octave/octave-3.2.2
> -I/octmgw32/octave/octave-3.2.2/liboctave
> -I/octmgw32/octave/octave-3.2.2/src
> -I/octmgw32/octave/octave-3.2.2/libcruft/misc
> C compiler:       mingw32-gcc-4.3.0-dw2, version4.3.0-dw2 (GCC TDM-2  
> for
> MinGW)
> CFLAGS:           -Wall
> CPICFLAG:
> C++ compiler:     mingw32-g++-4.3.0-dw2, version4.3.0-dw2
> CXXFLAGS:         -D_DLL -Wall
> CXXPICFLAG:
> LD_CXX:           mingw32-g++-4.3.0-dw2
> LDFLAGS:          -shared-libgcc -Wl,--exclude-libs=-lstdc++_s
> -Wl,--allow-multiple-definition
> LIBFLAGS:         -L.
> RLD_FLAG:
> BLAS_LIBS:        -llapack -lblas
> FFTW_LIBS:        -lfftw3 -lfftw3f
> LIBS:             -lreadline  -lncurses -liberty -lblas -lhdf5 -lz -lm
> -lgdi32 -lws2_32 -luser32 -lkernel32
> LEXLIB:
> LIBGLOB:          -lglob
> SED:              /usr/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_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_GLPK_H=1 - 
> DHAVE_GLPK=1
> -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_WINDOWS_H=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 - 
> Duid_t=int
> -Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_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=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_ASSERT_H=1 - 
> DHAVE_CURSES_H=1
> -DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 - 
> DHAVE_INTTYPES_H=1
> -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 - 
> DHAVE_NCURSES_H=1
> -DHAVE_PTHREAD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 - 
> DHAVE_STRING_H=1
> -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1
> -DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1
> -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 - 
> DHAVE_EXPM1F=1
> -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE_GETTIMEOFDAY=1
> -DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LOG1P=1
> -DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_PUTENV=1
> -DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1
> -DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1
> -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1
> -DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 - 
> DHAVE_TGAMMAF=1
> -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 - 
> DHAVE_UTIME=1
> -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1
> -DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1
> -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1
> -DHAVE_MKSTEMPS=1 -DHAVE_C99_VSNPRINTF=1 - 
> DOCTAVE_HAVE_BROKEN_STRPTIME=1
> -D_WIN32_WINNT=0x0403 -DHAVE_LOADLIBRARY_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_COPYSIGN=1
> -DHAVE_SIGNBIT=1 -DHAVE__FINITE=1 -DHAVE__ISNAN=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_RDEV=1 -DHAVE_DECL_TZNAME=1
> -DHAVE_TZNAME=1 -DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 - 
> DRETSIGTYPE=void
> -DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1
> -DRETSIGTYPE_IS_VOID=1
>
>
> User-preferences (please do not edit this section):
>
>  EDITOR = C:\Octave\3.2.2_gcc-4.3.0\tools\notepad++\notepad++.exe
>  EXEC_PATH =
> C:\Octave\3.2.2_gcc-4.3.0\MINGW32\bin;C:\Octave\3.2.2_gcc-4.3.0\MSYS 
> \bin;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\site\exec\i686- 
> pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\api-v37\site\exec 
> \i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\site\exec 
> \i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\exec 
> \i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\bin;C:\Program
> Files\MiKTeX
> 2.7\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS 
> \System32\Wbem;c:\Program
> Files\Common Files\Roxio Shared\DLLShared\;C:\Program
> Files\Hewlett-Packard\IAM\bin;C:\Program
> Files\QuickTime\QTSystem\;C:\Program Files\Perforce\;c:\Program
> Files\Microsoft SQL Server\90\Tools\binn\;C:\Program
> Files\Octave\3.2.0_gcc-4.3.0\mingw32\bin;c:\documents and
> settings\16deploy\perforce\
>  IMAGE_PATH = .;C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\imagelib
>  PAGER = C:\Octave\3.2.2_gcc-4.3.0\bin\less.exe
>  PS1 = octave:\#>
>  PS2 =
>  PS4 = +
>  beep_on_error = 0
>  completion_append_char =
>  crash_dumps_octave_core = 1
>  echo_executing_commands = 4
>  fixed_point_format = 0
>  gnuplot_binary = C:\Octave\3.2.2_gcc-4.3.0\bin\gnuplot.exe
> # gnuplot_command_end = <no value or error in displaying it> #
> gnuplot_command_plot = <no value or error in displaying it> #
> gnuplot_command_replot = <no value or error in displaying it> #
> gnuplot_command_splot = <no value or error in displaying it> #
> gnuplot_command_title = <no value or error in displaying it> #
> gnuplot_command_using = <no value or error in displaying it> #
> gnuplot_command_with = <no value or error in displaying it>
>  history_file = P:\.octave_hist
>  history_size = 1024
>  ignore_function_time_stamp = system
>  info_file = C:\Octave\3.2.2_gcc-4.3.0\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 = <no value or error in displaying it>
>  print_empty_dimensions = 1
>  save_precision = 16
>  saving_history = 0
>  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
>
>
> -- 
> View this message in context: http://www.nabble.com/Error-in-wavread-tp25218546p25218546.html
> Sent from the Octave - Bugs mailing list archive at Nabble.com.
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave



From carlo.defalco at gmail.com  Mon Aug 31 04:18:38 2009
From: carlo.defalco at gmail.com (Carlo de Falco)
Date: Mon, 31 Aug 2009 11:18:38 +0200
Subject: eigs interface inconsistent with documentation?
Message-ID: <79716426-E869-4FD5-8035-CDB9FBA6B005@gmail.com>

--------
Bug report for Octave 3.2.2 configured for i386-apple-darwin8.11.1

Description:
-----------

Using 'eigs' to solve a generalized eigenvalue problem does not seem  
to work
as advertized in the help text when the first argument is a function  
handle:

-- Loadable Function: D = eigs (AF, N, B)
-- Loadable Function: D = eigs (AF, N, B, K)
-- Loadable Function: D = eigs (AF, N, B, K, SIGMA)
-- Loadable Function: D = eigs (AF, N, B, K, SIGMA, OPTS)

Repeat-By:
---------

 >> A = eye (10);
 >> AF = @(x) (A*x);
 >> D = eigs (AF, 10, A)
warning: implicit conversion from diagonal matrix to real scalar
D =  1
 >> D = eigs (AF, 10, A, 6)
D = eigs (AF, 10, A, 6)
warning: implicit conversion from diagonal matrix to real scalar
D =  7
 >> D = eigs (AF, 10, A, 6, 'lm')
warning: implicit conversion from diagonal matrix to real scalar
error: eigs: options argument must be a structure
 >> D = eigs (AF, 10, A, 6, 'lm', struct ('issym', true))
warning: implicit conversion from diagonal matrix to real scalar
error: eigs: options argument must be a structure


Fix:
---

I beleive there should be some sort of problem in the way eigs checks  
for input arg type but I haven't found it yet...

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 -Wl,-framework -Wl,vecLib - 
lhdf5 -lz -lm
LEXLIB:
LIBGLOB:
SED:              /usr/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_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.2/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.2/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.2/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 = <no value or error in displaying it>
# gnuplot_command_plot = <no value or error in displaying it>
# gnuplot_command_replot = <no value or error in displaying it>
# gnuplot_command_splot = <no value or error in displaying it>
# gnuplot_command_title = <no value or error in displaying it>
# gnuplot_command_using = <no value or error in displaying it>
# gnuplot_command_with = <no value or error in displaying it>
   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 = <no value or error in displaying it>
   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 felix.buehlmann at acousticimplants.com  Mon Aug 31 04:25:45 2009
From: felix.buehlmann at acousticimplants.com (=?UTF-8?Q?F=C3=A9lixB?=)
Date: Mon, 31 Aug 2009 02:25:45 -0700 (PDT)
Subject: Error in wavread
In-Reply-To: <47AD6A04-7C54-4DD3-AACB-5C916806E1B4@illusonic.com>
References: <25218546.post@talk.nabble.com>
	<47AD6A04-7C54-4DD3-AACB-5C916806E1B4@illusonic.com>
Message-ID: <25220578.post@talk.nabble.com>


Christophe, thank's for your help!
BR

F?lix


Christophe Tournery-2 wrote:
> 
> Hi Felix,
> 
> I submitted a patch to this on this mailing list last Saturday.  
> Subject: wavread(...,'size') bug in 3.2.0.
> Hopefully it will be included in the next update.
> 
> In the meantime I suggest you patch your own version of wavread.m. The  
> file is in /path-to-octave-install/octave/3.2.2/m/audio/wavread.m.
> All you need to change is replace 'ck_size' with 'data_size'.
> 
> Bests,
> Christophe
> 
> 
> On Aug 31, 2009, at 7:35 AM, F?lixB wrote:
> 
>>
>> Bug report for Octave 3.2.2 configured for i686-pc-mingw32
>>
>> Description:
>> -----------
>> Hello
>>
>> I get an error when using wavread with the argument 'size'
>>
>> This error is also in Octave 3.2.0, but not in 3.0.5
>>
>> Calling : Ns = wavread(Fname,'size') ;
>>
>> error: `ck_size' undefined near line 172 column 12
>> error: called from:
>> error:   C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\m\audio 
>> \wavread.m at
>> line 172, column 9
>>
>> Thank's for you help
>>
>> Felix
>>
>> Configuration (please do not edit this section):
>> -----------------------------------------------
>>
>> uname output:     Windows
>> configure opts:
>> Fortran compiler: mingw32-gfortran-4.3.0-dw2
>> FFLAGS:           -O -mieee-fp
>> FLIBS:            -lgfortran
>> CPPFLAGS:         -march=i686 -mtune=generic -O2
>> INCFLAGS:         -I. -I/octmgw32/octave/octave-3.2.2 -I. -I./ 
>> liboctave
>> -I./src -I./libcruft/misc -I/octmgw32/octave/octave-3.2.2
>> -I/octmgw32/octave/octave-3.2.2/liboctave
>> -I/octmgw32/octave/octave-3.2.2/src
>> -I/octmgw32/octave/octave-3.2.2/libcruft/misc
>> C compiler:       mingw32-gcc-4.3.0-dw2, version4.3.0-dw2 (GCC TDM-2  
>> for
>> MinGW)
>> CFLAGS:           -Wall
>> CPICFLAG:
>> C++ compiler:     mingw32-g++-4.3.0-dw2, version4.3.0-dw2
>> CXXFLAGS:         -D_DLL -Wall
>> CXXPICFLAG:
>> LD_CXX:           mingw32-g++-4.3.0-dw2
>> LDFLAGS:          -shared-libgcc -Wl,--exclude-libs=-lstdc++_s
>> -Wl,--allow-multiple-definition
>> LIBFLAGS:         -L.
>> RLD_FLAG:
>> BLAS_LIBS:        -llapack -lblas
>> FFTW_LIBS:        -lfftw3 -lfftw3f
>> LIBS:             -lreadline  -lncurses -liberty -lblas -lhdf5 -lz -lm
>> -lgdi32 -lws2_32 -luser32 -lkernel32
>> LEXLIB:
>> LIBGLOB:          -lglob
>> SED:              /usr/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_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_GLPK_H=1 - 
>> DHAVE_GLPK=1
>> -DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_MAGICK=1 -DHAVE_WINDOWS_H=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 - 
>> Duid_t=int
>> -Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_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=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_ASSERT_H=1 - 
>> DHAVE_CURSES_H=1
>> -DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 - 
>> DHAVE_INTTYPES_H=1
>> -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 - 
>> DHAVE_NCURSES_H=1
>> -DHAVE_PTHREAD_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 - 
>> DHAVE_STRING_H=1
>> -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1
>> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTIME_H=1 -DHAVE_TERMCAP_H=1
>> -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1
>> -DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1 -DHAVE_ATEXIT=1 -DHAVE_BASENAME=1
>> -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1 -DHAVE_EXPM1=1 - 
>> DHAVE_EXPM1F=1
>> -DHAVE_FSTAT=1 -DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE_GETTIMEOFDAY=1
>> -DHAVE__KBHIT=1 -DHAVE_LGAMMA=1 -DHAVE_LGAMMAF=1 -DHAVE_LOG1P=1
>> -DHAVE_LOG1PF=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_PUTENV=1
>> -DHAVE_RAISE=1 -DHAVE_RENAME=1 -DHAVE_RMDIR=1 -DHAVE_ROUNDL=1
>> -DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_SNPRINTF=1 -DHAVE_STAT=1
>> -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1
>> -DHAVE_STRNCASECMP=1 -DHAVE_STRNICMP=1 -DHAVE_TEMPNAM=1 - 
>> DHAVE_TGAMMAF=1
>> -DHAVE_TRUNC=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 - 
>> DHAVE_UTIME=1
>> -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1
>> -DHAVE__SNPRINTF=1 -DHAVE_DECL_EXP2=1 -DHAVE_DECL_ROUND=1
>> -DHAVE_DECL_TGAMMA=1 -DHAVE_EXP2=1 -DHAVE_ROUND=1 -DHAVE_TGAMMA=1
>> -DHAVE_MKSTEMPS=1 -DHAVE_C99_VSNPRINTF=1 - 
>> DOCTAVE_HAVE_BROKEN_STRPTIME=1
>> -D_WIN32_WINNT=0x0403 -DHAVE_LOADLIBRARY_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_COPYSIGN=1
>> -DHAVE_SIGNBIT=1 -DHAVE__FINITE=1 -DHAVE__ISNAN=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_RDEV=1 -DHAVE_DECL_TZNAME=1
>> -DHAVE_TZNAME=1 -DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 - 
>> DRETSIGTYPE=void
>> -DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1
>> -DRETSIGTYPE_IS_VOID=1
>>
>>
>> User-preferences (please do not edit this section):
>>
>>  EDITOR = C:\Octave\3.2.2_gcc-4.3.0\tools\notepad++\notepad++.exe
>>  EXEC_PATH =
>> C:\Octave\3.2.2_gcc-4.3.0\MINGW32\bin;C:\Octave\3.2.2_gcc-4.3.0\MSYS 
>> \bin;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\site\exec\i686- 
>> pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\api-v37\site\exec 
>> \i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\site\exec 
>> \i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\libexec\octave\3.2.2\exec 
>> \i686-pc-mingw32;C:\Octave\3.2.2_gcc-4.3.0\bin;C:\Program
>> Files\MiKTeX
>> 2.7\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS 
>> \System32\Wbem;c:\Program
>> Files\Common Files\Roxio Shared\DLLShared\;C:\Program
>> Files\Hewlett-Packard\IAM\bin;C:\Program
>> Files\QuickTime\QTSystem\;C:\Program Files\Perforce\;c:\Program
>> Files\Microsoft SQL Server\90\Tools\binn\;C:\Program
>> Files\Octave\3.2.0_gcc-4.3.0\mingw32\bin;c:\documents and
>> settings\16deploy\perforce\
>>  IMAGE_PATH = .;C:\Octave\3.2.2_gcc-4.3.0\share\octave\3.2.2\imagelib
>>  PAGER = C:\Octave\3.2.2_gcc-4.3.0\bin\less.exe
>>  PS1 = octave:\#>
>>  PS2 =
>>  PS4 = +
>>  beep_on_error = 0
>>  completion_append_char =
>>  crash_dumps_octave_core = 1
>>  echo_executing_commands = 4
>>  fixed_point_format = 0
>>  gnuplot_binary = C:\Octave\3.2.2_gcc-4.3.0\bin\gnuplot.exe
>> # gnuplot_command_end = <no value or error in displaying it> #
>> gnuplot_command_plot = <no value or error in displaying it> #
>> gnuplot_command_replot = <no value or error in displaying it> #
>> gnuplot_command_splot = <no value or error in displaying it> #
>> gnuplot_command_title = <no value or error in displaying it> #
>> gnuplot_command_using = <no value or error in displaying it> #
>> gnuplot_command_with = <no value or error in displaying it>
>>  history_file = P:\.octave_hist
>>  history_size = 1024
>>  ignore_function_time_stamp = system
>>  info_file = C:\Octave\3.2.2_gcc-4.3.0\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 = <no value or error in displaying it>
>>  print_empty_dimensions = 1
>>  save_precision = 16
>>  saving_history = 0
>>  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
>>
>>
>> -- 
>> View this message in context:
>> http://www.nabble.com/Error-in-wavread-tp25218546p25218546.html
>> Sent from the Octave - Bugs mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Bug-octave mailing list
>> Bug-octave at octave.org
>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
> 
> 
> _______________________________________________
> 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-in-wavread-tp25218546p25220578.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.



From dbateman at free.fr  Mon Aug 31 10:15:44 2009
From: dbateman at free.fr (dbateman)
Date: Mon, 31 Aug 2009 08:15:44 -0700 (PDT)
Subject: quadgk test fault or comparing complex
In-Reply-To: <114761.44018.qm@web25501.mail.ukl.yahoo.com>
References: <114761.44018.qm@web25501.mail.ukl.yahoo.com>
Message-ID: <25225186.post@talk.nabble.com>




Marco atzeri-3 wrote:
> 
> Hi,
> on latest hg source , built on cygwin-1.7 and gcc-4.3.2 
> one of the test on quadgk is failing
> 
> quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> error: max_recursion_limit exceeded
> error: called from:
> error:   /pub/hg/octave_build/../octave_clone/scripts/general/quadgk.m at
> line 124, column 15
> 
> No problem on octave 3.2.2 
> octave:2> quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> ans = 3.5607e-12 - 3.1416e+00i
> 
> So it seems related on comparing 2 complex numbers
> 
> octave:1> 1+1i < 1+1i
> ans =  1
> octave:2> 1+1i > 1+1i
> ans = 0
> 
> 

Yes it seems the recent change to the complex comparison operators changed
this behavior. Though it also seems to me that the previous behavior for the
convergence of sub-intervals of the contour integrals was incorrect.. I
believe if you change line 332 from

dx = find (abs (q_errs) < tol .* diff (subs, [], 2) ./ h);
	
to

dx = find (abs (q_errs) < tol .* abs (diff (subs, [], 2)) ./ h);

it will be correct. However in the case you give "h" is zero but is supposed
to be an approximation the path length of the contour integral.. So the
calculation of "h" at line 187 should be 

h = sum (abs (diff (subs)));

I can't test this code and in any case the test code for the contour
integral appears incorrect as well. So I'll propose a patch later

D.

-- 
View this message in context: http://www.nabble.com/quadgk-test-fault-or-comparing-complex-tp25220292p25225186.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From dbateman at free.fr  Mon Aug 31 10:16:57 2009
From: dbateman at free.fr (dbateman)
Date: Mon, 31 Aug 2009 08:16:57 -0700 (PDT)
Subject: quadgk test fault or comparing complex
In-Reply-To: <114761.44018.qm@web25501.mail.ukl.yahoo.com>
References: <114761.44018.qm@web25501.mail.ukl.yahoo.com>
Message-ID: <25225206.post@talk.nabble.com>




Marco atzeri-3 wrote:
> 
> Hi,
> on latest hg source , built on cygwin-1.7 and gcc-4.3.2 
> one of the test on quadgk is failing
> 
> quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> error: max_recursion_limit exceeded
> error: called from:
> error:   /pub/hg/octave_build/../octave_clone/scripts/general/quadgk.m at
> line 124, column 15
> 
> No problem on octave 3.2.2 
> octave:2> quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> ans = 3.5607e-12 - 3.1416e+00i
> 
> So it seems related on comparing 2 complex numbers
> 
> octave:1> 1+1i < 1+1i
> ans =  1
> octave:2> 1+1i > 1+1i
> ans = 0
> 
> Regards
> Marco
> 
> 
>       
> 
> 
> _______________________________________________
> 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/quadgk-test-fault-or-comparing-complex-tp25220292p25225206.html
Sent from the Octave - Bugs mailing list archive at Nabble.com.


From marco_atzeri at yahoo.it  Mon Aug 31 11:06:04 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Mon, 31 Aug 2009 16:06:04 +0000 (GMT)
Subject: quadgk test fault or comparing complex
In-Reply-To: <25225186.post@talk.nabble.com>
Message-ID: <916049.32717.qm@web25508.mail.ukl.yahoo.com>

--- Lun 31/8/09, dbateman <dbateman at free.fr> ha scritto:

> Da: dbateman <dbateman at free.fr>
> Oggetto: Re: quadgk test fault or comparing complex
> A: bug-octave at octave.org
> Data: Luned? 31 agosto 2009, 17:15
> 
> 
> 
> Marco atzeri-3 wrote:
> > 
> > Hi,
> > on latest hg source , built on cygwin-1.7 and
> gcc-4.3.2 
> > one of the test on quadgk is failing
> > 
> > quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i,
> -1,-i, -1+i ])
> > error: max_recursion_limit exceeded
> > error: called from:
> >
> error:???/pub/hg/octave_build/../octave_clone/scripts/general/quadgk.m
> at
> > line 124, column 15
> > 
> > No problem on octave 3.2.2 
> > octave:2> quadgk (@(z) log(z), 1+1i,
> 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> > ans = 3.5607e-12 - 3.1416e+00i
> > 
> > So it seems related on comparing 2 complex numbers
> > 
> > octave:1> 1+1i < 1+1i
> > ans =? 1
> > octave:2> 1+1i > 1+1i
> > ans = 0
> > 
> > 
> 
> Yes it seems the recent change to the complex comparison
> operators changed
> this behavior. Though it also seems to me that the previous
> behavior for the
> convergence of sub-intervals of the contour integrals was
> incorrect.. I
> believe if you change line 332 from
> 
> dx = find (abs (q_errs) < tol .* diff (subs, [], 2) ./
> h);
> ??? 
> to
> 
> dx = find (abs (q_errs) < tol .* abs (diff (subs, [],
> 2)) ./ h);
> 
> it will be correct. However in the case you give "h" is
> zero but is supposed
> to be an approximation the path length of the contour
> integral.. So the
> calculation of "h" at line 187 should be 
> 
> h = sum (abs (diff (subs)));
> 
> I can't test this code and in any case the test code for
> the contour
> integral appears incorrect as well. So I'll propose a patch
> later
> 
> D.
> 
Hi David,

as only the second comaprison case is correct 

octave:1> 1+1i < 1+1i
ans =  1
octave:2> 1+1i > 1+1i
ans = 0


and as workaround I change the line 123

from 

  if (b>a )
    [q, err] = quadgk (f, b, a, varargin{:});
    q = -q;

to
  if (a>b )
    [q, err] = quadgk (f, b, a, varargin{:});
    q = -q;

the integral seems correct

quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
ans = 3.5607e-12 - 3.1416e+00i


Regards
Marco



      



From jwe at octave.org  Mon Aug 31 11:14:39 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 31 Aug 2009 12:14:39 -0400
Subject: quadgk test fault or comparing complex
In-Reply-To: <114761.44018.qm@web25501.mail.ukl.yahoo.com>
References: <114761.44018.qm@web25501.mail.ukl.yahoo.com>
Message-ID: <19099.63215.233135.139935@segfault.lan>

On 31-Aug-2009, Marco Atzeri wrote:

| on latest hg source , built on cygwin-1.7 and gcc-4.3.2 
| one of the test on quadgk is failing
| 
| quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
| error: max_recursion_limit exceeded
| error: called from:
| error:   /pub/hg/octave_build/../octave_clone/scripts/general/quadgk.m at line 124, column 15
| 
| No problem on octave 3.2.2 
| octave:2> quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
| ans = 3.5607e-12 - 3.1416e+00i
| 
| So it seems related on comparing 2 complex numbers
| 
| octave:1> 1+1i < 1+1i
| ans =  1
| octave:2> 1+1i > 1+1i
| ans = 0

I can't reproduce this problem with the latest sources.  I see:

  octave:1> 1+1i < 1+1i
  ans = 0
  octave:2> 1+1i > 1+1i
  ans = 0
  octave:3> quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
  ans = 3.5607e-12 - 3.1416e+00i

The latest changeset applied for my build is:

  changeset:   9587:5ab448e3febe
  tag:         tip
  user:        Jaroslav Hajek <highegg at gmail.com>
  date:        Sun Aug 30 10:32:10 2009 +0200
  summary:     remove unused macros from ops.h

Are you sure you are current?

jwe

From marco_atzeri at yahoo.it  Mon Aug 31 12:52:45 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Mon, 31 Aug 2009 17:52:45 +0000 (GMT)
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <19099.63215.233135.139935@segfault.lan>
Message-ID: <114022.98737.qm@web25504.mail.ukl.yahoo.com>

--- Lun 31/8/09, John W. Eaton <jwe at octave.org> ha scritto:

> Da: John W. Eaton <jwe at octave.org>
> Oggetto: quadgk test fault or comparing complex
> A: "Marco Atzeri" <marco_atzeri at yahoo.it>
> Cc: bug-octave at octave..org
> Data: Luned? 31 agosto 2009, 18:14
> On 31-Aug-2009, Marco Atzeri wrote:
> 
> | on latest hg source , built on cygwin-1.7 and gcc-4.3..2 
> | one of the test on quadgk is failing
> | 
> | quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i,
> -1+i ])
> | error: max_recursion_limit exceeded
> | error: called from:
> |
> error:???/pub/hg/octave_build/../octave_clone/scripts/general/quadgk.m
> at line 124, column 15
> | 
> | No problem on octave 3.2.2 
> | octave:2> quadgk (@(z) log(z), 1+1i,
> 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> | ans = 3.5607e-12 - 3.1416e+00i
> | 
> | So it seems related on comparing 2 complex numbers
> | 
> | octave:1> 1+1i < 1+1i
> | ans =? 1
> | octave:2> 1+1i > 1+1i
> | ans = 0
> 
> I can't reproduce this problem with the latest
> sources.? I see:
> 
> ? octave:1> 1+1i < 1+1i
> ? ans = 0
> ? octave:2> 1+1i > 1+1i
> ? ans = 0
> ? octave:3> quadgk (@(z) log(z), 1+1i,
> 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> ? ans = 3.5607e-12 - 3.1416e+00i
> 
> The latest changeset applied for my build is:
> 
> ? changeset:???9587:5ab448e3febe
> ? tag:? ? ? ???tip
> ? user:? ? ? ? Jaroslav Hajek
> <highegg at gmail.com>
> ? date:? ? ? ? Sun Aug 30 10:32:10
> 2009 +0200
> ? summary:? ???remove unused
> macros from ops.h
> 
> Are you sure you are current?
> 
> jwe


 hg tip
changeset:   9584:0fcbfddaa87f
tag:         tip
user:        John W. Eaton <jwe at octave.org>
date:        Fri Aug 28 05:30:29 2009 -0400
summary:     allow abbreviated graphics property names to match, with optional warning

I will rebuild as eventually the last cleaning from Jaroslav

http://hg.savannah.gnu.org/hgweb/octave/rev/319e2ab9b8ae

solved the issue.

Marco


      



From marco_atzeri at yahoo.it  Mon Aug 31 14:25:52 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Mon, 31 Aug 2009 19:25:52 +0000 (GMT)
Subject: R: quadgk test fault or comparing complex
In-Reply-To: <114022.98737.qm@web25504.mail.ukl.yahoo.com>
Message-ID: <573143.39036.qm@web25503.mail.ukl.yahoo.com>

--- Lun 31/8/09, Marco Atzeri <marco_atzeri at yahoo.it> ha scritto:

> Da: Marco Atzeri <marco_atzeri at yahoo.it>
> Oggetto: R: quadgk test fault or comparing complex
> A: "John W. Eaton" <jwe at octave.org>
> Cc: bug-octave at octave.org
> Data: Luned? 31 agosto 2009, 19:52
> --- Lun 31/8/09, John W. Eaton <jwe at octave.org>
> ha scritto:
> 
> > Da: John W. Eaton <jwe at octave.org>
> > Oggetto: quadgk test fault or comparing complex
> > A: "Marco Atzeri" <marco_atzeri at yahoo.it>
> > Cc: bug-octave at octave..org
> > Data: Luned? 31 agosto 2009, 18:14
> > On 31-Aug-2009, Marco Atzeri wrote:
> > 
> > | on latest hg source , built on cygwin-1.7 and
> gcc-4.3..2 
> > | one of the test on quadgk is failing
> > | 
> > | quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i,
> -1,-i,
> > -1+i ])
> > | error: max_recursion_limit exceeded
> > | error: called from:
> > |
> >
> error:???/pub/hg/octave_build/../octave_clone/scripts/general/quadgk.m
> > at line 124, column 15
> > | 
> > | No problem on octave 3.2.2 
> > | octave:2> quadgk (@(z) log(z), 1+1i,
> > 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> > | ans = 3.5607e-12 - 3.1416e+00i
> > | 
> > | So it seems related on comparing 2 complex numbers
> > | 
> > | octave:1> 1+1i < 1+1i
> > | ans =? 1
> > | octave:2> 1+1i > 1+1i
> > | ans = 0
> > 
> > I can't reproduce this problem with the latest
> > sources.? I see:
> > 
> > ? octave:1> 1+1i < 1+1i
> > ? ans = 0
> > ? octave:2> 1+1i > 1+1i
> > ? ans = 0
> > ? octave:3> quadgk (@(z) log(z), 1+1i,
> > 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> > ? ans = 3.5607e-12 - 3.1416e+00i
> > 
> > The latest changeset applied for my build is:
> > 
> > ? changeset:???9587:5ab448e3febe
> > ? tag:? ? ? ???tip
> > ? user:? ? ? ? Jaroslav Hajek
> > <highegg at gmail.com>
> > ? date:? ? ? ? Sun Aug 30 10:32:10
> > 2009 +0200
> > ? summary:? ???remove unused
> > macros from ops.h
> > 
> > Are you sure you are current?
> > 
> > jwe
> 
> 
>  hg tip
> changeset:???9584:0fcbfddaa87f
> tag:? ? ? ???tip
> user:? ? ? ? John W. Eaton <jwe at octave.org>
> date:? ? ? ? Fri Aug 28 05:30:29 2009
> -0400
> summary:? ???allow abbreviated graphics
> property names to match, with optional warning
> 
> I will rebuild as eventually the last cleaning from
> Jaroslav
> 
> http://hg.savannah.gnu.org/hgweb/octave/rev/319e2ab9b8ae
> 
> solved the issue.
> 
> Marco
> 

unfortunately the problem is still here

hg tip
changeset:   9589:8e42bb4ad34d
tag:         tip
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Sun Aug 30 21:56:18 2009 +0200
summary:     update NEWS


octave:2> 1+1i < 1+1i
ans =  1
octave:3> 1+1i > 1+1i
ans = 0
octave:4> 1-1i > 1-1i
ans =  1
octave:5> 1-1i < 1-1i
ans = 0



Marco



      



From dbateman at dbateman.org  Mon Aug 31 16:25:08 2009
From: dbateman at dbateman.org (David Bateman)
Date: Mon, 31 Aug 2009 23:25:08 +0200
Subject: quadgk test fault or comparing complex
In-Reply-To: <916049.32717.qm@web25508.mail.ukl.yahoo.com>
References: <916049.32717.qm@web25508.mail.ukl.yahoo.com>
Message-ID: <4A9C3FB4.9000900@dbateman.org>

Marco Atzeri wrote:
> --- Lun 31/8/09, dbateman <dbateman at free.fr> ha scritto:
>
>   
>> Da: dbateman <dbateman at free.fr>
>> Oggetto: Re: quadgk test fault or comparing complex
>> A: bug-octave at octave.org
>> Data: Luned? 31 agosto 2009, 17:15
>>
>>
>>
>> Marco atzeri-3 wrote:
>>     
>>> Hi,
>>> on latest hg source , built on cygwin-1.7 and
>>>       
>> gcc-4.3.2 
>>     
>>> one of the test on quadgk is failing
>>>
>>> quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i,
>>>       
>> -1,-i, -1+i ])
>>     
>>> error: max_recursion_limit exceeded
>>> error: called from:
>>>
>>>       
>> error:   /pub/hg/octave_build/../octave_clone/scripts/general/quadgk.m
>> at
>>     
>>> line 124, column 15
>>>
>>> No problem on octave 3.2.2 
>>> octave:2> quadgk (@(z) log(z), 1+1i,
>>>       
>> 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
>>     
>>> ans = 3.5607e-12 - 3.1416e+00i
>>>
>>> So it seems related on comparing 2 complex numbers
>>>
>>> octave:1> 1+1i < 1+1i
>>> ans =  1
>>> octave:2> 1+1i > 1+1i
>>> ans = 0
>>>
>>>
>>>       
>> Yes it seems the recent change to the complex comparison
>> operators changed
>> this behavior. Though it also seems to me that the previous
>> behavior for the
>> convergence of sub-intervals of the contour integrals was
>> incorrect.. I
>> believe if you change line 332 from
>>
>> dx = find (abs (q_errs) < tol .* diff (subs, [], 2) ./
>> h);
>>     
>> to
>>
>> dx = find (abs (q_errs) < tol .* abs (diff (subs, [],
>> 2)) ./ h);
>>
>> it will be correct. However in the case you give "h" is
>> zero but is supposed
>> to be an approximation the path length of the contour
>> integral.. So the
>> calculation of "h" at line 187 should be 
>>
>> h = sum (abs (diff (subs)));
>>
>> I can't test this code and in any case the test code for
>> the contour
>> integral appears incorrect as well. So I'll propose a patch
>> later
>>
>> D.
>>
>>     
> Hi David,
>
> as only the second comaprison case is correct 
>
> octave:1> 1+1i < 1+1i
> ans =  1
> octave:2> 1+1i > 1+1i
> ans = 0
>
>
> and as workaround I change the line 123
>
> from 
>
>   if (b>a )
>     [q, err] = quadgk (f, b, a, varargin{:});
>     q = -q;
>
> to
>   if (a>b )
>     [q, err] = quadgk (f, b, a, varargin{:});
>     q = -q;
>
> the integral seems correct
>
> quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i ])
> ans = 3.5607e-12 - 3.1416e+00i
>   
Ok, I see what you are complaining about is the comparison operator that 
is not flagging false for both comparisons as it should.. I was trying 
to make these tests entirely real before the comparison and avoid the 
issue. So I think my patch should help in any case if it is complete. 
Consider the following code

quadgk (@(z) log(z), 1+1i, 1+1i,'Waypoints',[1-i, -1,-i, -1+i 
],'Trace',true,'AbsTol',1e-9, 'RelTol',1e-9) + 1i * pi

Which sets an absolute and relative tolerance that is quite strict and 
includes a trace of the intermediate results. With 3.2.2 I get the result

warning: quadgk: Error tolerance not met. Estimated error 3.51666e-06
ans = 3.5607e-12 + 3.5616e-12i

That since there are no intermediate results, quadgk exits at the first 
test of the tolerance as "h" is zero. With the attached patch on the 
current tip the result returned was

   4.00000 + 0.00000i   0.00000 + 0.00000i   0.00000 - 3.14159i
   2.00000 + 0.00000i   0.00000 + 0.00000i  -0.00000 - 3.14159i
v = -4.4409e-16

which is more reasonable.. However in no case should 1+1i < 1+1i be 
true, but I think this is a bug in Jaroslav's recent change.

I applied the attached changeset

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/20090831/0fb03ce3/attachment.ksh 

From dbateman at dbateman.org  Mon Aug 31 16:56:58 2009
From: dbateman at dbateman.org (David Bateman)
Date: Mon, 31 Aug 2009 23:56:58 +0200
Subject: eigs interface inconsistent with documentation?
In-Reply-To: <79716426-E869-4FD5-8035-CDB9FBA6B005@gmail.com>
References: <79716426-E869-4FD5-8035-CDB9FBA6B005@gmail.com>
Message-ID: <4A9C472A.9070403@dbateman.org>

Carlo de Falco wrote:
> --------
> Bug report for Octave 3.2.2 configured for i386-apple-darwin8.11.1
>
> Description:
> -----------
>
> Using 'eigs' to solve a generalized eigenvalue problem does not seem  
> to work
> as advertized in the help text when the first argument is a function  
> handle:
>
> -- Loadable Function: D = eigs (AF, N, B)
> -- Loadable Function: D = eigs (AF, N, B, K)
> -- Loadable Function: D = eigs (AF, N, B, K, SIGMA)
> -- Loadable Function: D = eigs (AF, N, B, K, SIGMA, OPTS)
>
> Repeat-By:
> ---------
>
>  >> A = eye (10);
>  >> AF = @(x) (A*x);
>  >> D = eigs (AF, 10, A)
> warning: implicit conversion from diagonal matrix to real scalar
> D =  1
>  >> D = eigs (AF, 10, A, 6)
> D = eigs (AF, 10, A, 6)
> warning: implicit conversion from diagonal matrix to real scalar
> D =  7
>  >> D = eigs (AF, 10, A, 6, 'lm')
> warning: implicit conversion from diagonal matrix to real scalar
> error: eigs: options argument must be a structure
>  >> D = eigs (AF, 10, A, 6, 'lm', struct ('issym', true))
> warning: implicit conversion from diagonal matrix to real scalar
> error: eigs: options argument must be a structure
>
>
> Fix:
> ---
>
> I beleive there should be some sort of problem in the way eigs checks  
> for input arg type but I haven't found it yet...
>
>   
Waiting for a full rebuild to complete, so I can't test, but I think the 
attached patch against the savannah tip probably fixes the issue.

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/20090831/ee3d2a13/attachment.ksh