From shaiay at gmail.com  Thu Oct  1 01:19:59 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 1 Oct 2009 08:19:59 +0200
Subject: fltk backend fix & mouse wheel scroll factor
In-Reply-To: <19137.3438.750331.102963@segfault.lan>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
Message-ID: <420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>

On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe at octave.org> wrote:
> If we just had images working, then the fltk backend might be able to
> run all the demos...

I attach a changeset adding image rendering to the gl-renderer.
Currently only truecolor images are supported.
There is one major bug (which I know of ...) which is that the image
origin must be within the display area for it to be shown, so there
will be no zooming in on images just yet.
Note that images are purely 2D entities and are just "pasted" on the
window -- they will not undergo any transformation other than
stretching to fit the axes. I think this is the competition's behavior
as well, but I'm not sure.

Shai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glrender_image
Type: application/octet-stream
Size: 4681 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091001/b318d0f9/attachment.obj 

From tmacchant at yahoo.co.jp  Thu Oct  1 06:54:39 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 1 Oct 2009 20:54:39 +0900 (JST)
Subject: make check Fail of quadgk.m at sources of the Development Branch
	(Sep. 30, 09) (mingw gcc 4.4.0)
Message-ID: <20091001115439.4356.qmail@web3815.mail.bbt.yahoo.co.jp>

Hello

I have at last succeeded in building sources of the  Development Branch (Sep. 30,09) 

FAILs of make check
  d:\usr\Tatsu\mingwhome\octaves\hg\octave-work\src\data.cc  PASS  515/518  FAIL 3
  d:\usr\Tatsu\mingwhome\octaves\hg\octave-work\scripts/help\doc.m  PASS    0/1    FAIL 1
  d:\usr\Tatsu\mingwhome\octaves\hg\octave-work\scripts/general\quadgk.m  PASS   11/12   FAIL 1

FAILs of data.cc is already known.
FAIL of doc.m  is perhaps documentation creation error.
  ***** test if exist( info_file ()) != 2 && exist (sprintf ("%s.gz", info_file ())) != 2
       error ("Info file %s or %s.gz does not exist!", info_file (), info_file ());
     endif
!!!!! test failed
Info file d:/usr/Tatsu/mingwhome/octaves/OctBuild/hg-devel/doc/interpreter/octave.info or
d:/usr/Tatsu/mingwhome/octaves/OctBuild/hg-devel/doc

FAIL of quadgk.m error is new and essential error at the development sources.
  ***** assert (quadgk (@(z) log (z), 1+1i, 1+1i, 'WayPoints', [1-1i, -1,-1i, -1+1i]), -pi * 1i, 1e-6)
!!!!! test failed

octave.exe:1> quadgk (@(z) log (z), 1+1i, 1+1i, 'WayPoints', [1-1i, -1,-1i, -1+1i])
error: max_recursion_limit exceeded
error: called from:
error:  
d:\usr\Tatsu\mingwhome\octaves\OctBuild\hg-devel\..\..\hg\octave-work\scripts\general\quadgk.m at line
124, col
umn 15

Regards

Tatsuro

--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/

From jwe at octave.org  Thu Oct  1 14:21:51 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 1 Oct 2009 15:21:51 -0400
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel scroll
	factor)
In-Reply-To: <420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
Message-ID: <19141.335.259271.430886@segfault.lan>

On  1-Oct-2009, Shai Ayal wrote:

| On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe at octave.org> wrote:
| > If we just had images working, then the fltk backend might be able to
| > run all the demos...
| 
| I attach a changeset adding image rendering to the gl-renderer.
| Currently only truecolor images are supported.
| There is one major bug (which I know of ...) which is that the image
| origin must be within the display area for it to be shown, so there
| will be no zooming in on images just yet.
| Note that images are purely 2D entities and are just "pasted" on the
| window -- they will not undergo any transformation other than
| stretching to fit the axes. I think this is the competition's behavior
| as well, but I'm not sure.

I applied the patch and made some other small changes.  Thanks.

I also checked in this change

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

so that in a plot like

  image (rand (8, 10, 3))

all the rectangles of color are the same size and are all inside the
axes box.  This works now for both gnuplot and opengl.  However, the
following does not work correctly for the opengl backend:

  image (rand (8, 10, 3))
  set (gca, 'xlim', [2, 4])

I would expect something like the first image attached below
(generated with the gnuplot backend), but I get the second.  Oddly,
the axis is resized to fill the screen if the window is refreshed (by
placing another window on top of it then uncovering it, for example).
I'm not sure what the proper fix is.  Any clues?

jwe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnuplot.png
Type: image/png
Size: 9032 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091001/07f84a8a/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opengl.png
Type: image/png
Size: 12751 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091001/07f84a8a/attachment-0003.png 

From shaiay at gmail.com  Thu Oct  1 15:13:33 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 1 Oct 2009 22:13:33 +0200
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel scroll
	factor)
In-Reply-To: <19141.335.259271.430886@segfault.lan>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
Message-ID: <420fb9e60910011313k6871f5b8m84785af97eed676b@mail.gmail.com>

On Thu, Oct 1, 2009 at 9:21 PM, John W. Eaton <jwe at octave.org> wrote:
> On ?1-Oct-2009, Shai Ayal wrote:
>
> | On Mon, Sep 28, 2009 at 9:24 PM, John W. Eaton <jwe at octave.org> wrote:
> | > If we just had images working, then the fltk backend might be able to
> | > run all the demos...
> |
> | I attach a changeset adding image rendering to the gl-renderer.
> | Currently only truecolor images are supported.
> | There is one major bug (which I know of ...) which is that the image
> | origin must be within the display area for it to be shown, so there
> | will be no zooming in on images just yet.
> | Note that images are purely 2D entities and are just "pasted" on the
> | window -- they will not undergo any transformation other than
> | stretching to fit the axes. I think this is the competition's behavior
> | as well, but I'm not sure.
>
> I applied the patch and made some other small changes. ?Thanks.
>
> I also checked in this change
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/c338cb954e58
>
> so that in a plot like
>
> ?image (rand (8, 10, 3))
>
> all the rectangles of color are the same size and are all inside the
> axes box. ?This works now for both gnuplot and opengl. ?However, the
> following does not work correctly for the opengl backend:
>
> ?image (rand (8, 10, 3))
> ?set (gca, 'xlim', [2, 4])
>
> I would expect something like the first image attached below
> (generated with the gnuplot backend), but I get the second. ?Oddly,
> the axis is resized to fill the screen if the window is refreshed (by
> placing another window on top of it then uncovering it, for example).
> I'm not sure what the proper fix is. ?Any clues?
I can confirm this behavior.
I know what causes the first problem, of the image disappearing.
OpenGL will only draw the image if the origin of the image is within
the window (viewport in OpenGL teminology). When you change the axis,
it moves the image origin out of the viewport.
I will try and fix this by drawing only the part of the image which is
inside the viewport if the origin is outside the viewport

I have no idea about the second problem -- the strange axes aspect
ration which is corrected by a screen redraw.

Shai

Shai


From michael.goffioul at gmail.com  Thu Oct  1 15:26:35 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Thu, 1 Oct 2009 21:26:35 +0100
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel scroll
	factor)
In-Reply-To: <420fb9e60910011313k6871f5b8m84785af97eed676b@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910011313k6871f5b8m84785af97eed676b@mail.gmail.com>
Message-ID: <128f38bd0910011326v1221bde2ncb9c16b3a8a2a967@mail.gmail.com>

A better - more generic - solution would be to implement
images::properties::update_[x|y]data() correctly. Basically,
an image always extend beyond xdata and ydata, by half
a pixel width (here, I mean an image pixel, no a screen pixel).
This must be taken into account by the algorithm that is
computing the axes limits. That's the purpose of the xlim
and ylim hidden properties of the image object.

For a complete fix, you would also need to implement the
"axis image" mode.

Michael.


On Thu, Oct 1, 2009 at 9:13 PM, Shai Ayal <shaiay at gmail.com> wrote:
> I can confirm this behavior.
> I know what causes the first problem, of the image disappearing.
> OpenGL will only draw the image if the origin of the image is within
> the window (viewport in OpenGL teminology). When you change the axis,
> it moves the image origin out of the viewport.
> I will try and fix this by drawing only the part of the image which is
> inside the viewport if the origin is outside the viewport
>
> I have no idea about the second problem -- the strange axes aspect
> ration which is corrected by a screen redraw.
>
> Shai
>
> Shai
>
>

From marco_atzeri at yahoo.it  Fri Oct  2 03:25:24 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Fri, 2 Oct 2009 08:25:24 +0000 (GMT)
Subject: I: Changeset: redefined library_path_var for cygwin
Message-ID: <710626.89365.qm@web25506.mail.ukl.yahoo.com>

ping ?


> Da: Marco Atzeri <marco_atzeri at yahoo.it>
> Oggetto: Changeset: redefined library_path_var for cygwin
> A: octave-maintainers at octave.org
> Data: Venerd? 18 settembre 2009, 15:16
> John,
> this complete your previous patch
> 
> http://hg.savannah.gnu.org/hgweb/octave/rev/16907d1153d1
> 
> now "make check" works fine also for cygwin
> 
> Regards
> Marco
> 



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hg_path_patch
Type: application/octet-stream
Size: 1034 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091002/c5e36e78/attachment.obj 

From godfrey at isl.stanford.edu  Fri Oct  2 16:48:51 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Fri, 02 Oct 2009 14:48:51 -0700
Subject: changeset: Allow more relaxed font test
Message-ID: <4AC67543.606@isl.stanford.edu>

Fedora Linux systems seem to fail the current
font test when suitable fonts are available.  This
change results in fonts being found.  The reason
for the additional test, which this change comments out,
seems to be unclear.  I have left the test in the source
in case someone wants to explore  better ways of handling
the font matching.

Michael Godfrey

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: font_upd.diff
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091002/538afd48/attachment.ksh 

From shaiay at gmail.com  Sat Oct  3 02:55:29 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sat, 3 Oct 2009 09:55:29 +0200
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel scroll
	factor)
In-Reply-To: <19141.335.259271.430886@segfault.lan>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
Message-ID: <420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>

On Thu, Oct 1, 2009 at 9:21 PM, John W. Eaton <jwe at octave.org> wrote:
> ?image (rand (8, 10, 3))
> ?set (gca, 'xlim', [2, 4])
>
> I would expect something like the first image attached below
> (generated with the gnuplot backend), but I get the second. ?Oddly,
> the axis is resized to fill the screen if the window is refreshed (by
> placing another window on top of it then uncovering it, for example).
> I'm not sure what the proper fix is. ?Any clues?

I attach a changeset to fix these issues -- It clips the image
according to axes limits. It also fixes the limits of the image object
to take into account the real size of the image

Shai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image_fixes
Type: application/octet-stream
Size: 5314 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091003/898fd272/attachment.obj 

From jwe at octave.org  Sat Oct  3 09:48:38 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 3 Oct 2009 10:48:38 -0400
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel scroll
	factor)
In-Reply-To: <420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
Message-ID: <19143.25670.690133.336107@segfault.lan>

On  3-Oct-2009, Shai Ayal wrote:

| On Thu, Oct 1, 2009 at 9:21 PM, John W. Eaton <jwe at octave.org> wrote:
| > ?image (rand (8, 10, 3))
| > ?set (gca, 'xlim', [2, 4])
| >
| > I would expect something like the first image attached below
| > (generated with the gnuplot backend), but I get the second. ?Oddly,
| > the axis is resized to fill the screen if the window is refreshed (by
| > placing another window on top of it then uncovering it, for example).
| > I'm not sure what the proper fix is. ?Any clues?
| 
| I attach a changeset to fix these issues -- It clips the image
| according to axes limits. It also fixes the limits of the image object
| to take into account the real size of the image

I applied the patch, but it still does not seem to behave as I would
expect.  Now I see the following after doing

  image (rand (8, 10, 3))
  set (gca, 'xlim', [2, 4])

(first attached figure) when I would expect something more like the
gnuplot output (second attached figure).

Do you see a way to display the  partial pixels between x=[2,2.5] and
x=[3.5,4]?  Also, do you understand what is causing the odd scaling of
the axes?  they are adjusted if the figure window is redrawn (for
example, but covering it with another window and then uncovering it)?

jwe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: opengl.png
Type: image/png
Size: 12842 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091003/10878ec9/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnuplot.png
Type: image/png
Size: 9042 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091003/10878ec9/attachment-0003.png 

From shaiay at gmail.com  Sat Oct  3 10:30:03 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sat, 3 Oct 2009 17:30:03 +0200
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel scroll
	factor)
In-Reply-To: <19143.25670.690133.336107@segfault.lan>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
	<19143.25670.690133.336107@segfault.lan>
Message-ID: <420fb9e60910030830q6c5bb934r7e7b520cf48350a5@mail.gmail.com>

On Sat, Oct 3, 2009 at 4:48 PM, John W. Eaton <jwe at octave.org> wrote:
> On ?3-Oct-2009, Shai Ayal wrote:
>
> | On Thu, Oct 1, 2009 at 9:21 PM, John W. Eaton <jwe at octave.org> wrote:
> | > ?image (rand (8, 10, 3))
> | > ?set (gca, 'xlim', [2, 4])
> | >
> | > I would expect something like the first image attached below
> | > (generated with the gnuplot backend), but I get the second. ?Oddly,
> | > the axis is resized to fill the screen if the window is refreshed (by
> | > placing another window on top of it then uncovering it, for example).
> | > I'm not sure what the proper fix is. ?Any clues?
> |
> | I attach a changeset to fix these issues -- It clips the image
> | according to axes limits. It also fixes the limits of the image object
> | to take into account the real size of the image
>
> I applied the patch, but it still does not seem to behave as I would
> expect. ?Now I see the following after doing
>
> ?image (rand (8, 10, 3))
> ?set (gca, 'xlim', [2, 4])
>
> (first attached figure) when I would expect something more like the
> gnuplot output (second attached figure).
>
> Do you see a way to display the ?partial pixels between x=[2,2.5] and
> x=[3.5,4]?
No. This a limitation of OpenGL images -- no partial pixels. Do you
think this is serious enough to warrant a rewrite in terms of another
OpenGL primitive?

>?Also, do you understand what is causing the odd scaling of
> the axes? ?they are adjusted if the figure window is redrawn (for
> example, but covering it with another window and then uncovering it)?
I don't get it either.

Shai


From shaiay at gmail.com  Sat Oct  3 12:24:32 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sat, 3 Oct 2009 19:24:32 +0200
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel scroll
	factor)
In-Reply-To: <420fb9e60910030830q6c5bb934r7e7b520cf48350a5@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
	<19143.25670.690133.336107@segfault.lan>
	<420fb9e60910030830q6c5bb934r7e7b520cf48350a5@mail.gmail.com>
Message-ID: <420fb9e60910031024t559d0eb8kfa0b8e39ffda6ddb@mail.gmail.com>

On Sat, Oct 3, 2009 at 5:30 PM, Shai Ayal <shaiay at gmail.com> wrote:
> On Sat, Oct 3, 2009 at 4:48 PM, John W. Eaton <jwe at octave.org> wrote:
>> On ?3-Oct-2009, Shai Ayal wrote:
>>
>> | On Thu, Oct 1, 2009 at 9:21 PM, John W. Eaton <jwe at octave.org> wrote:
>> | > ?image (rand (8, 10, 3))
>> | > ?set (gca, 'xlim', [2, 4])
>> | >
>> | > I would expect something like the first image attached below
>> | > (generated with the gnuplot backend), but I get the second. ?Oddly,
>> | > the axis is resized to fill the screen if the window is refreshed (by
>> | > placing another window on top of it then uncovering it, for example).
>> | > I'm not sure what the proper fix is. ?Any clues?
>> |
>> | I attach a changeset to fix these issues -- It clips the image
>> | according to axes limits. It also fixes the limits of the image object
>> | to take into account the real size of the image
>>
>> I applied the patch, but it still does not seem to behave as I would
>> expect. ?Now I see the following after doing
>>
>> ?image (rand (8, 10, 3))
>> ?set (gca, 'xlim', [2, 4])
>>
>> (first attached figure) when I would expect something more like the
>> gnuplot output (second attached figure).
>>
>> Do you see a way to display the ?partial pixels between x=[2,2.5] and
>> x=[3.5,4]?
> No. This a limitation of OpenGL images -- no partial pixels. Do you
> think this is serious enough to warrant a rewrite in terms of another
> OpenGL primitive?
>
>>?Also, do you understand what is causing the odd scaling of
>> the axes? ?they are adjusted if the figure window is redrawn (for
>> example, but covering it with another window and then uncovering it)?
> I don't get it either.
Maybe it's because image sets axes.xlimmode  and axes.ylimmode to be manual?
If I do
image (rand (8, 10, 3))
set (gca, 'ylimmode', 'auto', 'xlimmode', 'auto')
set (gca, 'xlim', [2, 5])
then it looks as expected.

However, I still don't understand why redrawing the figure corrects this.

Shai


From tmacchant at yahoo.co.jp  Sat Oct  3 19:32:53 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Sun, 4 Oct 2009 09:32:53 +0900 (JST)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <20090930111533.90584.qmail@web3806.mail.bbt.yahoo.co.jp>
Message-ID: <20091004003253.40645.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello John

--- Tatsuro MATSUOKA wrote:
> 
> Although Benjamin said "so I would't need to have it dealt with in octave's configure script", I
> propose here the patch for FLTK_LDFLAGS.
> 
> Regards
> 
> Tatsuro

http://www.nabble.com/Re%3A-fltk-config-for-windows-gives--mwindows-flag-(was-octave-3.3.50-built-by-mingw-gcc-4.4.0-cannot-be-executed.)-p25679117.html

Could you please reply me whether my proposal is accepted or not ?

My building script of octave for development branch depends on the patch being accepted or not.

In case of rejection, I should add a few context of hacking  of fltk-config in my build script.

Regards

Tatsuro

--------------------------------------
Yahoo! JAPAN - Internet Security for teenagers and parents.
http://pr.mail.yahoo.co.jp/security/

From soren at hauberg.org  Sun Oct  4 16:01:17 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sun, 04 Oct 2009 23:01:17 +0200
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel
	scroll factor)
In-Reply-To: <420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
Message-ID: <1254690077.5143.30.camel@sh-t400>

l?r, 03 10 2009 kl. 09:55 +0200, skrev Shai Ayal:
> On Thu, Oct 1, 2009 at 9:21 PM, John W. Eaton <jwe at octave.org> wrote:
> >  image (rand (8, 10, 3))
> >  set (gca, 'xlim', [2, 4])
> >
> > I would expect something like the first image attached below
> > (generated with the gnuplot backend), but I get the second.  Oddly,
> > the axis is resized to fill the screen if the window is refreshed (by
> > placing another window on top of it then uncovering it, for example).
> > I'm not sure what the proper fix is.  Any clues?
> 
> I attach a changeset to fix these issues -- It clips the image
> according to axes limits. It also fixes the limits of the image object
> to take into account the real size of the image

I tried the code in the repository, and it's nice to see images in FLTK
(it's the only feature I really miss; I don't mind using gnuplot for
printing). However, it seems plotting on top of images behave somewhat
odd, in that the image appears on top of the plot. To see this, try

  imshow (rand (100, 100, 3))
  hold on, plot (1:100, 50*sin(linspace (0, 2*pi, 100))+50, "linewidth",
10), hold off


in both backends.

S?ren


From shaiay at gmail.com  Sun Oct  4 23:43:57 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 5 Oct 2009 06:43:57 +0200
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel scroll
	factor)
In-Reply-To: <1254690077.5143.30.camel@sh-t400>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
	<1254690077.5143.30.camel@sh-t400>
Message-ID: <420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>

On Sun, Oct 4, 2009 at 11:01 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> l?r, 03 10 2009 kl. 09:55 +0200, skrev Shai Ayal:
>> On Thu, Oct 1, 2009 at 9:21 PM, John W. Eaton <jwe at octave.org> wrote:
>> > ?image (rand (8, 10, 3))
>> > ?set (gca, 'xlim', [2, 4])
>> >
>> > I would expect something like the first image attached below
>> > (generated with the gnuplot backend), but I get the second. ?Oddly,
>> > the axis is resized to fill the screen if the window is refreshed (by
>> > placing another window on top of it then uncovering it, for example).
>> > I'm not sure what the proper fix is. ?Any clues?
>>
>> I attach a changeset to fix these issues -- It clips the image
>> according to axes limits. It also fixes the limits of the image object
>> to take into account the real size of the image
>
> I tried the code in the repository, and it's nice to see images in FLTK
> (it's the only feature I really miss; I don't mind using gnuplot for
> printing). However, it seems plotting on top of images behave somewhat
> odd, in that the image appears on top of the plot. To see this, try
>
> ?imshow (rand (100, 100, 3))
> ?hold on, plot (1:100, 50*sin(linspace (0, 2*pi, 100))+50, "linewidth",
> 10), hold off

The image is drawn at z=0, so to see the plot, you should plot the
libe aboce the z-plane:
 hold on, plot3 (1:100, 50*sin(linspace (0, 2*pi,
100))+50,ones(1,100), "linewidth",10), hold off, view(2)
Is this not the expected behavior?

Shai



>
> in both backends.
>
> S?ren
>
>


From soren at hauberg.org  Mon Oct  5 00:48:37 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Mon, 05 Oct 2009 07:48:37 +0200
Subject: opengl and images (was: Re: fltk backend fix & mouse wheel
	scroll  factor)
In-Reply-To: <420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
	<1254690077.5143.30.camel@sh-t400>
	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
Message-ID: <1254721717.4918.3.camel@sh-t400>

man, 05 10 2009 kl. 06:43 +0200, skrev Shai Ayal:
> The image is drawn at z=0, so to see the plot, you should plot the
> libe aboce the z-plane:
>  hold on, plot3 (1:100, 50*sin(linspace (0, 2*pi,
> 100))+50,ones(1,100), "linewidth",10), hold off, view(2)
> Is this not the expected behavior?

When I do this, I get the attached image. I would have expected to see
the sine curve on top of the image. This happens both with and without
the call to 'view'.

So, no, this is not the expected behaviour. Images should always be
shown below other graphics objects. This is really handy, when doing
image processing as it allows you to easily plot positions of objects on
top of the image.

S?ren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fltk.png
Type: image/png
Size: 51264 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091005/7f26a993/attachment-0001.png 

From godfrey at isl.stanford.edu  Mon Oct  5 01:15:28 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sun, 04 Oct 2009 23:15:28 -0700
Subject: opengl and images
In-Reply-To: <1254721717.4918.3.camel@sh-t400>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>	<19137.3438.750331.102963@segfault.lan>	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>	<19141.335.259271.430886@segfault.lan>	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>	<1254690077.5143.30.camel@sh-t400>	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400>
Message-ID: <4AC98F00.9070507@isl.stanford.edu>

On 10/04/2009 10:48 PM, S?ren Hauberg wrote:
> man, 05 10 2009 kl. 06:43 +0200, skrev Shai Ayal:
>> >  The image is drawn at z=0, so to see the plot, you should plot the
>> >  libe aboce the z-plane:
>> >    hold on, plot3 (1:100, 50*sin(linspace (0, 2*pi,
>> >  100))+50,ones(1,100), "linewidth",10), hold off, view(2)
>> >  Is this not the expected behavior?
> When I do this, I get the attached image. I would have expected to see
> the sine curve on top of the image. This happens both with and without
> the call to 'view'.
>
> So, no, this is not the expected behaviour. Images should always be
> shown below other graphics objects. This is really handy, when doing
> image processing as it allows you to easily plot positions of objects on
> top of the image.
>
> S?ren

Well, here is what I get using current development system and Fedora 
FC11_x86_64.  Attached.  Curve is on top.

I used:
backend("fltk")
imshow (rand (100, 100, 3))
hold on
plot3 (1:100, 50*sin(linspace (0, 2*pi,100))+50,ones(1,100),"linewidth",10)
hold off
view(2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: im_test.png
Type: image/png
Size: 62097 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091004/2c448c58/attachment-0001.png 

From shaiay at gmail.com  Mon Oct  5 02:55:26 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 5 Oct 2009 09:55:26 +0200
Subject: opengl and images
In-Reply-To: <4AC98F00.9070507@isl.stanford.edu>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
	<1254690077.5143.30.camel@sh-t400>
	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400> <4AC98F00.9070507@isl.stanford.edu>
Message-ID: <420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>

On Mon, Oct 5, 2009 at 8:15 AM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 10/04/2009 10:48 PM, S?ren Hauberg wrote:
>>
>> man, 05 10 2009 kl. 06:43 +0200, skrev Shai Ayal:
>>>
>>> > ?The image is drawn at z=0, so to see the plot, you should plot the
>>> > ?libe aboce the z-plane:
>>> > ? ?hold on, plot3 (1:100, 50*sin(linspace (0, 2*pi,
>>> > ?100))+50,ones(1,100), "linewidth",10), hold off, view(2)
>>> > ?Is this not the expected behavior?
>>
>> When I do this, I get the attached image. I would have expected to see
>> the sine curve on top of the image. This happens both with and without
>> the call to 'view'.
>>
>> So, no, this is not the expected behaviour. Images should always be
>> shown below other graphics objects. This is really handy, when doing
>> image processing as it allows you to easily plot positions of objects on
>> top of the image.
>>
>> S?ren
>
> Well, here is what I get using current development system and Fedora
> FC11_x86_64. ?Attached. ?Curve is on top.
>
> I used:
> backend("fltk")
> imshow (rand (100, 100, 3))
> hold on
> plot3 (1:100, 50*sin(linspace (0, 2*pi,100))+50,ones(1,100),"linewidth",10)
> hold off
> view(2)
>

Maybe it's a driver issue? -- what graphics card do you use, and what
is the output of
glxinfo|grep render

Shai


From soren at hauberg.org  Mon Oct  5 03:12:29 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Mon, 05 Oct 2009 10:12:29 +0200
Subject: opengl and images
In-Reply-To: <420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19137.3438.750331.102963@segfault.lan>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
	<1254690077.5143.30.camel@sh-t400>
	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400> <4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
Message-ID: <1254730349.4403.4.camel@sh-t400>

man, 05 10 2009 kl. 09:55 +0200, skrev Shai Ayal:
> Maybe it's a driver issue? -- what graphics card do you use, and what
> is the output of
> glxinfo|grep render

I'm not sure if you were asking me or Michael, but I have an Intel card,
and I get the following form glxinfo

        No kernel support for execution fencing, disabling texture
        tiling
        direct rendering: Yes
        OpenGL renderer string: Mesa DRI Mobile Intel? GM45 Express
        Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2

If you look at the image I sent, you will see that the curve appears
under the image, so both objects are rendered. My _guess_ is that the
two objects have the same depth, and their order becomes somewhat
arbitrary.

S?ren


From michael.goffioul at gmail.com  Mon Oct  5 03:19:54 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Mon, 5 Oct 2009 09:19:54 +0100
Subject: opengl and images
In-Reply-To: <1254730349.4403.4.camel@sh-t400>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<420fb9e60909302319q580b560biefe54b565d156ded@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
	<1254690077.5143.30.camel@sh-t400>
	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400> <4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
	<1254730349.4403.4.camel@sh-t400>
Message-ID: <128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>

On Mon, Oct 5, 2009 at 9:12 AM, S?ren Hauberg <soren at hauberg.org> wrote:
> man, 05 10 2009 kl. 09:55 +0200, skrev Shai Ayal:
>> Maybe it's a driver issue? -- what graphics card do you use, and what
>> is the output of
>> glxinfo|grep render
>
> I'm not sure if you were asking me or Michael, but I have an Intel card,
> and I get the following form glxinfo
>
> ? ? ? ?No kernel support for execution fencing, disabling texture
> ? ? ? ?tiling
> ? ? ? ?direct rendering: Yes
> ? ? ? ?OpenGL renderer string: Mesa DRI Mobile Intel? GM45 Express
> ? ? ? ?Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2
>
> If you look at the image I sent, you will see that the curve appears
> under the image, so both objects are rendered. My _guess_ is that the
> two objects have the same depth, and their order becomes somewhat
> arbitrary.

Drawing coplanar primitives in OpenGL is not reliable and you can't
rely on the draw order to put one on top of the other (especially as
computation is done in float, not double). When dealing with polygons,
you can use glPolygonOffset, but I'm not sure glDrawPixels is sensitive
to that setting.

Michael.


From shaiay at gmail.com  Mon Oct  5 03:21:33 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 5 Oct 2009 10:21:33 +0200
Subject: opengl and images
In-Reply-To: <128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<19141.335.259271.430886@segfault.lan>
	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>
	<1254690077.5143.30.camel@sh-t400>
	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400> <4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
	<1254730349.4403.4.camel@sh-t400>
	<128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
Message-ID: <420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>

On Mon, Oct 5, 2009 at 10:19 AM, Michael Goffioul
<michael.goffioul at gmail.com> wrote:
> On Mon, Oct 5, 2009 at 9:12 AM, S?ren Hauberg <soren at hauberg.org> wrote:
>> man, 05 10 2009 kl. 09:55 +0200, skrev Shai Ayal:
>>> Maybe it's a driver issue? -- what graphics card do you use, and what
>>> is the output of
>>> glxinfo|grep render
>>
>> I'm not sure if you were asking me or Michael, but I have an Intel card,
>> and I get the following form glxinfo
>>
>> ? ? ? ?No kernel support for execution fencing, disabling texture
>> ? ? ? ?tiling
>> ? ? ? ?direct rendering: Yes
>> ? ? ? ?OpenGL renderer string: Mesa DRI Mobile Intel? GM45 Express
>> ? ? ? ?Chipset GEM 20090712 2009Q2 RC3 x86/MMX/SSE2
>>
>> If you look at the image I sent, you will see that the curve appears
>> under the image, so both objects are rendered. My _guess_ is that the
>> two objects have the same depth, and their order becomes somewhat
>> arbitrary.
>
> Drawing coplanar primitives in OpenGL is not reliable and you can't
> rely on the draw order to put one on top of the other (especially as
> computation is done in float, not double). When dealing with polygons,
> you can use glPolygonOffset, but I'm not sure glDrawPixels is sensitive
> to that setting.

This is very strange, since using plot3 we explicitly asked the line
to be displayed above the z-plane.
This could stem from one of two reasons:
1. Driver bug
2. OpenGL spec alloows for images to be drawn after all other primitives?

I will look into the OpenGL spec later (have to do my real job now...)

Shai


From lindnerben at gmx.net  Mon Oct  5 13:51:50 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 05 Oct 2009 20:51:50 +0200
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <20090930111533.90584.qmail@web3806.mail.bbt.yahoo.co.jp>
References: <20090930111533.90584.qmail@web3806.mail.bbt.yahoo.co.jp>
Message-ID: <4ACA4046.8050005@gmx.net>


>> For the mingw binaries, since I need to build fltk from source, I can 
>> remove the -mwindows flag there from fltk-config, so I would't need to 
>> have it dealt with in octave's configure script.
>>
>> Does this problem also occur on cygwin?
>>
>> If we deal with this in octave's configure script, then I'd suggest it 
>> be done only for mingw (and cygwn?) platform.
>>
>> sed -e "+s-mwindows++g"
> The above is typo. sed -e "s+-mwindows++g" is correct. 

You are right, sorry.

> 
>> Hi Tatsuro,
>> currently fltk don't work on cygwin; at least for me.
>> The windows is created but only garbage is plotted.
> 
> Although Benjamin said "so I would't need to have it dealt with in octave's configure script", I
> propose here the patch for FLTK_LDFLAGS.

You can avoid the code duplication in the call to fltk-config by doing

diff -r a65c135a1deb configure.in
--- a/configure.in      Mon Oct 05 19:22:13 2009 +0200
+++ b/configure.in      Mon Oct 05 20:30:33 2009 +0200
@@ -847,6 +847,11 @@
    FLTK_CFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --cflags`"
    FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags`"

+  case "$canonical_host_type" in
+  *-*-mingw*)
+    FLTK_LDFLAGS="`echo $FLTK_LDFLAGS | sed -e 's+-mwindows++g'`"
+  esac
+
    AC_MSG_CHECKING(for OpenGL support in FLTK)
    cat > conftest.cc <<EOF
    #include <FL/gl.h>


benjamin

From tmacchant at yahoo.co.jp  Mon Oct  5 16:32:07 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 6 Oct 2009 06:32:07 +0900 (JST)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <4ACA4046.8050005@gmx.net>
Message-ID: <20091005213207.53087.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello

--- Benjamin Lindner  wrote:

> You can avoid the code duplication in the call to fltk-config by doing
> 
> diff -r a65c135a1deb configure.in
> --- a/configure.in      Mon Oct 05 19:22:13 2009 +0200
> +++ b/configure.in      Mon Oct 05 20:30:33 2009 +0200
> @@ -847,6 +847,11 @@
>     FLTK_CFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --cflags`"
>     FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags`"
> 
> +  case "$canonical_host_type" in
> +  *-*-mingw*)
> +    FLTK_LDFLAGS="`echo $FLTK_LDFLAGS | sed -e 's+-mwindows++g'`"
> +  esac
> +
>     AC_MSG_CHECKING(for OpenGL support in FLTK)
>     cat > conftest.cc <<EOF
>     #include <FL/gl.h>


Thanks!!

Regards

Tatsuro

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

From godfrey at isl.stanford.edu  Mon Oct  5 17:20:31 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Mon, 05 Oct 2009 15:20:31 -0700
Subject: opengl and images
In-Reply-To: <420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>	<19141.335.259271.430886@segfault.lan>	<420fb9e60910030055n726f1ac7o47e9c6c684389c2d@mail.gmail.com>	<1254690077.5143.30.camel@sh-t400>	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>	<1254721717.4918.3.camel@sh-t400>
	<4AC98F00.9070507@isl.stanford.edu>	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>	<1254730349.4403.4.camel@sh-t400>	<128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
	<420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>
Message-ID: <4ACA712F.6050507@isl.stanford.edu>

On 10/05/2009 01:21 AM, Shai Ayal wrote:
> This is very strange, since using plot3 we explicitly asked the line
> to be displayed above the z-plane.
> This could stem from one of two reasons:
> 1. Driver bug
> 2. OpenGL spec alloows for images to be drawn after all other primitives?
>
> I will look into the OpenGL spec later (have to do my real job now...)
>
> Shai
>    
It is known that OpenGL has various errors depending on
drivers, etc.  Here is what you get if you type opengl('info')
in  M:
 >> opengl('info')

Version         = 1.4 (2.1.2 NVIDIA 185.18.36)
Vendor          = NVIDIA Corporation
Renderer        = GeForce 6200 TurboCache(TM)/PCI/SSE2
MaxTextureSize  = 4096
Visual          = 0x21 (TrueColor, depth 24, RGB mask 0xff0000 0xff00 
0x00ff)
Software        = false
# of Extensions = 79

Driver Bug Workarounds:
OpenGLBitmapZbufferBug    = 0
OpenGLWobbleTesselatorBug = 0
OpenGLLineSmoothingBug    = 0
OpenGLClippedImageBug     = 1
OpenGLEraseModeBug        = 0




From thomas.weber.mail at gmail.com  Mon Oct  5 23:34:11 2009
From: thomas.weber.mail at gmail.com (Thomas Weber)
Date: Tue, 6 Oct 2009 06:34:11 +0200
Subject: Octave 3.2.3
In-Reply-To: <69d8d540909202250t5ba6dbafne607e65c63828888@mail.gmail.com>
References: <69d8d540909202250t5ba6dbafne607e65c63828888@mail.gmail.com>
Message-ID: <20091006043411.GA18753@atlan>

On Mon, Sep 21, 2009 at 07:50:11AM +0200, Jaroslav Hajek wrote:
> hi all,
> 
> with another small delay, here are the 3.2.3 release tarballs:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 
> thanks to all contributors for their help.

octave-3.2.3/doc/interpreter/HTML/voronoi.png
is an empty file in both the .gz and .bz2 tarballs. 

	Thomas

From shaiay at gmail.com  Tue Oct  6 00:39:19 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 6 Oct 2009 07:39:19 +0200
Subject: opengl and images
In-Reply-To: <4ACA712F.6050507@isl.stanford.edu>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254690077.5143.30.camel@sh-t400>
	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400> <4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
	<1254730349.4403.4.camel@sh-t400>
	<128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
	<420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>
	<4ACA712F.6050507@isl.stanford.edu>
Message-ID: <420fb9e60910052239l1502620fva008b208d2eb9013@mail.gmail.com>

On Tue, Oct 6, 2009 at 12:20 AM, Michael D. Godfrey
<godfrey at isl.stanford.edu> wrote:
> It is known that OpenGL has various errors depending on
> drivers, etc. ?Here is what you get if you type opengl('info')
> in ?M:
>>> opengl('info')
>
> Version ? ? ? ? = 1.4 (2.1.2 NVIDIA 185.18.36)
> Vendor ? ? ? ? ?= NVIDIA Corporation
> Renderer ? ? ? ?= GeForce 6200 TurboCache(TM)/PCI/SSE2
> MaxTextureSize ?= 4096
> Visual ? ? ? ? ?= 0x21 (TrueColor, depth 24, RGB mask 0xff0000 0xff00
> 0x00ff)
> Software ? ? ? ?= false
> # of Extensions = 79
>
> Driver Bug Workarounds:
> OpenGLBitmapZbufferBug ? ?= 0
> OpenGLWobbleTesselatorBug = 0
> OpenGLLineSmoothingBug ? ?= 0
> OpenGLClippedImageBug ? ? = 1
> OpenGLEraseModeBug ? ? ? ?= 0
>

Maybe the "OpenGLBitmapZbufferBug" is the problem we are seeing here,
but I'm not sure.
Superficially reading thee opengl docs I don't see anything to suggest
that what we are seeing is a bug in the driver, but I can't see
anything to suggest that isn't either ...

To workaround this in the opengl-renderer would mean to use textures
for images. This is complicated since textures have maximal size and
are limited to powers of two in their dimensions.
Another workaround is to use surface objects for images.
Yet another workaround is to use mesa software rendering. In debian,
this worked for me:
apt-get install libgl1-mesa-swx11-dev libgl1-mesa-swx11-i686
However, this will disable opengl hardware acceleration, which might
be a high price to pay.

Shai


From soren at hauberg.org  Tue Oct  6 01:05:30 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Tue, 06 Oct 2009 08:05:30 +0200
Subject: opengl and images
In-Reply-To: <420fb9e60910052239l1502620fva008b208d2eb9013@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254690077.5143.30.camel@sh-t400>
	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400> <4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
	<1254730349.4403.4.camel@sh-t400>
	<128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
	<420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>
	<4ACA712F.6050507@isl.stanford.edu>
	<420fb9e60910052239l1502620fva008b208d2eb9013@mail.gmail.com>
Message-ID: <1254809130.4620.2.camel@sh-t400>

tir, 06 10 2009 kl. 07:39 +0200, skrev Shai Ayal:
> Yet another workaround is to use mesa software rendering. In debian,
> this worked for me:
> apt-get install libgl1-mesa-swx11-dev libgl1-mesa-swx11-i686
> However, this will disable opengl hardware acceleration, which might
> be a high price to pay.

Yeah, at least for me this is not an option. I'm working fairly close
with graphics / physics-simulation people at the moment, so I'm highly
dependent on OpenGL :-(

I guess the proper cause of action depends on how many people are
actually experiencing this issue. If I'm the only one, then I guess it
doesn't make sense to invest too much work here.

S?ren


From michael.goffioul at gmail.com  Tue Oct  6 01:30:01 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Tue, 6 Oct 2009 07:30:01 +0100
Subject: opengl and images
In-Reply-To: <420fb9e60910052239l1502620fva008b208d2eb9013@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400> <4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
	<1254730349.4403.4.camel@sh-t400>
	<128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
	<420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>
	<4ACA712F.6050507@isl.stanford.edu>
	<420fb9e60910052239l1502620fva008b208d2eb9013@mail.gmail.com>
Message-ID: <128f38bd0910052330p6028298ew37cfe8ecb7c9e05c@mail.gmail.com>

On Tue, Oct 6, 2009 at 6:39 AM, Shai Ayal <shaiay at gmail.com> wrote:
> To workaround this in the opengl-renderer would mean to use textures
> for images. This is complicated since textures have maximal size and
> are limited to powers of two in their dimensions.

The latter can be worked around by using the rectangular texture
extension, which hopefully is available in many graphics cards today.
If it's not, then too bad, we can't do miracles. To solve the former problem,
you need to decompose the original image into sub-elements that fit
the maximum texture size, then select the right texture and compute
the right coordinates. This is indeed not trivial.

> Another workaround is to use surface objects for images.

Surface objects use textures mapping. The problem is the same.

> Yet another workaround is to use mesa software rendering. In debian,
> this worked for me:
> apt-get install libgl1-mesa-swx11-dev libgl1-mesa-swx11-i686
> However, this will disable opengl hardware acceleration, which might
> be a high price to pay.

Indeed....

Michael.

From shaiay at gmail.com  Tue Oct  6 02:51:28 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 6 Oct 2009 09:51:28 +0200
Subject: opengl and images
In-Reply-To: <128f38bd0910052330p6028298ew37cfe8ecb7c9e05c@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400> <4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
	<1254730349.4403.4.camel@sh-t400>
	<128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
	<420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>
	<4ACA712F.6050507@isl.stanford.edu>
	<420fb9e60910052239l1502620fva008b208d2eb9013@mail.gmail.com>
	<128f38bd0910052330p6028298ew37cfe8ecb7c9e05c@mail.gmail.com>
Message-ID: <420fb9e60910060051p3f9b2740o33067e23c73c9812@mail.gmail.com>

On Tue, Oct 6, 2009 at 8:30 AM, Michael Goffioul
<michael.goffioul at gmail.com> wrote:
> On Tue, Oct 6, 2009 at 6:39 AM, Shai Ayal <shaiay at gmail.com> wrote:
>> Another workaround is to use surface objects for images.
>
> Surface objects use textures mapping. The problem is the same.

I meant using the actual image as a surface using the
surface.facecolor property and flat shading. This will probably be
very inefficient, but should work in all conditions since the image
pixels will be OpenGL polygons

Shai

From bpabbott at mac.com  Tue Oct  6 07:18:41 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Tue, 06 Oct 2009 08:18:41 -0400
Subject: inconsequential eigs.cc test failure
Message-ID: <73E1C4F8-AF7A-497B-881B-F3DEB5E7E582@mac.com>

I occasionally get the failure below.

 >>>>> processing /Users/bpabbott/Development/mercurial/local_clone/ 
src/DLD-FUNCTIONS/eigs.cc
   ***** testif HAVE_ARPACK
  [v1,d1] = eigs(A, k, 'si');
  d1 = diag(d1);
  for i=1:k
   assert(max(abs((A - d1(i)*eye(n))*v1(:,i))),0.,1e-11)
  endfor
!!!!! test failed
assert (max (abs ((A - d1 (i) * eye (n)) * v1 (:, i))),0.,1e-11)  
expected
0
but got
  8.2063e-11
maximum absolute error 8.20629e-11 exceeds tolerance 1e-11>>>>>  
processing /Users/bpabbott/Development/mercurial/local_clone/src/DLD- 
FUNCTIONS/fft.cc

Is there any objection to an increase in the tolerance for the test  
script?

Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset-eigs.patch
Type: application/octet-stream
Size: 32332 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091006/acd3586c/attachment-0001.obj 

From jwe at octave.org  Wed Oct  7 13:39:31 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 7 Oct 2009 14:39:31 -0400
Subject: overloaded functions vs. internals
Message-ID: <19148.57443.35090.598585@segfault.lan>

Given the following class constructor and method:

  @foo/foo.m:
  function x = foo ()
    x = class (struct (), 'foo');
  end

  @foo/size.m:
  function s = size (x)
    s = [13, 42];
  end

Octave will do the following:

  octave> x = foo ();
  octave> size (x)
  ans =

     13   42

  octave> whos x
  Variables in the current scope:

    Attr Name        Size                     Bytes  Class
    ==== ====        ====                     =====  ===== 
	 x           1x1                          0  foo

The problem is that internally, whos is computing size using the
octave_value::dims function, and that does not call size, even though
the octave_value::size function has been overloaded to call a
user-defined size method if it is available.

Fixing whos to call size instead of using dims, and then construct the
dimension string from that fixes the problem for whos.  As a quick fix
for the person who reported this problem to me, I checked in the
following change:

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

However, the problem remains for any other internal function that
calls dims on a class object that has an overloaded size function.

I started working on a better fix, but ran into problems with const.
For example, I would like to replace the current octave_class::dims
function with

  dim_vector
  octave_class::dims (void) const
  {
    // Be consistent with size if it is overloaded with a user-defined
    // method.

    Matrix sz = size ();

    dim_vector dv (sz.numel ());

    for (int i = 0; i < dv.length (); i++)
      dv(i) = sz(i);

    return dv;
  }

but this won't work because size is not const (and can't be; see
below).  Dropping the const qualifier from the dims function is not
desirable, because dims is used in many other const functions, so it
would cause a cascade of const removal.  I don't think we want that.

So why isn't the octave_value::size method constant?  Because the
octave_class definition of size is

  Matrix
  octave_class::size (void)
  {
    Matrix retval (1, 2, 1.0);
    octave_value meth = symbol_table::find_method ("size", class_name ());

    if (meth.is_defined ())
      {
	count++;
	octave_value_list args (1, octave_value (this));

	octave_value_list lv = feval (meth.function_value (), args, 1);
	if (lv.length () == 1 && lv(0).is_matrix_type () && lv(0).dims ().is_vector ())
	  retval = lv(0).matrix_value ();
	else
	  error ("@%s/size: invalid return value");
      }

    return retval;
  }

Note the lines

	count++;
	octave_value_list args (1, octave_value (this));

This sets up the argument list for the call to the user-defined
method.  We have to increment the reference count of the octave_class
object when we put it inside a new octave_value object so that it can
go in the argument list.  Since count is a member of
octave_base_value, and octave_class is derived from that,
octave_class::size can't be const.

My next thought was to make count mutable, but that is not sufficient
because if octave_value::size is const, then "this" is const inside
octave_value::size, and although we have an

  octave_value::octave_value (octave_base_value *)

constructor, there is no

  octave_value::octave_value (const octave_base_value *)

constructor because octave_value::rep is not const and copying the
const argument to the non-const rep won't work.  And anyway, rep can't
be const if we want to call any non-const member functions through the
rep pointer.

So, I'm a bit stuck here.  Any thoughts about how to get out of this
mess?

Ideally, I'd like to find a solution for the const problem so that we
can call overloaded methods without having to give up const.  Perhaps
there is something simple that I'm missing, but I just don't see a
solution at the moment.

Note that this problem affects much more than just dims and size.  It
is potentially trouble for any octave_value member function that is
used to implement a scripting language funtion that can be overloaded
by a user-defined method for a class object.  For example, numel, nnz,
rows, columns, etc.  Even though these work properly for overloaded
methods in the scripting language, if the corresponding octave_value
method is called internally, it will not call the overloaded function.
For example, if the function

  @foo/nnz.m:
  function n = nnz (x)
    n = 100;
  end

is added to the foo class shown above, then it will be called for

  nnz (foo ())

But, the following function shows that  the corresponding internal
octave_value::nnz funtion will not call the overloaded method:

  #include <octave/oct.h>

  DEFUN_DLD (doit, args, , "")
  {
    octave_value_list retval;

    if (args.length () == 1)
      retval(1) = args(0).nnz ();
    else
      print_usage ();

    return retval;
  }

Using this function, I see

  octave> doit (foo ())
  error: octave_base_value::nnz (): wrong type argument `class'

Comments or suggestions?

Thanks,

jwe

From highegg at gmail.com  Wed Oct  7 15:09:40 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 7 Oct 2009 22:09:40 +0200
Subject: overloaded functions vs. internals
In-Reply-To: <19148.57443.35090.598585@segfault.lan>
References: <19148.57443.35090.598585@segfault.lan>
Message-ID: <69d8d540910071309s146827b6g3640ffd27a791050@mail.gmail.com>

On Wed, Oct 7, 2009 at 8:39 PM, John W. Eaton <jwe at octave.org> wrote:
> Given the following class constructor and method:
>
> ?@foo/foo.m:
> ?function x = foo ()
> ? ?x = class (struct (), 'foo');
> ?end
>
> ?@foo/size.m:
> ?function s = size (x)
> ? ?s = [13, 42];
> ?end
>
> Octave will do the following:
>
> ?octave> x = foo ();
> ?octave> size (x)
> ?ans =
>
> ? ? 13 ? 42
>
> ?octave> whos x
> ?Variables in the current scope:
>
> ? ?Attr Name ? ? ? ?Size ? ? ? ? ? ? ? ? ? ? Bytes ?Class
> ? ?==== ==== ? ? ? ?==== ? ? ? ? ? ? ? ? ? ? ===== ?=====
> ? ? ? ? x ? ? ? ? ? 1x1 ? ? ? ? ? ? ? ? ? ? ? ? ?0 ?foo
>
> The problem is that internally, whos is computing size using the
> octave_value::dims function, and that does not call size, even though
> the octave_value::size function has been overloaded to call a
> user-defined size method if it is available.
>
> Fixing whos to call size instead of using dims, and then construct the
> dimension string from that fixes the problem for whos. ?As a quick fix
> for the person who reported this problem to me, I checked in the
> following change:
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/bb413c0d0d6d
>
> However, the problem remains for any other internal function that
> calls dims on a class object that has an overloaded size function.
>
> I started working on a better fix, but ran into problems with const.
> For example, I would like to replace the current octave_class::dims
> function with
>
> ?dim_vector
> ?octave_class::dims (void) const
> ?{
> ? ?// Be consistent with size if it is overloaded with a user-defined
> ? ?// method.
>
> ? ?Matrix sz = size ();
>
> ? ?dim_vector dv (sz.numel ());
>
> ? ?for (int i = 0; i < dv.length (); i++)
> ? ? ?dv(i) = sz(i);
>
> ? ?return dv;
> ?}
>
> but this won't work because size is not const (and can't be; see
> below). ?Dropping the const qualifier from the dims function is not
> desirable, because dims is used in many other const functions, so it
> would cause a cascade of const removal. ?I don't think we want that.
>
> So why isn't the octave_value::size method constant? ?Because the
> octave_class definition of size is
>
> ?Matrix
> ?octave_class::size (void)
> ?{
> ? ?Matrix retval (1, 2, 1.0);
> ? ?octave_value meth = symbol_table::find_method ("size", class_name ());
>
> ? ?if (meth.is_defined ())
> ? ? ?{
> ? ? ? ?count++;
> ? ? ? ?octave_value_list args (1, octave_value (this));
>
> ? ? ? ?octave_value_list lv = feval (meth.function_value (), args, 1);
> ? ? ? ?if (lv.length () == 1 && lv(0).is_matrix_type () && lv(0).dims ().is_vector ())
> ? ? ? ? ?retval = lv(0).matrix_value ();
> ? ? ? ?else
> ? ? ? ? ?error ("@%s/size: invalid return value");
> ? ? ?}
>
> ? ?return retval;
> ?}
>
> Note the lines
>
> ? ? ? ?count++;
> ? ? ? ?octave_value_list args (1, octave_value (this));
>
> This sets up the argument list for the call to the user-defined
> method. ?We have to increment the reference count of the octave_class
> object when we put it inside a new octave_value object so that it can
> go in the argument list. ?Since count is a member of
> octave_base_value, and octave_class is derived from that,
> octave_class::size can't be const.
>
> My next thought was to make count mutable, but that is not sufficient
> because if octave_value::size is const, then "this" is const inside
> octave_value::size, and although we have an
>
> ?octave_value::octave_value (octave_base_value *)
>
> constructor, there is no
>
> ?octave_value::octave_value (const octave_base_value *)
>
> constructor because octave_value::rep is not const and copying the
> const argument to the non-const rep won't work. ?And anyway, rep can't
> be const if we want to call any non-const member functions through the
> rep pointer.
>
> So, I'm a bit stuck here. ?Any thoughts about how to get out of this
> mess?
>
> Ideally, I'd like to find a solution for the const problem so that we
> can call overloaded methods without having to give up const. ?Perhaps
> there is something simple that I'm missing, but I just don't see a
> solution at the moment.
>

I mostly thought along the same lines when I was improving
octave_class - that's why I decided to create a separate non-const
size() method (previously, octave_value::size existed but only called
dims() and thus wasn't much useful), that will behave correctly even
with classes. It returns a Matrix because the original
octave_value::size did so and also because a user-defined size()
method may actually return something more complicated than a canonical
dim_vector.

Btw., for the same reason there is numel (void) const and numel (const
octave_value_list&), the latter calling overloaded numel() for classes
but the former not.

This seemed to me as the least painful approach, because I found out
the same difficulties as you did.
Currently, IMHO the only const-clean approach to do what you would
like to is to construct
octave_value (this->clone ()) and pass that to the method. That
involves some overhead of duplicating the object's internals - map and
parent_list. map is reference counted, so copying it is actually quite
cheap, parent_list is worse, but probably easily acceptable.
A dirty alternative, of course, is going via const_cast.

I didn't do it myself when thinking of it because I wasn't so sure it
is a good idea to let dims() call overloaded size() method. I think an
infinite recursion might easily occur, given how often dims() is
called. There should be some mechanism to get the internal dims, and
to avoid the recursion. map_value ().dims () will work, but is not
very nice.

Generally, I think one usually wants to handle classes as a separate
case anyway, so it doesn't hurt much to have separate methods. For
instance, currently dims() never generates an error; that would also
change. But I don't really object to such changes, just pointing out
possible problems.
The same solution and similar arguments apply to the other const
methods you refer to below.

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  Thu Oct  8 04:49:38 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 8 Oct 2009 11:49:38 +0200
Subject: overloaded functions vs. internals
In-Reply-To: <69d8d540910071309s146827b6g3640ffd27a791050@mail.gmail.com>
References: <19148.57443.35090.598585@segfault.lan>
	<69d8d540910071309s146827b6g3640ffd27a791050@mail.gmail.com>
Message-ID: <69d8d540910080249q21287096h11f6699ce629f082@mail.gmail.com>

On Wed, Oct 7, 2009 at 10:09 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Wed, Oct 7, 2009 at 8:39 PM, John W. Eaton <jwe at octave.org> wrote:
>> Given the following class constructor and method:
>>
>> ?@foo/foo.m:
>> ?function x = foo ()
>> ? ?x = class (struct (), 'foo');
>> ?end
>>
>> ?@foo/size.m:
>> ?function s = size (x)
>> ? ?s = [13, 42];
>> ?end
>>
>> Octave will do the following:
>>
>> ?octave> x = foo ();
>> ?octave> size (x)
>> ?ans =
>>
>> ? ? 13 ? 42
>>
>> ?octave> whos x
>> ?Variables in the current scope:
>>
>> ? ?Attr Name ? ? ? ?Size ? ? ? ? ? ? ? ? ? ? Bytes ?Class
>> ? ?==== ==== ? ? ? ?==== ? ? ? ? ? ? ? ? ? ? ===== ?=====
>> ? ? ? ? x ? ? ? ? ? 1x1 ? ? ? ? ? ? ? ? ? ? ? ? ?0 ?foo
>>
>> The problem is that internally, whos is computing size using the
>> octave_value::dims function, and that does not call size, even though
>> the octave_value::size function has been overloaded to call a
>> user-defined size method if it is available.
>>
>> Fixing whos to call size instead of using dims, and then construct the
>> dimension string from that fixes the problem for whos. ?As a quick fix
>> for the person who reported this problem to me, I checked in the
>> following change:
>>
>> ?http://hg.savannah.gnu.org/hgweb/octave/rev/bb413c0d0d6d
>>
>> However, the problem remains for any other internal function that
>> calls dims on a class object that has an overloaded size function.
>>
>> I started working on a better fix, but ran into problems with const.
>> For example, I would like to replace the current octave_class::dims
>> function with
>>
>> ?dim_vector
>> ?octave_class::dims (void) const
>> ?{
>> ? ?// Be consistent with size if it is overloaded with a user-defined
>> ? ?// method.
>>
>> ? ?Matrix sz = size ();
>>
>> ? ?dim_vector dv (sz.numel ());
>>
>> ? ?for (int i = 0; i < dv.length (); i++)
>> ? ? ?dv(i) = sz(i);
>>
>> ? ?return dv;
>> ?}
>>
>> but this won't work because size is not const (and can't be; see
>> below). ?Dropping the const qualifier from the dims function is not
>> desirable, because dims is used in many other const functions, so it
>> would cause a cascade of const removal. ?I don't think we want that.
>>
>> So why isn't the octave_value::size method constant? ?Because the
>> octave_class definition of size is
>>
>> ?Matrix
>> ?octave_class::size (void)
>> ?{
>> ? ?Matrix retval (1, 2, 1.0);
>> ? ?octave_value meth = symbol_table::find_method ("size", class_name ());
>>
>> ? ?if (meth.is_defined ())
>> ? ? ?{
>> ? ? ? ?count++;
>> ? ? ? ?octave_value_list args (1, octave_value (this));
>>
>> ? ? ? ?octave_value_list lv = feval (meth.function_value (), args, 1);
>> ? ? ? ?if (lv.length () == 1 && lv(0).is_matrix_type () && lv(0).dims ().is_vector ())
>> ? ? ? ? ?retval = lv(0).matrix_value ();
>> ? ? ? ?else
>> ? ? ? ? ?error ("@%s/size: invalid return value");
>> ? ? ?}
>>
>> ? ?return retval;
>> ?}
>>
>> Note the lines
>>
>> ? ? ? ?count++;
>> ? ? ? ?octave_value_list args (1, octave_value (this));
>>
>> This sets up the argument list for the call to the user-defined
>> method. ?We have to increment the reference count of the octave_class
>> object when we put it inside a new octave_value object so that it can
>> go in the argument list. ?Since count is a member of
>> octave_base_value, and octave_class is derived from that,
>> octave_class::size can't be const.
>>
>> My next thought was to make count mutable, but that is not sufficient
>> because if octave_value::size is const, then "this" is const inside
>> octave_value::size, and although we have an
>>
>> ?octave_value::octave_value (octave_base_value *)
>>
>> constructor, there is no
>>
>> ?octave_value::octave_value (const octave_base_value *)
>>
>> constructor because octave_value::rep is not const and copying the
>> const argument to the non-const rep won't work. ?And anyway, rep can't
>> be const if we want to call any non-const member functions through the
>> rep pointer.
>>
>> So, I'm a bit stuck here. ?Any thoughts about how to get out of this
>> mess?
>>
>> Ideally, I'd like to find a solution for the const problem so that we
>> can call overloaded methods without having to give up const. ?Perhaps
>> there is something simple that I'm missing, but I just don't see a
>> solution at the moment.
>>
>
> I mostly thought along the same lines when I was improving
> octave_class - that's why I decided to create a separate non-const
> size() method (previously, octave_value::size existed but only called
> dims() and thus wasn't much useful), that will behave correctly even
> with classes. It returns a Matrix because the original
> octave_value::size did so and also because a user-defined size()
> method may actually return something more complicated than a canonical
> dim_vector.
>
> Btw., for the same reason there is numel (void) const and numel (const
> octave_value_list&), the latter calling overloaded numel() for classes
> but the former not.
>
> This seemed to me as the least painful approach, because I found out
> the same difficulties as you did.
> Currently, IMHO the only const-clean approach to do what you would
> like to is to construct
> octave_value (this->clone ()) and pass that to the method. That
> involves some overhead of duplicating the object's internals - map and
> parent_list. map is reference counted, so copying it is actually quite
> cheap, parent_list is worse, but probably easily acceptable.
> A dirty alternative, of course, is going via const_cast.
>
> I didn't do it myself when thinking of it because I wasn't so sure it
> is a good idea to let dims() call overloaded size() method. I think an
> infinite recursion might easily occur, given how often dims() is
> called. There should be some mechanism to get the internal dims, and
> to avoid the recursion. map_value ().dims () will work, but is not
> very nice.
>
> Generally, I think one usually wants to handle classes as a separate
> case anyway, so it doesn't hurt much to have separate methods. For
> instance, currently dims() never generates an error; that would also
> change. But I don't really object to such changes, just pointing out
> possible problems.
> The same solution and similar arguments apply to the other const
> methods you refer to below.
>
> regards
>

In fact I realized that I myself made exactly the mistake I was just
warning against:
http://hg.savannah.gnu.org/hgweb/octave/rev/5acd99c3e794

the problem is that octave_value::numel (const octave_value_list&)
can, unlike other methods, call a user-defined class method, or even
user-defined size() method. But you don't want to call it from within
the builtin numel, because then if you called
builtin("numel",obj) from within the overloaded numel for obj, it
would end up in an infinite recursion.
Another possibility would be to employ a similar trick like the one
within octave_class::subsref and octave_class::subsasgn and check for
called_from_builtin inside octave_class::numel (const
octave_value_list&).
But I don't like that approach very much - it can be fooled around,
though with some difficulty.

In short, when calling an octave_value::some_method from C++, there is
no magic to tell whether you mean some_method(obj,...) or
builtin("some_method", obj). Currently, most of the octave_value
methods correspond to the second form (i.e. builtin), except a small
set of methods intimately connected to indexing: size(), numel (const
octave_value_list&), subsref, subsasgn.
(Note that all of them are non-const).
While the former two have their built-in-only counterpart (basically,
dims()), the latter two check the call stack to determine which form
is meant. That is convenient and will sometimes do just the right
thing, but in other cases it can fail. Even now it's not bulletproof:
for instance, using eval("object.field") inside a class subsref method
while you're handling object.field triggers an infinite recursion, but
maybe we can improve it.
It would be even better if we had subsref/subsref_with_overload
subsasgn/subsasgn_with_overload or something like that, but that would
require massive changes now.

regards

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


From tmacchant at yahoo.co.jp  Thu Oct  8 05:33:53 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 8 Oct 2009 19:33:53 +0900 (JST)
Subject: Resubmission of changeset for configure.ac of develpoment branch for
	fltk-config issue of octave/mingw 
Message-ID: <20091008103353.22875.qmail@web3812.mail.bbt.yahoo.co.jp>

Hello

After the discussion the below, I have once submit a changeset 
http://www.nabble.com/octave-3.3.50-built-by-mingw-gcc-4.4.0-cannot-be-executed.-td25569527.html

However, there have been no reply.
Therefore I resubmit a changeset to remove '-mwindows' option from fltk-config output for correct
building octave on mingw platform.

Regards

Tatsuro

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fltk-config_mingw.changeset
Type: application/x-unknown
Size: 770 bytes
Desc: 2999286454-fltk-config_mingw.changeset
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091008/0ff60370/attachment.bin 

From tmacchant at yahoo.co.jp  Thu Oct  8 06:08:08 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 8 Oct 2009 20:08:08 +0900 (JST)
Subject: Search of pgnuplot is obsolated for mingw, cygwin abd  msvc
Message-ID: <20091008110808.18286.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello

Name of console mode gnuplot for windows was determined to be 'gnuplot.exe' not 'pgnuplot.exe' by
gnuplot team.
In addition, the original pgnuplot is no longer to be used from octave.

I think that search for pgnuplot is obsolete and harmful. 

So I propose that search of pgnuplot is eliminated from configure process.

The below patch is for the latest 3.2.x source trees.
Perhaps this should also be applied to the development branch sources.
 

--- a/aclocal.m4 2009-08-06 16:46:40.062500000 +0900
+++ b/aclocal.m4  2009-10-08 19:57:42.703125000 +0900
@@ -476,16 +476,8 @@
 dnl Does gnuplot exist?
 dnl
 AC_DEFUN(OCTAVE_PROG_GNUPLOT, [
-case "$canonical_host_type" in
-  *-*-cygwin* | *-*-mingw32* | *-*-msdosmsvc)
-    gp_names="pgnuplot pipe-gnuplot gnuplot"
-    gp_default=pgnuplot
-  ;;
-  *)
-    gp_names=gnuplot
-    gp_default=gnuplot
-  ;;
-esac
+  gp_names=gnuplot
+  gp_default=gnuplot
 if test "$cross_compiling" = yes; then
   GNUPLOT="$gp_default"
   AC_MSG_RESULT(assuming $GNUPLOT exists on $canonical_host_type host)

**********

Regards

Tatsuro

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

From highegg at gmail.com  Thu Oct  8 09:15:34 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 8 Oct 2009 16:15:34 +0200
Subject: best way to use new qrupdate version?
Message-ID: <69d8d540910080715t59918bb6ufc0a1663d66f1e33@mail.gmail.com>

hi John,

in version 1.1, which I intend to release later this year, qrupdate
will be able to compute rank-1 updates of LU and pivoted LU
factorizations. The SVN version already has the functionality. I want
to make the feature again available to Octave via a "luupdate"
function. The bulk of the code for Octave is already upstream:
http://hg.savannah.gnu.org/hgweb/octave/rev/6f3ffe11d926

Because there is 100% backward compatibility, I would like Octave stay
buildable with qrupdate 1.0, which by now has already spread to
several distros. The approach I've taken in the above patch is simply
check for one of the new functions after qrupdate was detected, and
define an additional macro. But maybe that is not the best idea? Does
anyone see a better way?
qrupdate uses a F77-style implicit interface, so there is no header
file, which could define a versioning symbol.
An alternative is to make qrupdate 1.1 a requirement for Octave 3.4,
but it seems nice to support the old version if it's compatible.

comments?

-- 
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 Oct  8 15:06:54 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 8 Oct 2009 16:06:54 -0400
Subject: best way to use new qrupdate version?
In-Reply-To: <69d8d540910080715t59918bb6ufc0a1663d66f1e33@mail.gmail.com>
References: <69d8d540910080715t59918bb6ufc0a1663d66f1e33@mail.gmail.com>
Message-ID: <19150.18014.859201.785451@segfault.lan>

On  8-Oct-2009, Jaroslav Hajek wrote:

| in version 1.1, which I intend to release later this year, qrupdate
| will be able to compute rank-1 updates of LU and pivoted LU
| factorizations. The SVN version already has the functionality. I want
| to make the feature again available to Octave via a "luupdate"
| function. The bulk of the code for Octave is already upstream:
| http://hg.savannah.gnu.org/hgweb/octave/rev/6f3ffe11d926
| 
| Because there is 100% backward compatibility, I would like Octave stay
| buildable with qrupdate 1.0, which by now has already spread to
| several distros. The approach I've taken in the above patch is simply
| check for one of the new functions after qrupdate was detected, and
| define an additional macro. But maybe that is not the best idea? Does
| anyone see a better way?
| qrupdate uses a F77-style implicit interface, so there is no header
| file, which could define a versioning symbol.

Couldn't you define a function that returns a version string?  But
even if you did that, I think a version test is not really a
desirable thing to do in a configure script, and doing it with a
function requires running a program, not just linking, so that can
cause trouble for cross compiling (if that even matters for us).

| An alternative is to make qrupdate 1.1 a requirement for Octave 3.4,
| but it seems nice to support the old version if it's compatible.

I guess the choice is yours.  Qrupdate is small and easy to build
though, isn't it?  So it would not be a big burden to require the new
version.  OTOH, if the older version will work (possibly with some
loss of functionality) then continuing to allow its use would be OK
with me.

To check in configure, you could do something like this (untested):

save_LIBS="$LIBS"
LIBS="$BLAS_LIBS $FLIBS $LIBS"
OCTAVE_CHECK_LIBRARY(qrupdate, qrupdate,
  [qrupdate not found.  The QR & Cholesky updating functions will be slow.],
  [],
  [F77_FUNC(sqr1up,SQR1UP)],
  [], [don't use qrupdate, disable QR & Cholesky updating functions],
  [warn_qrupdate=
   AC_CHECK_FUNCS([F77_FUNC(other_qrupdate_fcn,OTHER_QRUPDATE_FCN)],
    [AC_DEFINE(HAVE_OTHER_QRUPDATE_FCN, 1)],
    [warn_qrupdate="other_qrupdate_fcn missing; some loss of functionality"])])
LIBS="$save_LIBS"

jwe

From highegg at gmail.com  Fri Oct  9 01:05:51 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 9 Oct 2009 08:05:51 +0200
Subject: best way to use new qrupdate version?
In-Reply-To: <19150.18014.859201.785451@segfault.lan>
References: <69d8d540910080715t59918bb6ufc0a1663d66f1e33@mail.gmail.com>
	<19150.18014.859201.785451@segfault.lan>
Message-ID: <69d8d540910082305m72790d1fx91da0fb2142cba82@mail.gmail.com>

On Thu, Oct 8, 2009 at 10:06 PM, John W. Eaton <jwe at octave.org> wrote:
> On ?8-Oct-2009, Jaroslav Hajek wrote:
>
> | in version 1.1, which I intend to release later this year, qrupdate
> | will be able to compute rank-1 updates of LU and pivoted LU
> | factorizations. The SVN version already has the functionality. I want
> | to make the feature again available to Octave via a "luupdate"
> | function. The bulk of the code for Octave is already upstream:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/6f3ffe11d926
> |
> | Because there is 100% backward compatibility, I would like Octave stay
> | buildable with qrupdate 1.0, which by now has already spread to
> | several distros. The approach I've taken in the above patch is simply
> | check for one of the new functions after qrupdate was detected, and
> | define an additional macro. But maybe that is not the best idea? Does
> | anyone see a better way?
> | qrupdate uses a F77-style implicit interface, so there is no header
> | file, which could define a versioning symbol.
>
> Couldn't you define a function that returns a version string? ?But
> even if you did that, I think a version test is not really a
> desirable thing to do in a configure script, and doing it with a
> function requires running a program, not just linking, so that can
> cause trouble for cross compiling (if that even matters for us).
>
> | An alternative is to make qrupdate 1.1 a requirement for Octave 3.4,
> | but it seems nice to support the old version if it's compatible.
>
> I guess the choice is yours. ?Qrupdate is small and easy to build
> though, isn't it? ?So it would not be a big burden to require the new
> version. ?OTOH, if the older version will work (possibly with some
> loss of functionality) then continuing to allow its use would be OK
> with me.
>
> To check in configure, you could do something like this (untested):
>
> save_LIBS="$LIBS"
> LIBS="$BLAS_LIBS $FLIBS $LIBS"
> OCTAVE_CHECK_LIBRARY(qrupdate, qrupdate,
> ?[qrupdate not found. ?The QR & Cholesky updating functions will be slow.],
> ?[],
> ?[F77_FUNC(sqr1up,SQR1UP)],
> ?[], [don't use qrupdate, disable QR & Cholesky updating functions],
> ?[warn_qrupdate=
> ? AC_CHECK_FUNCS([F77_FUNC(other_qrupdate_fcn,OTHER_QRUPDATE_FCN)],
> ? ?[AC_DEFINE(HAVE_OTHER_QRUPDATE_FCN, 1)],
> ? ?[warn_qrupdate="other_qrupdate_fcn missing; some loss of functionality"])])
> LIBS="$save_LIBS"
>
> jwe
>

It's close to what I did, except that I split the tests based on
$octave_qrupdate_ok defined from the first test.
If that's OK, I'll leave it as it is.

regards

-- 
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  Fri Oct  9 04:03:32 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 9 Oct 2009 05:03:32 -0400
Subject: best way to use new qrupdate version?
In-Reply-To: <69d8d540910082305m72790d1fx91da0fb2142cba82@mail.gmail.com>
References: <69d8d540910080715t59918bb6ufc0a1663d66f1e33@mail.gmail.com>
	<19150.18014.859201.785451@segfault.lan>
	<69d8d540910082305m72790d1fx91da0fb2142cba82@mail.gmail.com>
Message-ID: <19150.64612.435048.34441@segfault.lan>

On  9-Oct-2009, Jaroslav Hajek wrote:

| It's close to what I did, except that I split the tests based on
| $octave_qrupdate_ok defined from the first test.
| If that's OK, I'll leave it as it is.

The EXTRA-CHECK argument for OCTAVE_CHECK_LIBRARY is expanded inside
both AC_LANG_PUSH/POP and an if $octave_LIBRARY_ok shell test, so it
would be a little more concise to use the extra argument for
OCTAVE_CHECK_LIBRARY.

jwe

From shaiay at gmail.com  Fri Oct  9 08:40:22 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Fri, 9 Oct 2009 15:40:22 +0200
Subject: Fix for fltk zoom box problems
Message-ID: <420fb9e60910090640l2e1f2315n4648463e131de80b@mail.gmail.com>

On Tue, Sep 29, 2009 at 2:00 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> tir, 29 09 2009 kl. 13:42 +0200, skrev Shai Ayal:
>> On Tue, Sep 29, 2009 at 1:40 PM, S?ren Hauberg <soren at hauberg.org> wrote:
>> > tir, 29 09 2009 kl. 13:38 +0200, skrev Shai Ayal:
>> >> I think this is an issue with the overlays, like I use to draw the
>> >> zoom rubber-band. I might try to draw it normally, not in an overlay
>> >> (maybe adding a cool blue transparent rectangle like in the gnuplot
>> >> wxt terminal).
>> >
>> > I don't see any rubber-band during drag-zoom, so this sounds like part
>> > of the problem.
>> >
>> Do the problems start when you try to zoom with the right button, or
>> are they always there?
>
> Everything works until I start dragging with the right button down.

I attach a (trivial) fix which should work -- it simply bypasses the
OpenGL overlay and draws the zoom box (now in cool transparent grey!)
normally.
Please try

Shai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fltk_overlay_fix
Type: application/octet-stream
Size: 1730 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091009/e84db3da/attachment.obj 

From octave at nomad.inbox5.com  Fri Oct  9 12:06:29 2009
From: octave at nomad.inbox5.com (Rik)
Date: Fri, 09 Oct 2009 10:06:29 -0700
Subject: Patch to stop counting missing tests on internal functions
Message-ID: <MTAwMDAyMS5ub21hZA.1255107996@quikprotect>

10/8/09

All,

Currently when a user runs 'make check' there is a report which shows a
large number of files that don't have tests written for them and then
invites the user to contribute tests.  On looking through the list,
however, there are about 60 functions which are for internal use only as
designated by the prefix and suffix "__".   An example is __contourc__.cc

My proposed patch to fntests.m would remove these from the report of
functions missing tests. (This is *only* about reporting.  If tests for
internal functions have been written they would still continue to be
run.)  First, if these internal functions need coverage they should get
it from tests written by the function which calls them.  In the example
given, there is already a test in contourc.m which presumably would
catch an error in the internal function.  Secondly, if a user does have
a few spare moments to write a test for a function we will get more
value for the coding effort if they concentrate on functions that people
might use all the time rather than internal ones.

Thoughts?  If there are no strong objections I'll apply the patch in a
few days.

Cheers,
Rik
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.no_count_internal_functions
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091009/c72b0c63/attachment.ksh 

From soren at hauberg.org  Sat Oct 10 12:55:05 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sat, 10 Oct 2009 19:55:05 +0200
Subject: opengl and images
In-Reply-To: <1254809130.4620.2.camel@sh-t400>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<1254690077.5143.30.camel@sh-t400>
	<420fb9e60910042143q7cae66fdw2740fe86e8dfab55@mail.gmail.com>
	<1254721717.4918.3.camel@sh-t400> <4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
	<1254730349.4403.4.camel@sh-t400>
	<128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
	<420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>
	<4ACA712F.6050507@isl.stanford.edu>
	<420fb9e60910052239l1502620fva008b208d2eb9013@mail.gmail.com>
	<1254809130.4620.2.camel@sh-t400>
Message-ID: <1255197305.4615.5.camel@sh-t400>

tir, 06 10 2009 kl. 08:05 +0200, skrev S?ren Hauberg:
> tir, 06 10 2009 kl. 07:39 +0200, skrev Shai Ayal:
> > Yet another workaround is to use mesa software rendering. In debian,
> > this worked for me:
> > apt-get install libgl1-mesa-swx11-dev libgl1-mesa-swx11-i686
> > However, this will disable opengl hardware acceleration, which might
> > be a high price to pay.
> 
> Yeah, at least for me this is not an option. I'm working fairly close
> with graphics / physics-simulation people at the moment, so I'm highly
> dependent on OpenGL :-(
> 
> I guess the proper cause of action depends on how many people are
> actually experiencing this issue. If I'm the only one, then I guess it
> doesn't make sense to invest too much work here.

For some reason the Intel graphics driver broke for me recently. I have
one of these fancy laptops that both have an Intel and an AMD graphics
card, so I've changed to use the AMD card (using the FGLRX driver).

Using this card / driver I still see the issue where the image is on top
of the plot. So, this is not a driver issue.

S?ren


From soren at hauberg.org  Sat Oct 10 13:23:11 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sat, 10 Oct 2009 20:23:11 +0200
Subject: Fix for fltk zoom box problems
In-Reply-To: <420fb9e60910090640l2e1f2315n4648463e131de80b@mail.gmail.com>
References: <420fb9e60910090640l2e1f2315n4648463e131de80b@mail.gmail.com>
Message-ID: <1255198991.4615.12.camel@sh-t400>

fre, 09 10 2009 kl. 15:40 +0200, skrev Shai Ayal:
> I attach a (trivial) fix which should work -- it simply bypasses the
> OpenGL overlay and draws the zoom box (now in cool transparent grey!)
> normally.
> Please try

Hey, this is quite neat. Due to driver issues I have not been able to
test with my Intel card, but this works great on my AMD card.

Attached is a trivial change that

  * draws a border around the overlay,
  * changes the colour to a Tango [1] colour.

This is a pure visual change, so feel free to ignore it, though.

The current code allows you to zoom outside the range of the current
axes. I'm not sure if the range of the zoom box should be fixed to the
range of the current axes.

S?ren

[1] http://tango.freedesktop.org/Tango_Desktop_Project
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fltk_overlay_with_border.patch
Type: text/x-patch
Size: 855 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091010/05943cd1/attachment.bin 

From shaiay at gmail.com  Sat Oct 10 14:32:49 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sat, 10 Oct 2009 21:32:49 +0200
Subject: Fix for fltk zoom box problems
In-Reply-To: <1255198991.4615.12.camel@sh-t400>
References: <420fb9e60910090640l2e1f2315n4648463e131de80b@mail.gmail.com>
	<1255198991.4615.12.camel@sh-t400>
Message-ID: <420fb9e60910101232j49d957d9gc6077d72bba5e09e@mail.gmail.com>

On Sat, Oct 10, 2009 at 8:23 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> fre, 09 10 2009 kl. 15:40 +0200, skrev Shai Ayal:
>> I attach a (trivial) fix which should work -- it simply bypasses the
>> OpenGL overlay and draws the zoom box (now in cool transparent grey!)
>> normally.
>> Please try
>
> Hey, this is quite neat. Due to driver issues I have not been able to
> test with my Intel card, but this works great on my AMD card.
>
> Attached is a trivial change that
>
> ?* draws a border around the overlay,
> ?* changes the colour to a Tango [1] colour.
>
> This is a pure visual change, so feel free to ignore it, though.

I'll use it and send a complete changeset soon

> The current code allows you to zoom outside the range of the current
> axes. I'm not sure if the range of the zoom box should be fixed to the
> range of the current axes.

I'm not sure this is a bad thing -- I used this feature in gnuplot
from time to time, although the zoom/pan interface is better suited to
small corrections.

Shai


From shaiay at gmail.com  Sat Oct 10 15:38:43 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sat, 10 Oct 2009 22:38:43 +0200
Subject: Fix for fltk zoom box problems
In-Reply-To: <420fb9e60910101232j49d957d9gc6077d72bba5e09e@mail.gmail.com>
References: <420fb9e60910090640l2e1f2315n4648463e131de80b@mail.gmail.com>
	<1255198991.4615.12.camel@sh-t400>
	<420fb9e60910101232j49d957d9gc6077d72bba5e09e@mail.gmail.com>
Message-ID: <420fb9e60910101338n313dc4ecu5e97be2dd769e742@mail.gmail.com>

On Sat, Oct 10, 2009 at 9:32 PM, Shai Ayal <shaiay at gmail.com> wrote:
> On Sat, Oct 10, 2009 at 8:23 PM, S?ren Hauberg <soren at hauberg.org> wrote:
>> fre, 09 10 2009 kl. 15:40 +0200, skrev Shai Ayal:
>>> I attach a (trivial) fix which should work -- it simply bypasses the
>>> OpenGL overlay and draws the zoom box (now in cool transparent grey!)
>>> normally.
>>> Please try
>>
>> Hey, this is quite neat. Due to driver issues I have not been able to
>> test with my Intel card, but this works great on my AMD card.
>>
>> Attached is a trivial change that
>>
>> ?* draws a border around the overlay,
>> ?* changes the colour to a Tango [1] colour.
>>
>> This is a pure visual change, so feel free to ignore it, though.
>
> I'll use it and send a complete changeset soon
I attach a changeset incorporating the Tange color & border. This
patch includes the previous patch I sent

Shai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fltk_overlay_fix2
Type: application/octet-stream
Size: 2379 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091010/57754696/attachment.obj 

From jwe at octave.org  Sun Oct 11 10:11:42 2009
From: jwe at octave.org (John W. Eaton)
Date: Sun, 11 Oct 2009 11:11:42 -0400
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <4AC25824.3010606@gmx.net>
References: <20090929082251.37122.qmail@web3814.mail.bbt.yahoo.co.jp>
	<4AC25824.3010606@gmx.net>
Message-ID: <19153.62894.211943.180064@hugo.lan>

On 29-Sep-2009, Benjamin Lindner wrote:

| I'd suggest
| 
| sed -e "+s-mwindows++g"
| 
| to be more robust.

Why do you say that is more robust?  If the pattern is a literal
string, then I think the only requirement is that the delimiters for
the sed command don't appaer in the pattern string.

jwe

From jwe at octave.org  Sun Oct 11 10:36:14 2009
From: jwe at octave.org (John W. Eaton)
Date: Sun, 11 Oct 2009 11:36:14 -0400
Subject: Assertion in symbol table due to Revision 8881
In-Reply-To: <4A485AF0.5090600@ieee.org>
References: <4A485AF0.5090600@ieee.org>
Message-ID: <19153.64366.409432.624499@hugo.lan>

On 29-Jun-2009, Daniel J Sebald wrote:

| The octave-core dump ends up being only 11 bytes long.

The octave-core file is just an octave save file that contains the
variables in the top-level workspace.  It is intended to help you
avoid losing all your work if Octave crashes.  But it seems that it is
a common misconception that this file can somehow be used for
debugging.  Maybe simply changing the name to be something like
octave-crash-workspace-PID would help avoid the confusion?  If there
is agreement, I can make this change.

jwe

From jwe at octave.org  Sun Oct 11 10:12:46 2009
From: jwe at octave.org (John W. Eaton)
Date: Sun, 11 Oct 2009 11:12:46 -0400
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <4ACA4046.8050005@gmx.net>
References: <20090930111533.90584.qmail@web3806.mail.bbt.yahoo.co.jp>
	<4ACA4046.8050005@gmx.net>
Message-ID: <19153.62958.446247.732431@hugo.lan>

On  5-Oct-2009, Benjamin Lindner wrote:

| >> For the mingw binaries, since I need to build fltk from source, I can 
| >> remove the -mwindows flag there from fltk-config, so I would't need to 
| >> have it dealt with in octave's configure script.
| >>
| >> Does this problem also occur on cygwin?
| >>
| >> If we deal with this in octave's configure script, then I'd suggest it 
| >> be done only for mingw (and cygwn?) platform.
| >>
| >> sed -e "+s-mwindows++g"
| > The above is typo. sed -e "s+-mwindows++g" is correct. 
| 
| You are right, sorry.
| 
| > 
| >> Hi Tatsuro,
| >> currently fltk don't work on cygwin; at least for me.
| >> The windows is created but only garbage is plotted.
| > 
| > Although Benjamin said "so I would't need to have it dealt with in octave's configure script", I
| > propose here the patch for FLTK_LDFLAGS.
| 
| You can avoid the code duplication in the call to fltk-config by doing
| 
| diff -r a65c135a1deb configure.in
| --- a/configure.in      Mon Oct 05 19:22:13 2009 +0200
| +++ b/configure.in      Mon Oct 05 20:30:33 2009 +0200
| @@ -847,6 +847,11 @@
|     FLTK_CFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --cflags`"
|     FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags`"
| 
| +  case "$canonical_host_type" in
| +  *-*-mingw*)
| +    FLTK_LDFLAGS="`echo $FLTK_LDFLAGS | sed -e 's+-mwindows++g'`"
| +  esac
| +
|     AC_MSG_CHECKING(for OpenGL support in FLTK)
|     cat > conftest.cc <<EOF
|     #include <FL/gl.h>

Only *-*-mingw*?  Would this also be a problem for *-*-msdosmsvc?

jwe

From lindnerben at gmx.net  Sun Oct 11 13:44:46 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sun, 11 Oct 2009 20:44:46 +0200
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <19153.62894.211943.180064@hugo.lan>
References: <20090929082251.37122.qmail@web3814.mail.bbt.yahoo.co.jp>	<4AC25824.3010606@gmx.net>
	<19153.62894.211943.180064@hugo.lan>
Message-ID: <4AD2279E.6010605@gmx.net>

John W. Eaton wrote:
> On 29-Sep-2009, Benjamin Lindner wrote:
> 
> | I'd suggest
> | 
> | sed -e "+s-mwindows++g"
> | 
> | to be more robust.
> 
> Why do you say that is more robust?  If the pattern is a literal
> string, then I think the only requirement is that the delimiters for
> the sed command don't appaer in the pattern string.

It's not about the delimiters, it's about the removed space character.

Tatsuro originally suggested
    sed -e 's/ -mwindows//'
which sould only match if there is at least one space character 
preceeding the token "-mwindows", correct?

IMO the replacement rule should remove "-mwindows" regardless if it is 
preceeded by a space or not (e.g. even if it is the first token in a string)

benjamin


From tmacchant at yahoo.co.jp  Sun Oct 11 15:02:16 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 12 Oct 2009 05:02:16 +0900 (JST)
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <19153.62958.446247.732431@hugo.lan>
Message-ID: <20091011200216.894.qmail@web3803.mail.bbt.yahoo.co.jp>

Hello

--- "John W. Eaton" wrote:

> Only *-*-mingw*?  Would this also be a problem for *-*-msdosmsvc?
> 
> jwe
> 

Similar problem may occur on msvc. However, the linker options of msvc have different style from those
of mingw.  I do not know how fltk-config for msvc pull the output of the msvc linker options. 
Therefore I limit my patch to the mingw case.


Regards

Tatsuro       

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

From michael.goffioul at gmail.com  Sun Oct 11 15:02:57 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Sun, 11 Oct 2009 21:02:57 +0100
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50 
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <19153.62958.446247.732431@hugo.lan>
References: <20090930111533.90584.qmail@web3806.mail.bbt.yahoo.co.jp>
	<4ACA4046.8050005@gmx.net> <19153.62958.446247.732431@hugo.lan>
Message-ID: <128f38bd0910111302i1cb9404aib9be492140d4f145@mail.gmail.com>

On Sun, Oct 11, 2009 at 4:12 PM, John W. Eaton <jwe at octave.org> wrote:
> | diff -r a65c135a1deb configure.in
> | --- a/configure.in ? ? ?Mon Oct 05 19:22:13 2009 +0200
> | +++ b/configure.in ? ? ?Mon Oct 05 20:30:33 2009 +0200
> | @@ -847,6 +847,11 @@
> | ? ? FLTK_CFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --cflags`"
> | ? ? FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags`"
> |
> | + ?case "$canonical_host_type" in
> | + ?*-*-mingw*)
> | + ? ?FLTK_LDFLAGS="`echo $FLTK_LDFLAGS | sed -e 's+-mwindows++g'`"
> | + ?esac
> | +
> | ? ? AC_MSG_CHECKING(for OpenGL support in FLTK)
> | ? ? cat > conftest.cc <<EOF
> | ? ? #include <FL/gl.h>
>
> Only *-*-mingw*? ?Would this also be a problem for *-*-msdosmsvc?

No. The -mwindows flag is only GCC specific.

Michael.


From michael.goffioul at gmail.com  Sun Oct 11 15:40:51 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Sun, 11 Oct 2009 21:40:51 +0100
Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50 
	built by mingw-gcc-4.4.0 cannot be executed.)
In-Reply-To: <20091011200216.894.qmail@web3803.mail.bbt.yahoo.co.jp>
References: <19153.62958.446247.732431@hugo.lan>
	<20091011200216.894.qmail@web3803.mail.bbt.yahoo.co.jp>
Message-ID: <128f38bd0910111340l4a0a5ad6x3de5ac97b698c25a@mail.gmail.com>

2009/10/11 Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>:
> Hello
>
> --- "John W. Eaton" wrote:
>
>> Only *-*-mingw*? ?Would this also be a problem for *-*-msdosmsvc?
>>
>> jwe
>>
>
> Similar problem may occur on msvc. However, the linker options of msvc have different style from those
> of mingw. ?I do not know how fltk-config for msvc pull the output of the msvc linker options.

There's no fltk-config for MSVC. I have one, because I compile FLTK
with my own toolchain that makes MSVC looks like GCC. But the
official FLTK build system for MSVC simply uses VS solution files.
No shell, no configure script, no fltk-config...

So in practice, my fltk-config script is simply as I want it to be.

Michael.


From shaiay at gmail.com  Sun Oct 11 15:55:13 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sun, 11 Oct 2009 22:55:13 +0200
Subject: c++ question
In-Reply-To: <128f38bd0910111348i328bc2b1r108fa11593f86dd3@mail.gmail.com>
References: <420fb9e60910100135o884aa0bs9a0904db297ed146@mail.gmail.com>
	<420fb9e60910101255t72e89fe7rdfdb9e479925e4c7@mail.gmail.com>
	<128f38bd0910111348i328bc2b1r108fa11593f86dd3@mail.gmail.com>
Message-ID: <420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>

Hi all,

This is a question I came across while trying to work on opengl
backend. At first I thought it was too trivial to ask on the list, so
I asked Michael privately, but since he agrees that it is strange, I
gained some self confidence and so I'm asking on the list :)
I am using gcc version 4.3.4 (Debian 4.3.4-5).

Any help would be apriciated. The definitions of the opengl_renderer
class are in src/gl-render.h

Shai

On Sat, Oct 10, 2009 at 8:55 PM, Shai Ayal <shaiay at gmail.com> wrote:
> On Sat, Oct 10, 2009 at 10:35 AM, Shai Ayal <shaiay at gmail.com> wrote:
>> Hi Michael,
>>
>> I'm trying to implement the gl2ps code in the gl-renderer, and I've
>> come across a c++ problem:
>> As a first step I tried to defined a subclass of opengl_render which
>> should override the draw method for a handle. In the new method gl2ps
>> will be initialized. This is the definition:
>> #include "gl-render.h"
>>
>> class
>> OCTINTERP_API
>> glps_renderer : public opengl_renderer
>> {
>> ?public:
>> ?glps_renderer (const std::string& _filename)
>> ? ?: opengl_renderer () , filename (_filename) { }
>>
>> ?~glps_renderer (void) { }
>>
>> ?void draw (const graphics_object& go);
>>
>> ?private:
>> ?std::string filename;
>>
>> };
>>
>> However, when I try to use this in the code:
>>
>> ? ? ? ?glps_renderer gl2ps (print_filename);
>> ? ? ? ?gl2ps.draw (gh_manager::lookup (number));
>>
>> The compiler complains that there is no matching function for call to
>> ?glps_renderer::draw(graphics_handle).
>>
>> I thought it would automatically use the base class
>> opengl_render::draw(graphics_handle) which would then call
>> glps_renderer::draw (const graphics_object& go);
>>
> OK, I think I figured it out :
> opengl_renderer *rend = new glps_renderer (print_filename);
> rend->draw (gh_manager::lookup (number));
>
> so it appears the compiler is able to do run time dynamic functions,
> but not compile time. Strange.
>
> Now for the next problem:
> the opengl_renderer::draw function is actually a dispatcher based upon
> the object type. The way I implemented the gl2ps renderer, I override
> the draw method, do the gl2ps initializations and then call
> opengl_renderer::draw.
> The problem is I would like to override some specific draw function
> (e.g. ?virtual void draw (const text::properties& props);), but
> instead of the glps_renderer version being called, the base
> opengl_renderer version is called. So when calling with a text object
> the sequence is:
>
> opengl_renderer::draw (const graphics_handle& h)
> glps_renderer::draw (const graphics_object& go);
> opengl_renderer::draw (const graphics_object& go);
> opengl_renderer::draw (const text::properties& props)
>
> although there is a glps_renderer::draw (const text::properties& props)
>
> Any thoughts?

Both problems are really weird. Basically, this *should* work
as you expect. For the first problem, you might try to use an
intermediate variable to store the graphics_handle object,
although I don't expect any difference. For the second problem,
I have no clue. Sorry.

Michael.


From trystan at trystan.org  Sun Oct 11 19:39:35 2009
From: trystan at trystan.org (Trystan Larey-Williams)
Date: Sun, 11 Oct 2009 17:39:35 -0700
Subject: c++ question
In-Reply-To: <420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>
References: <420fb9e60910100135o884aa0bs9a0904db297ed146@mail.gmail.com>	<420fb9e60910101255t72e89fe7rdfdb9e479925e4c7@mail.gmail.com>	<128f38bd0910111348i328bc2b1r108fa11593f86dd3@mail.gmail.com>
	<420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>
Message-ID: <4AD27AC7.6040903@trystan.org>

Have you tried declaring your child class version of the 'draw' function 
virtual as well? It has been my experience that some compilers require 
this.


-Trystan

Shai Ayal wrote:
> Hi all,
>
> This is a question I came across while trying to work on opengl
> backend. At first I thought it was too trivial to ask on the list, so
> I asked Michael privately, but since he agrees that it is strange, I
> gained some self confidence and so I'm asking on the list :)
> I am using gcc version 4.3.4 (Debian 4.3.4-5).
>
> Any help would be apriciated. The definitions of the opengl_renderer
> class are in src/gl-render.h
>
> Shai
>
> On Sat, Oct 10, 2009 at 8:55 PM, Shai Ayal <shaiay at gmail.com> wrote:
>   
>> On Sat, Oct 10, 2009 at 10:35 AM, Shai Ayal <shaiay at gmail.com> wrote:
>>     
>>> Hi Michael,
>>>
>>> I'm trying to implement the gl2ps code in the gl-renderer, and I've
>>> come across a c++ problem:
>>> As a first step I tried to defined a subclass of opengl_render which
>>> should override the draw method for a handle. In the new method gl2ps
>>> will be initialized. This is the definition:
>>> #include "gl-render.h"
>>>
>>> class
>>> OCTINTERP_API
>>> glps_renderer : public opengl_renderer
>>> {
>>>  public:
>>>  glps_renderer (const std::string& _filename)
>>>    : opengl_renderer () , filename (_filename) { }
>>>
>>>  ~glps_renderer (void) { }
>>>
>>>  void draw (const graphics_object& go);
>>>
>>>  private:
>>>  std::string filename;
>>>
>>> };
>>>
>>> However, when I try to use this in the code:
>>>
>>>        glps_renderer gl2ps (print_filename);
>>>        gl2ps.draw (gh_manager::lookup (number));
>>>
>>> The compiler complains that there is no matching function for call to
>>> ?glps_renderer::draw(graphics_handle).
>>>
>>> I thought it would automatically use the base class
>>> opengl_render::draw(graphics_handle) which would then call
>>> glps_renderer::draw (const graphics_object& go);
>>>
>>>       
>> OK, I think I figured it out :
>> opengl_renderer *rend = new glps_renderer (print_filename);
>> rend->draw (gh_manager::lookup (number));
>>
>> so it appears the compiler is able to do run time dynamic functions,
>> but not compile time. Strange.
>>
>> Now for the next problem:
>> the opengl_renderer::draw function is actually a dispatcher based upon
>> the object type. The way I implemented the gl2ps renderer, I override
>> the draw method, do the gl2ps initializations and then call
>> opengl_renderer::draw.
>> The problem is I would like to override some specific draw function
>> (e.g.  virtual void draw (const text::properties& props);), but
>> instead of the glps_renderer version being called, the base
>> opengl_renderer version is called. So when calling with a text object
>> the sequence is:
>>
>> opengl_renderer::draw (const graphics_handle& h)
>> glps_renderer::draw (const graphics_object& go);
>> opengl_renderer::draw (const graphics_object& go);
>> opengl_renderer::draw (const text::properties& props)
>>
>> although there is a void draw (const graphics_object& go);
>>
>> Any thoughts?
>>     
>
> Both problems are really weird. Basically, this *should* work
> as you expect. For the first problem, you might try to use an
> intermediate variable to store the graphics_handle object,
> although I don't expect any difference. For the second problem,
> I have no clue. Sorry.
>
> Michael.
>
>
>   


From shaiay at gmail.com  Sun Oct 11 23:34:13 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 12 Oct 2009 06:34:13 +0200
Subject: c++ question
In-Reply-To: <4AD27AC7.6040903@trystan.org>
References: <420fb9e60910100135o884aa0bs9a0904db297ed146@mail.gmail.com>
	<420fb9e60910101255t72e89fe7rdfdb9e479925e4c7@mail.gmail.com>
	<128f38bd0910111348i328bc2b1r108fa11593f86dd3@mail.gmail.com>
	<420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>
	<4AD27AC7.6040903@trystan.org>
Message-ID: <420fb9e60910112134p4ebb3eb6y805e506a55f01587@mail.gmail.com>

On Mon, Oct 12, 2009 at 2:39 AM, Trystan Larey-Williams
<trystan at trystan.org> wrote:
> Have you tried declaring your child class version of the 'draw' function
> virtual as well? It has been my experience that some compilers require this.
No, that didn;t work either ...

My declaration:
class
OCTINTERP_API
glps_renderer : public opengl_renderer
{
 public:
  glps_renderer (const std::string& _filename)
    : opengl_renderer () , filename (_filename) { }

  ~glps_renderer (void) { }

  virtual void draw (const graphics_object& go);

 protected:

  virtual void draw (const text::properties& props);

 private:
  std::string filename;

};

From highegg at gmail.com  Mon Oct 12 01:37:59 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 12 Oct 2009 08:37:59 +0200
Subject: c++ question
In-Reply-To: <420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>
References: <420fb9e60910100135o884aa0bs9a0904db297ed146@mail.gmail.com>
	<420fb9e60910101255t72e89fe7rdfdb9e479925e4c7@mail.gmail.com>
	<128f38bd0910111348i328bc2b1r108fa11593f86dd3@mail.gmail.com>
	<420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>
Message-ID: <69d8d540910112337y3f6af92fma2493372f56bccd5@mail.gmail.com>

On Sun, Oct 11, 2009 at 10:55 PM, Shai Ayal <shaiay at gmail.com> wrote:
> Hi all,
>
> This is a question I came across while trying to work on opengl
> backend. At first I thought it was too trivial to ask on the list, so
> I asked Michael privately, but since he agrees that it is strange, I
> gained some self confidence and so I'm asking on the list :)
> I am using gcc version 4.3.4 (Debian 4.3.4-5).
>
> Any help would be apriciated. The definitions of the opengl_renderer
> class are in src/gl-render.h
>
> Shai
>
> On Sat, Oct 10, 2009 at 8:55 PM, Shai Ayal <shaiay at gmail.com> wrote:
>> On Sat, Oct 10, 2009 at 10:35 AM, Shai Ayal <shaiay at gmail.com> wrote:
>>> Hi Michael,
>>>
>>> I'm trying to implement the gl2ps code in the gl-renderer, and I've
>>> come across a c++ problem:
>>> As a first step I tried to defined a subclass of opengl_render which
>>> should override the draw method for a handle. In the new method gl2ps
>>> will be initialized. This is the definition:
>>> #include "gl-render.h"
>>>
>>> class
>>> OCTINTERP_API
>>> glps_renderer : public opengl_renderer
>>> {
>>> ?public:
>>> ?glps_renderer (const std::string& _filename)
>>> ? ?: opengl_renderer () , filename (_filename) { }
>>>
>>> ?~glps_renderer (void) { }
>>>
>>> ?void draw (const graphics_object& go);
>>>
>>> ?private:
>>> ?std::string filename;
>>>
>>> };
>>>
>>> However, when I try to use this in the code:
>>>
>>> ? ? ? ?glps_renderer gl2ps (print_filename);
>>> ? ? ? ?gl2ps.draw (gh_manager::lookup (number));
>>>
>>> The compiler complains that there is no matching function for call to
>>> ?glps_renderer::draw(graphics_handle).
>>>
>>> I thought it would automatically use the base class
>>> opengl_render::draw(graphics_handle) which would then call
>>> glps_renderer::draw (const graphics_object& go);
>>>
>> OK, I think I figured it out :
>> opengl_renderer *rend = new glps_renderer (print_filename);
>> rend->draw (gh_manager::lookup (number));
>>
>> so it appears the compiler is able to do run time dynamic functions,
>> but not compile time. Strange.
>>

No, it would work the same if the methods were non-virtual, it plays
no role. What you see is a bit unknown C++ feature called "name
hiding". In short, methods from base class are not automatically
imported into the subclass namespace if there's an overloaded version
declared in the subclass. (Trust me, there are good reasons for this).

You can either import it explicitly:

class
OCTINTERP_API
glps_renderer : public opengl_renderer
{
 public:
   using opengl_renderer::draw;
 glps_renderer (const std::string& _filename)
   : opengl_renderer () , filename (_filename) { }

 ~glps_renderer (void) { }

 void draw (const graphics_object& go);

 private:
 std::string filename;

};

to the public section of gpls_renderer,

or make the call like this:

  glps_renderer gl2ps (print_filename);
  gl2ps.opengl_renderer::draw (gh_manager::lookup (number));


>> Now for the next problem:
>> the opengl_renderer::draw function is actually a dispatcher based upon
>> the object type. The way I implemented the gl2ps renderer, I override
>> the draw method, do the gl2ps initializations and then call
>> opengl_renderer::draw.
>> The problem is I would like to override some specific draw function
>> (e.g. ?virtual void draw (const text::properties& props);), but
>> instead of the glps_renderer version being called, the base
>> opengl_renderer version is called. So when calling with a text object
>> the sequence is:
>>
>> opengl_renderer::draw (const graphics_handle& h)
>> glps_renderer::draw (const graphics_object& go);
>> opengl_renderer::draw (const graphics_object& go);
>> opengl_renderer::draw (const text::properties& props)
>>
>> although there is a glps_renderer::draw (const text::properties& props)
>>
>> Any thoughts?
>

Please post your code, or a (not working) changeset. I'd like to help,
but I need more info.

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  Mon Oct 12 01:58:55 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 12 Oct 2009 08:58:55 +0200
Subject: Assertion in symbol table due to Revision 8881
In-Reply-To: <19153.64366.409432.624499@hugo.lan>
References: <4A485AF0.5090600@ieee.org> <19153.64366.409432.624499@hugo.lan>
Message-ID: <69d8d540910112358yf715e8dxa05d5d54530bcd8c@mail.gmail.com>

On Sun, Oct 11, 2009 at 5:36 PM, John W. Eaton <jwe at octave.org> wrote:
> On 29-Jun-2009, Daniel J Sebald wrote:
>
> | The octave-core dump ends up being only 11 bytes long.
>
> The octave-core file is just an octave save file that contains the
> variables in the top-level workspace. ?It is intended to help you
> avoid losing all your work if Octave crashes. ?But it seems that it is
> a common misconception that this file can somehow be used for
> debugging. ?Maybe simply changing the name to be something like
> octave-crash-workspace-PID would help avoid the confusion? ?If there
> is agreement, I can make this change.
>

I don't think so. Octave is very clearly saying
attempting to save variables to 'octave-core'...
so saved variables are what you should expect in the file, and a who
does not bother reading messages just gets what he deserves.
Besides, I think the core dump filename is already customizable.

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


From shaiay at gmail.com  Mon Oct 12 02:00:00 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 12 Oct 2009 09:00:00 +0200
Subject: c++ question
In-Reply-To: <69d8d540910112337y3f6af92fma2493372f56bccd5@mail.gmail.com>
References: <420fb9e60910100135o884aa0bs9a0904db297ed146@mail.gmail.com>
	<420fb9e60910101255t72e89fe7rdfdb9e479925e4c7@mail.gmail.com>
	<128f38bd0910111348i328bc2b1r108fa11593f86dd3@mail.gmail.com>
	<420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>
	<69d8d540910112337y3f6af92fma2493372f56bccd5@mail.gmail.com>
Message-ID: <420fb9e60910120000yca5971ap9c415eec93c55d7c@mail.gmail.com>

On Mon, Oct 12, 2009 at 8:37 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Sun, Oct 11, 2009 at 10:55 PM, Shai Ayal <shaiay at gmail.com> wrote:
>> Hi all,
>>
>> This is a question I came across while trying to work on opengl
>> backend. At first I thought it was too trivial to ask on the list, so
>> I asked Michael privately, but since he agrees that it is strange, I
>> gained some self confidence and so I'm asking on the list :)
>> I am using gcc version 4.3.4 (Debian 4.3.4-5).
>>
>> Any help would be apriciated. The definitions of the opengl_renderer
>> class are in src/gl-render.h
>>
>> Shai
>>
>> On Sat, Oct 10, 2009 at 8:55 PM, Shai Ayal <shaiay at gmail.com> wrote:
>>> On Sat, Oct 10, 2009 at 10:35 AM, Shai Ayal <shaiay at gmail.com> wrote:
>>>> Hi Michael,
>>>>
>>>> I'm trying to implement the gl2ps code in the gl-renderer, and I've
>>>> come across a c++ problem:
>>>> As a first step I tried to defined a subclass of opengl_render which
>>>> should override the draw method for a handle. In the new method gl2ps
>>>> will be initialized. This is the definition:
>>>> #include "gl-render.h"
>>>>
>>>> class
>>>> OCTINTERP_API
>>>> glps_renderer : public opengl_renderer
>>>> {
>>>> ?public:
>>>> ?glps_renderer (const std::string& _filename)
>>>> ? ?: opengl_renderer () , filename (_filename) { }
>>>>
>>>> ?~glps_renderer (void) { }
>>>>
>>>> ?void draw (const graphics_object& go);
>>>>
>>>> ?private:
>>>> ?std::string filename;
>>>>
>>>> };
>>>>
>>>> However, when I try to use this in the code:
>>>>
>>>> ? ? ? ?glps_renderer gl2ps (print_filename);
>>>> ? ? ? ?gl2ps.draw (gh_manager::lookup (number));
>>>>
>>>> The compiler complains that there is no matching function for call to
>>>> ?glps_renderer::draw(graphics_handle).
>>>>
>>>> I thought it would automatically use the base class
>>>> opengl_render::draw(graphics_handle) which would then call
>>>> glps_renderer::draw (const graphics_object& go);
>>>>
>>> OK, I think I figured it out :
>>> opengl_renderer *rend = new glps_renderer (print_filename);
>>> rend->draw (gh_manager::lookup (number));
>>>
>>> so it appears the compiler is able to do run time dynamic functions,
>>> but not compile time. Strange.
>>>
>
> No, it would work the same if the methods were non-virtual, it plays
> no role. What you see is a bit unknown C++ feature called "name
> hiding". In short, methods from base class are not automatically
> imported into the subclass namespace if there's an overloaded version
> declared in the subclass. (Trust me, there are good reasons for this).
>
> You can either import it explicitly:
>
> class
> OCTINTERP_API
> glps_renderer : public opengl_renderer
> {
> ?public:
> ? using opengl_renderer::draw;
> ?glps_renderer (const std::string& _filename)
> ? : opengl_renderer () , filename (_filename) { }
>
> ?~glps_renderer (void) { }
>
> ?void draw (const graphics_object& go);
>
> ?private:
> ?std::string filename;
>
> };
>
> to the public section of gpls_renderer,
>
> or make the call like this:
>
> ?glps_renderer gl2ps (print_filename);
> ?gl2ps.opengl_renderer::draw (gh_manager::lookup (number));
>
>
>>> Now for the next problem:
>>> the opengl_renderer::draw function is actually a dispatcher based upon
>>> the object type. The way I implemented the gl2ps renderer, I override
>>> the draw method, do the gl2ps initializations and then call
>>> opengl_renderer::draw.
>>> The problem is I would like to override some specific draw function
>>> (e.g. ?virtual void draw (const text::properties& props);), but
>>> instead of the glps_renderer version being called, the base
>>> opengl_renderer version is called. So when calling with a text object
>>> the sequence is:
>>>
>>> opengl_renderer::draw (const graphics_handle& h)
>>> glps_renderer::draw (const graphics_object& go);
>>> opengl_renderer::draw (const graphics_object& go);
>>> opengl_renderer::draw (const text::properties& props)
>>>
>>> although there is a glps_renderer::draw (const text::properties& props)
>>>
>>> Any thoughts?
>>
>
> Please post your code, or a (not working) changeset. I'd like to help,
> but I need more info.
>
Thanks Jaroslav. I'll try to post some code tonight

Shai


From individ at acc.umu.se  Mon Oct 12 02:12:50 2009
From: individ at acc.umu.se (David Grundberg)
Date: Mon, 12 Oct 2009 09:12:50 +0200
Subject: Assertion in symbol table due to Revision 8881
In-Reply-To: <19153.64366.409432.624499@hugo.lan>
References: <4A485AF0.5090600@ieee.org> <19153.64366.409432.624499@hugo.lan>
Message-ID: <4AD2D6F2.7040302@acc.umu.se>

John W. Eaton wrote:
> On 29-Jun-2009, Daniel J Sebald wrote:
>
> | The octave-core dump ends up being only 11 bytes long.
>
> The octave-core file is just an octave save file that contains the
> variables in the top-level workspace.  It is intended to help you
> avoid losing all your work if Octave crashes.  But it seems that it is
> a common misconception that this file can somehow be used for
> debugging.  Maybe simply changing the name to be something like
> octave-crash-workspace-PID would help avoid the confusion?  If there
> is agreement, I can make this change.
>
> jwe
>   

I think the current name (octave-core) is cute, in a unixy way. But 
since people associate this with debugging too much, I think it calling 
it workspace-something is a good solution. Maybe a compromise, like 
workspace-core?

Just my 0.02 SEK.

David

From michael.goffioul at gmail.com  Mon Oct 12 02:58:12 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Mon, 12 Oct 2009 08:58:12 +0100
Subject: c++ question
In-Reply-To: <69d8d540910112337y3f6af92fma2493372f56bccd5@mail.gmail.com>
References: <420fb9e60910100135o884aa0bs9a0904db297ed146@mail.gmail.com>
	<420fb9e60910101255t72e89fe7rdfdb9e479925e4c7@mail.gmail.com>
	<128f38bd0910111348i328bc2b1r108fa11593f86dd3@mail.gmail.com>
	<420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>
	<69d8d540910112337y3f6af92fma2493372f56bccd5@mail.gmail.com>
Message-ID: <128f38bd0910120058n4e107b3bsb042b910b3f309a@mail.gmail.com>

On Mon, Oct 12, 2009 at 7:37 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
> No, it would work the same if the methods were non-virtual, it plays
> no role. What you see is a bit unknown C++ feature called "name
> hiding". In short, methods from base class are not automatically
> imported into the subclass namespace if there's an overloaded version
> declared in the subclass. (Trust me, there are good reasons for this).

Thanks, I didn't know about that feature. Maybe the "draw" interface of
opengl_render class should be changed into "drawXXXX" (drawImage,
drawText...) such that any future derived class won't be bitten by this
issue.

Michael.

From shaiay at gmail.com  Mon Oct 12 03:03:05 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 12 Oct 2009 10:03:05 +0200
Subject: c++ question
In-Reply-To: <128f38bd0910120058n4e107b3bsb042b910b3f309a@mail.gmail.com>
References: <420fb9e60910100135o884aa0bs9a0904db297ed146@mail.gmail.com>
	<420fb9e60910101255t72e89fe7rdfdb9e479925e4c7@mail.gmail.com>
	<128f38bd0910111348i328bc2b1r108fa11593f86dd3@mail.gmail.com>
	<420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>
	<69d8d540910112337y3f6af92fma2493372f56bccd5@mail.gmail.com>
	<128f38bd0910120058n4e107b3bsb042b910b3f309a@mail.gmail.com>
Message-ID: <420fb9e60910120103j314b74fds7b525151f2f40192@mail.gmail.com>

On Mon, Oct 12, 2009 at 9:58 AM, Michael Goffioul
<michael.goffioul at gmail.com> wrote:
> On Mon, Oct 12, 2009 at 7:37 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>> No, it would work the same if the methods were non-virtual, it plays
>> no role. What you see is a bit unknown C++ feature called "name
>> hiding". In short, methods from base class are not automatically
>> imported into the subclass namespace if there's an overloaded version
>> declared in the subclass. (Trust me, there are good reasons for this).
>
> Thanks, I didn't know about that feature. Maybe the "draw" interface of
> opengl_render class should be changed into "drawXXXX" (drawImage,
> drawText...) such that any future derived class won't be bitten by this
> issue.

I don't see a downside since the actual "dispatch" is done manually
anyway in the opengl_renderer::draw function based on the type of the
object as gathered from it's "type" property. Unless someone has an
abjection I'll make this change

Shai

From daniel.sebald at ieee.org  Mon Oct 12 03:04:33 2009
From: daniel.sebald at ieee.org (Daniel J Sebald)
Date: Mon, 12 Oct 2009 03:04:33 -0500
Subject: Assertion in symbol table due to Revision 8881
In-Reply-To: <19153.64366.409432.624499@hugo.lan>
References: <4A485AF0.5090600@ieee.org> <19153.64366.409432.624499@hugo.lan>
Message-ID: <4AD2E311.5070606@ieee.org>

John W. Eaton wrote:
> On 29-Jun-2009, Daniel J Sebald wrote:
> 
> | The octave-core dump ends up being only 11 bytes long.
> 
> The octave-core file is just an octave save file that contains the
> variables in the top-level workspace.  It is intended to help you
> avoid losing all your work if Octave crashes.  But it seems that it is
> a common misconception that this file can somehow be used for
> debugging.

Well, that was my understanding of octave-core.  I guess that misconception came about because I think you used to request the octave-core from time to time when someone reported a bug.  (Not that you ever said there was debug info in octave-core.)

  Maybe simply changing the name to be something like
> octave-crash-workspace-PID would help avoid the confusion?  If there
> is agreement, I can make this change.

I'm fine with octave-core; prefer it actually.  The reason is that files with "core" in them are often tossed as inconsequential unless pertaining to the context at hand.  I.e., to free space, people often recursively remove core dump files or leave them out of archives.

Dan

From daniel.sebald at ieee.org  Mon Oct 12 03:08:07 2009
From: daniel.sebald at ieee.org (Daniel J Sebald)
Date: Mon, 12 Oct 2009 03:08:07 -0500
Subject: Assertion in symbol table due to Revision 8881
In-Reply-To: <69d8d540910112358yf715e8dxa05d5d54530bcd8c@mail.gmail.com>
References: <4A485AF0.5090600@ieee.org> <19153.64366.409432.624499@hugo.lan>
	<69d8d540910112358yf715e8dxa05d5d54530bcd8c@mail.gmail.com>
Message-ID: <4AD2E3E7.5090707@ieee.org>

Jaroslav Hajek wrote:
> On Sun, Oct 11, 2009 at 5:36 PM, John W. Eaton <jwe at octave.org> wrote:
> 
>>On 29-Jun-2009, Daniel J Sebald wrote:
>>
>>| The octave-core dump ends up being only 11 bytes long.
>>
>>The octave-core file is just an octave save file that contains the
>>variables in the top-level workspace.  It is intended to help you
>>avoid losing all your work if Octave crashes.  But it seems that it is
>>a common misconception that this file can somehow be used for
>>debugging.  Maybe simply changing the name to be something like
>>octave-crash-workspace-PID would help avoid the confusion?  If there
>>is agreement, I can make this change.
>>
> 
> 
> I don't think so. Octave is very clearly saying
> attempting to save variables to 'octave-core'...
> so saved variables are what you should expect in the file, and a who
> does not bother reading messages just gets what he deserves.

It doesn't say that the variables are being saved exclusively.  Variables could be one of many things saved.  (But that isn't the case here.)

Dan

From highegg at gmail.com  Mon Oct 12 03:16:55 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 12 Oct 2009 10:16:55 +0200
Subject: Assertion in symbol table due to Revision 8881
In-Reply-To: <4AD2E3E7.5090707@ieee.org>
References: <4A485AF0.5090600@ieee.org> <19153.64366.409432.624499@hugo.lan>
	<69d8d540910112358yf715e8dxa05d5d54530bcd8c@mail.gmail.com>
	<4AD2E3E7.5090707@ieee.org>
Message-ID: <69d8d540910120116y64664294q86e3aecf2c31c633@mail.gmail.com>

On Mon, Oct 12, 2009 at 10:08 AM, Daniel J Sebald
<daniel.sebald at ieee.org> wrote:
> Jaroslav Hajek wrote:
>>
>> On Sun, Oct 11, 2009 at 5:36 PM, John W. Eaton <jwe at octave.org> wrote:
>>
>>> On 29-Jun-2009, Daniel J Sebald wrote:
>>>
>>> | The octave-core dump ends up being only 11 bytes long.
>>>
>>> The octave-core file is just an octave save file that contains the
>>> variables in the top-level workspace. ?It is intended to help you
>>> avoid losing all your work if Octave crashes. ?But it seems that it is
>>> a common misconception that this file can somehow be used for
>>> debugging. ?Maybe simply changing the name to be something like
>>> octave-crash-workspace-PID would help avoid the confusion? ?If there
>>> is agreement, I can make this change.
>>>
>>
>>
>> I don't think so. Octave is very clearly saying
>> attempting to save variables to 'octave-core'...
>> so saved variables are what you should expect in the file, and a who
>> does not bother reading messages just gets what he deserves.
>
> It doesn't say that the variables are being saved exclusively. ?Variables
> could be one of many things saved. ?(But that isn't the case here.)
>
> Dan
>

Well, but it doesn't speak of anything else, so for expecting anything
else you have no reasoning. Besides, if you interpret "save" aka
Octave's save command, then of course only variables can be saved.

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


From octave at nomad.inbox5.com  Mon Oct 12 12:46:32 2009
From: octave at nomad.inbox5.com (octave at nomad.inbox5.com)
Date: Mon, 12 Oct 2009 10:46:32 -0700
Subject: Brittleness with texinfo and version numbering
Message-ID: <MTAwMDAzNi5ub21hZA.1255369601@quikprotect>

The current octave development version number is 3.3.50+.  The '+'
character is rather special in UNIX naming and in this case it is
breaking the macro @verbatiminclude which is used, for example, in oop.texi.

The actual problem is the value of abs_top_srcdir.  For Mercurial
archives this is whatever the user named the directory when cloning the
repository.  In my case I just used the name 'octave-dev' and my
Mercurial code compiles fine.  However, if one does 'make dist' the
resulting file includes the version (octave-3.3.50+.tar.gz) and this
code will extract to the directory octave-3.3.50+ and will not compile
the documentation.

Offhand I can think of two simple solutions.
1) Stop using '+' or other special characters in version numbering
2) Switch from absolute srcdir naming to relative path naming (../../
avoids any reference to octave-3.3.50+)

Which solution does the community prefer?

--Rik

From thorsten.meyier at gmx.de  Mon Oct 12 15:04:37 2009
From: thorsten.meyier at gmx.de (Thorsten Meyer)
Date: Mon, 12 Oct 2009 22:04:37 +0200
Subject: plot templates and options lists for set, plot etc.
In-Reply-To: <19120.38664.367047.840593@segfault.lan>
References: <h0e1im$k1b$1@ger.gmane.org>	<834BB2D5-476C-467E-AA4F-173C3AC3819E@mac.com>	<4A2A9C98.7040905@gmx.de>
	<18987.46745.291803.265226@segfault.lan>	<F3C0D7A0-B92A-49CA-BD4E-32E45A6EA8C3@mac.com>	<18987.55627.712999.228501@segfault.lan>
	<4A3FF9AB.7080103@gmx.de>	<19010.23227.606968.13598@segfault.lan>	<197FE62F-CA51-4052-ADC5-E09A39252CE6@mac.com>	<4A508D30.2000108@gmx.de>	<7A4FF226-DC6F-4225-BA17-E0A4D2D280DA@mac.com>	<4A50F894.6060505@gmx.de>
	<4A510BF1.1030004@gmx.de>	<4AB093E8.5050809@gmx.de>
	<19120.38664.367047.840593@segfault.lan>
Message-ID: <4AD38BD5.1010205@gmx.de>

Thanks for your feedback (and your offline reminder :-) ).

Included you will find an updated patch. See comments below.

John W. Eaton wrote:
> On 16-Sep-2009, Thorsten Meyer wrote:
> 
> | Thorsten Meyer wrote:
> | > Here is a patch implementing struct and cell array arguments for the set function.
> | > 
> | > I have impplemented the matlab behaviour (as I understand it ...). See the tests
> | >  added to the patch for the details.
> | > 
> | > Could somebody please review the patch (what I do in the sources is still a lot
> | > of trial and error):
> | >  - Have I got the types of the various variables right?
> 
> | >  - Is it ok to add doxygen style comments to the new methods? (the
> | >    doxygen docs
> 
> I don't use Doxygen, so I'm unlikely to remember to add the markup in
> the comments I write.  If we decide to do this, then I think we should
> try to do it on a more global scale.
I removed the Doxygen markup for now.

> | >  - What about the coding style?
> | >  - Are the added methods for the graphics_object ok (also where I placed the
> | > definitions)?
> 
> I try to keep the order of the declarations in the .h file the same as
> the order in the .cc file.  If you've done that, then it is probably
> OK.
I fixed the order to be consistent in .h, .cc and the documentation string.

> | +//! Set properties given in two cell arrays containing names and values.
> | +void
> | +graphics_object::set (const Array<std::string> names,
> | +                      const Cell values, octave_idx_type row)
> 
> I think this should be 
> 
>   graphics_object::set (const Array<std::string>& names,
>                         const Cell& values, octave_idx_type row)
done.

> 
> | +  if (! (names.numel () == values.columns ())) 
> 
> Why use
> 
>   ! (x == y)
> 
> instead of
> 
>   x != y
> 
> ?
I changed it.

> 
> | +void
> | +graphics_object::set (const Octave_map m)
> 
> This should be
> 
>   void
>   graphics_object::set (const Octave_map& m)
Done

> | +//! Set a property to a value or to its (factory) default value.
> | +void graphics_object::set_value_or_default (caseless_str& name,
> | +                                            octave_value& val)
> 
> I think this should be
> 
>   void
>   graphics_object::set_value_or_default (const caseless_str& name,
>                                          const octave_value& val)
> 
> unless the function needs to modify NAME and VAL.  It doesn't appear
> need to.
> 
> | +  if (val.is_string ())
> | +    {
> | +      caseless_str tval = val.string_value ();
> | +
> | +      if (tval.compare ("default"))
> | +        val = get_default (name);
> | +      else if (tval.compare ("factory"))
> | +        val = get_factory_default (name);
> | +    }
> | +
> | +  if (error_state)
> | +    return;
> | +
> | +  rep->set (name, val);
> | +}
> 
> With the non-const VAL, if VAL is a string, then it will also be
> changed in the caller.  Is that really what you want?  I think it
> would be better to define a local temporary value inside the
> function.
I changed the method arguments as you suggested and blew up the conditional a
bit to avoid copying val.

Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_set_syntax.patch
Type: text/x-patch
Size: 10397 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091012/1330a048/attachment.bin 

From shaiay at gmail.com  Mon Oct 12 15:49:21 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Mon, 12 Oct 2009 22:49:21 +0200
Subject: c++ question
In-Reply-To: <420fb9e60910120000yca5971ap9c415eec93c55d7c@mail.gmail.com>
References: <420fb9e60910100135o884aa0bs9a0904db297ed146@mail.gmail.com>
	<420fb9e60910101255t72e89fe7rdfdb9e479925e4c7@mail.gmail.com>
	<128f38bd0910111348i328bc2b1r108fa11593f86dd3@mail.gmail.com>
	<420fb9e60910111355o6604ed45i58c0f163f45c37e3@mail.gmail.com>
	<69d8d540910112337y3f6af92fma2493372f56bccd5@mail.gmail.com>
	<420fb9e60910120000yca5971ap9c415eec93c55d7c@mail.gmail.com>
Message-ID: <420fb9e60910121349oca5fe99x5ae28cfa0898c465@mail.gmail.com>

On Mon, Oct 12, 2009 at 9:00 AM, Shai Ayal <shaiay at gmail.com> wrote:
> On Mon, Oct 12, 2009 at 8:37 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>> On Sun, Oct 11, 2009 at 10:55 PM, Shai Ayal <shaiay at gmail.com> wrote:
>>> Hi all,
>>>
>>> This is a question I came across while trying to work on opengl
>>> backend. At first I thought it was too trivial to ask on the list, so
>>> I asked Michael privately, but since he agrees that it is strange, I
>>> gained some self confidence and so I'm asking on the list :)
>>> I am using gcc version 4.3.4 (Debian 4.3.4-5).
>>>
>>> Any help would be apriciated. The definitions of the opengl_renderer
>>> class are in src/gl-render.h
>>>
>>> Shai
>>>
>>> On Sat, Oct 10, 2009 at 8:55 PM, Shai Ayal <shaiay at gmail.com> wrote:
>>>> On Sat, Oct 10, 2009 at 10:35 AM, Shai Ayal <shaiay at gmail.com> wrote:
>>>>> Hi Michael,
>>>>>
>>>>> I'm trying to implement the gl2ps code in the gl-renderer, and I've
>>>>> come across a c++ problem:
>>>>> As a first step I tried to defined a subclass of opengl_render which
>>>>> should override the draw method for a handle. In the new method gl2ps
>>>>> will be initialized. This is the definition:
>>>>> #include "gl-render.h"
>>>>>
>>>>> class
>>>>> OCTINTERP_API
>>>>> glps_renderer : public opengl_renderer
>>>>> {
>>>>> ?public:
>>>>> ?glps_renderer (const std::string& _filename)
>>>>> ? ?: opengl_renderer () , filename (_filename) { }
>>>>>
>>>>> ?~glps_renderer (void) { }
>>>>>
>>>>> ?void draw (const graphics_object& go);
>>>>>
>>>>> ?private:
>>>>> ?std::string filename;
>>>>>
>>>>> };
>>>>>
>>>>> However, when I try to use this in the code:
>>>>>
>>>>> ? ? ? ?glps_renderer gl2ps (print_filename);
>>>>> ? ? ? ?gl2ps.draw (gh_manager::lookup (number));
>>>>>
>>>>> The compiler complains that there is no matching function for call to
>>>>> ?glps_renderer::draw(graphics_handle).
>>>>>
>>>>> I thought it would automatically use the base class
>>>>> opengl_render::draw(graphics_handle) which would then call
>>>>> glps_renderer::draw (const graphics_object& go);
>>>>>
>>>> OK, I think I figured it out :
>>>> opengl_renderer *rend = new glps_renderer (print_filename);
>>>> rend->draw (gh_manager::lookup (number));
>>>>
>>>> so it appears the compiler is able to do run time dynamic functions,
>>>> but not compile time. Strange.
>>>>
>>
>> No, it would work the same if the methods were non-virtual, it plays
>> no role. What you see is a bit unknown C++ feature called "name
>> hiding". In short, methods from base class are not automatically
>> imported into the subclass namespace if there's an overloaded version
>> declared in the subclass. (Trust me, there are good reasons for this).
>>
>> You can either import it explicitly:
>>
>> class
>> OCTINTERP_API
>> glps_renderer : public opengl_renderer
>> {
>> ?public:
>> ? using opengl_renderer::draw;
>> ?glps_renderer (const std::string& _filename)
>> ? : opengl_renderer () , filename (_filename) { }
>>
>> ?~glps_renderer (void) { }
>>
>> ?void draw (const graphics_object& go);
>>
>> ?private:
>> ?std::string filename;
>>
>> };
>>
>> to the public section of gpls_renderer,
>>
>> or make the call like this:
>>
>> ?glps_renderer gl2ps (print_filename);
>> ?gl2ps.opengl_renderer::draw (gh_manager::lookup (number));
>>
>>
>>>> Now for the next problem:
>>>> the opengl_renderer::draw function is actually a dispatcher based upon
>>>> the object type. The way I implemented the gl2ps renderer, I override
>>>> the draw method, do the gl2ps initializations and then call
>>>> opengl_renderer::draw.
>>>> The problem is I would like to override some specific draw function
>>>> (e.g. ?virtual void draw (const text::properties& props);), but
>>>> instead of the glps_renderer version being called, the base
>>>> opengl_renderer version is called. So when calling with a text object
>>>> the sequence is:
>>>>
>>>> opengl_renderer::draw (const graphics_handle& h)
>>>> glps_renderer::draw (const graphics_object& go);
>>>> opengl_renderer::draw (const graphics_object& go);
>>>> opengl_renderer::draw (const text::properties& props)
>>>>
>>>> although there is a glps_renderer::draw (const text::properties& props)
>>>>
>>>> Any thoughts?
>>>
>>
>> Please post your code, or a (not working) changeset. I'd like to help,
>> but I need more info.
>>
> Thanks Jaroslav. I'll try to post some code tonight

OK, it was my mistake. I found my problem -- I was just
misunderstanding the opengl_renderer code.

Thanks and sorry for the noise

Shai


From shaiay at gmail.com  Tue Oct 13 03:16:15 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 13 Oct 2009 10:16:15 +0200
Subject: opengl and images
In-Reply-To: <1255197305.4615.5.camel@sh-t400>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
	<1254730349.4403.4.camel@sh-t400>
	<128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
	<420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>
	<4ACA712F.6050507@isl.stanford.edu>
	<420fb9e60910052239l1502620fva008b208d2eb9013@mail.gmail.com>
	<1254809130.4620.2.camel@sh-t400> <1255197305.4615.5.camel@sh-t400>
Message-ID: <420fb9e60910130116td4c2abev391be1eb832872b9@mail.gmail.com>

On Sat, Oct 10, 2009 at 7:55 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> tir, 06 10 2009 kl. 08:05 +0200, skrev S?ren Hauberg:
>> tir, 06 10 2009 kl. 07:39 +0200, skrev Shai Ayal:
>> > Yet another workaround is to use mesa software rendering. In debian,
>> > this worked for me:
>> > apt-get install libgl1-mesa-swx11-dev libgl1-mesa-swx11-i686
>> > However, this will disable opengl hardware acceleration, which might
>> > be a high price to pay.
>>
>> Yeah, at least for me this is not an option. I'm working fairly close
>> with graphics / physics-simulation people at the moment, so I'm highly
>> dependent on OpenGL :-(
>>
>> I guess the proper cause of action depends on how many people are
>> actually experiencing this issue. If I'm the only one, then I guess it
>> doesn't make sense to invest too much work here.
>
> For some reason the Intel graphics driver broke for me recently. I have
> one of these fancy laptops that both have an Intel and an AMD graphics
> card, so I've changed to use the AMD card (using the FGLRX driver).
>
> Using this card / driver I still see the issue where the image is on top
> of the plot. So, this is not a driver issue.

The only easy solution I see now is the one I suggested before --
displaying the image as a surface.
At least on my debian/nvidia system this is significantly slower.
While using the OpenGL draw pixels command allows me to smoothly zoom
and pan a 4 Megapixel photograph, doing so with a similarly sized
surface is quite slow and jumpy.

Shai


From highegg at gmail.com  Tue Oct 13 05:38:33 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 13 Oct 2009 12:38:33 +0200
Subject: FYI: sum improved
Message-ID: <69d8d540910130338i1de5486dv12aa084fee2927cc@mail.gmail.com>

the built-in "sum" function was improved:
http://hg.savannah.gnu.org/hgweb/octave/rev/192d94cff6c1

"sum" now accepts an 'extra' option that makes it use a special
summation algorithm, compensating for loss of precision (slightly more
sophisticated than the well-known Kahan's). The effect is demonstrable
by the following script:

ans =  0.015097
Elapsed time is 0.000108957 seconds.
ans = 0
Elapsed time is 0.0004 seconds.
ans =  10.015
Elapsed time is 2.69e-05 seconds.
ans =  10
Elapsed time is 3.41e-05 seconds.
ans = -7.1538
Elapsed time is 0.000391 seconds.
ans =  1.1546e-14
Elapsed time is 0.0005829 seconds.
ans =  2.8462
Elapsed time is 0.0002379 seconds.
ans =  10.000
Elapsed time is 0.000573 seconds.
ans =  24.671
Elapsed time is 0.0269 seconds.
ans = -1.6911e-12
Elapsed time is 0.06166 seconds.
ans =  34.671
Elapsed time is 0.0352 seconds.
ans = 10.0000
Elapsed time is 0.06382 seconds.

as you can see, the compensated summation always gives a much more
precise result (should be 0 or 10), at the cost of speed penalty
factor up to some 2+ (this depends on memory management). This is with
SSE arithmetics on 64-bit machines; I'm wondering what 387 arithmetics
would do. The "extra" option is not yet working for sparse matrices.

the double-accumulated non-native reduction (default for integers,
specified by "double") is now performed inline, without temporary
conversion to double if possible. This brings it on par with native
reductions, as demonstrated by the following benchmark (set n to
suitable value):

n = 2500;
disp ("single");
a = single (rand (n));
tic; sum (a, 1, "native"); toc;
tic; sum (a, 1, "double"); toc;
tic; sum (a, 2, "native"); toc
tic; sum (a, 2, "double"); toc
tic; sum (a(:), "native"); toc
tic; sum (a(:), "double"); toc
disp ("single complex");
a = complex (single (rand (n)), single (rand (n)));
tic; sum (a, 1, "native"); toc;
tic; sum (a, 1, "double"); toc;
tic; sum (a, 2, "native"); toc
tic; sum (a, 2, "double"); toc
tic; sum (a(:), "native"); toc
tic; sum (a(:), "double"); toc
disp ("int32");
a = int32 (1e4 * (rand (n) - 0.5));
tic; sum (a, 1, "native"); toc;
tic; sum (a, 1, "double"); toc;
tic; sum (a, 2, "native"); toc
tic; sum (a, 2, "double"); toc
tic; sum (a(:), "native"); toc
tic; sum (a(:), "double"); toc
disp ("uint16");
a = uint16 (1e1 * rand (n));
tic; sum (a, 1, "native"); toc;
tic; sum (a, 1, "double"); toc;
tic; sum (a, 2, "native"); toc
tic; sum (a, 2, "double"); toc
tic; sum (a(:), "native"); toc
tic; sum (a(:), "double"); toc
disp ("int64");
a = int64 (1e8 * (rand (n) - 0.5));
tic; sum (a, 1, "native"); toc;
tic; sum (a, 1, "double"); toc;
tic; sum (a, 2, "native"); toc
tic; sum (a, 2, "double"); toc
tic; sum (a(:), "native"); toc
tic; sum (a(:), "double"); toc

with a recent tip, I get (Core 2 Duo @ 2.83 GHz, g++ -O3 -march=native)

single
Elapsed time is 0.00736904 seconds.
Elapsed time is 0.0398569 seconds.
Elapsed time is 0.00691319 seconds.
Elapsed time is 0.0457029 seconds.
Elapsed time is 0.00729012 seconds.
Elapsed time is 0.0429699 seconds.
single complex
Elapsed time is 0.009444 seconds.
Elapsed time is 0.122845 seconds.
Elapsed time is 0.0125308 seconds.
Elapsed time is 0.124614 seconds.
Elapsed time is 0.00960779 seconds.
Elapsed time is 0.125515 seconds.
int32
Elapsed time is 0.00868487 seconds.
Elapsed time is 0.04076 seconds.
Elapsed time is 0.00867987 seconds.
Elapsed time is 0.0458021 seconds.
Elapsed time is 0.00956798 seconds.
Elapsed time is 0.0463171 seconds.
uint16
Elapsed time is 0.00492692 seconds.
Elapsed time is 0.039608 seconds.
Elapsed time is 0.00606394 seconds.
Elapsed time is 0.0457959 seconds.
Elapsed time is 0.00865698 seconds.
Elapsed time is 0.0426869 seconds.
int64
Elapsed time is 0.010695 seconds.
Elapsed time is 0.0449679 seconds.
Elapsed time is 0.0123532 seconds.
Elapsed time is 0.0477431 seconds.
Elapsed time is 0.0102439 seconds.
Elapsed time is 0.04808 seconds.

with the new patch, I get:

single
Elapsed time is 0.00735211 seconds.
Elapsed time is 0.00744104 seconds.
Elapsed time is 0.0052731 seconds.
Elapsed time is 0.0054481 seconds.
Elapsed time is 0.0071578 seconds.
Elapsed time is 0.00739503 seconds.
single complex
Elapsed time is 0.0096209 seconds.
Elapsed time is 0.0110161 seconds.
Elapsed time is 0.0124722 seconds.
Elapsed time is 0.0198781 seconds.
Elapsed time is 0.010736 seconds.
Elapsed time is 0.0117328 seconds.
int32
Elapsed time is 0.00881386 seconds.
Elapsed time is 0.00739193 seconds.
Elapsed time is 0.00970101 seconds.
Elapsed time is 0.0179269 seconds.
Elapsed time is 0.00954795 seconds.
Elapsed time is 0.00770593 seconds.
uint16
Elapsed time is 0.00493503 seconds.
Elapsed time is 0.00696611 seconds.
Elapsed time is 0.00503612 seconds.
Elapsed time is 0.013629 seconds.
Elapsed time is 0.00915194 seconds.
Elapsed time is 0.00722909 seconds.
int64
Elapsed time is 0.010839 seconds.
Elapsed time is 0.00875592 seconds.
Elapsed time is 0.0108941 seconds.
Elapsed time is 0.015064 seconds.
Elapsed time is 0.0130761 seconds.
Elapsed time is 0.010613 seconds.

as you can see, some operations' speed improved by a factor of 5 or more.

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

From jwe at octave.org  Tue Oct 13 04:56:53 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 13 Oct 2009 05:56:53 -0400
Subject: Patch to stop counting missing tests on internal functions
In-Reply-To: <MTAwMDAyMS5ub21hZA.1255107996@quikprotect>
References: <MTAwMDAyMS5ub21hZA.1255107996@quikprotect>
Message-ID: <19156.20197.242290.724607@hugo.lan>

On  9-Oct-2009, Rik wrote:

| Currently when a user runs 'make check' there is a report which shows a
| large number of files that don't have tests written for them and then
| invites the user to contribute tests.  On looking through the list,
| however, there are about 60 functions which are for internal use only as
| designated by the prefix and suffix "__".   An example is __contourc__.cc
| 
| My proposed patch to fntests.m would remove these from the report of
| functions missing tests. (This is *only* about reporting.  If tests for
| internal functions have been written they would still continue to be
| run.)  First, if these internal functions need coverage they should get
| it from tests written by the function which calls them.  In the example
| given, there is already a test in contourc.m which presumably would
| catch an error in the internal function.  Secondly, if a user does have
| a few spare moments to write a test for a function we will get more
| value for the coding effort if they concentrate on functions that people
| might use all the time rather than internal ones.
| 
| Thoughts?  If there are no strong objections I'll apply the patch in a
| few days.

I'm not sure that we should stop testing all functions named this way.
The naming scheme was adopted because Octave did not have private
functions or subfunctions, so the functions with names of the form
__X__ which really should be private functions or subfunctions should
be converted.  Then they won't be tested because you can't call
private functions or subfunctions directly, and we could ensure that
the test script does not search private subdirectories.  Then we would
be left with functions that are "internal" in the sense that they do
something special that is not normally useful for programming, but are
occasionally used for debugging or some other purpose.  I'm thinking
of functions like __dump_symtab_info__.

jwe

From highegg at gmail.com  Tue Oct 13 06:12:45 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 13 Oct 2009 13:12:45 +0200
Subject: Patch to stop counting missing tests on internal functions
In-Reply-To: <19156.20197.242290.724607@hugo.lan>
References: <MTAwMDAyMS5ub21hZA.1255107996@quikprotect>
	<19156.20197.242290.724607@hugo.lan>
Message-ID: <69d8d540910130412r1c46d578rdf758fcb075ac3f1@mail.gmail.com>

On Tue, Oct 13, 2009 at 11:56 AM, John W. Eaton <jwe at octave.org> wrote:
> On ?9-Oct-2009, Rik wrote:
>
> | Currently when a user runs 'make check' there is a report which shows a
> | large number of files that don't have tests written for them and then
> | invites the user to contribute tests. ?On looking through the list,
> | however, there are about 60 functions which are for internal use only as
> | designated by the prefix and suffix "__". ? An example is __contourc__.cc
> |
> | My proposed patch to fntests.m would remove these from the report of
> | functions missing tests. (This is *only* about reporting. ?If tests for
> | internal functions have been written they would still continue to be
> | run.) ?First, if these internal functions need coverage they should get
> | it from tests written by the function which calls them. ?In the example
> | given, there is already a test in contourc.m which presumably would
> | catch an error in the internal function. ?Secondly, if a user does have
> | a few spare moments to write a test for a function we will get more
> | value for the coding effort if they concentrate on functions that people
> | might use all the time rather than internal ones.
> |
> | Thoughts? ?If there are no strong objections I'll apply the patch in a
> | few days.
>
> I'm not sure that we should stop testing all functions named this way.
> The naming scheme was adopted because Octave did not have private
> functions or subfunctions, so the functions with names of the form
> __X__ which really should be private functions or subfunctions should
> be converted. ?Then they won't be tested because you can't call
> private functions or subfunctions directly, and we could ensure that
> the test script does not search private subdirectories. ?Then we would
> be left with functions that are "internal" in the sense that they do
> something special that is not normally useful for programming, but are
> occasionally used for debugging or some other purpose. ?I'm thinking
> of functions like __dump_symtab_info__.
>
> jwe
>

I would also like to see more private functions become really private;
one problem I see is that a number of __helper__ functions are
compiled codes, which are all bundled in one directory in the current
Octave's binary files organization.
Regarding the test log, it is surely not realistic to expect every
source file to have tests; the list in fntests.log includes assistant
sources, such as oct-locbuf.cc, for which no test is really
meaningful, or even auto-generated sources, such as mx-cm-dm.cc.
Maybe C++ files that are expected to have tests some day can be marked
as such, and only those files listed.

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


From soren at hauberg.org  Tue Oct 13 06:13:14 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Tue, 13 Oct 2009 13:13:14 +0200
Subject: FYI: sum improved
In-Reply-To: <69d8d540910130338i1de5486dv12aa084fee2927cc@mail.gmail.com>
References: <69d8d540910130338i1de5486dv12aa084fee2927cc@mail.gmail.com>
Message-ID: <1255432394.5215.4.camel@sh-t400>

tir, 13 10 2009 kl. 12:38 +0200, skrev Jaroslav Hajek:
> the built-in "sum" function was improved:
> http://hg.savannah.gnu.org/hgweb/octave/rev/192d94cff6c1

Nice :-) It's always great to see improvements to the basic stuff.

> "sum" now accepts an 'extra' option that makes it use a special
> summation algorithm, compensating for loss of precision (slightly more
> sophisticated than the well-known Kahan's).

The name of the 'extra' option seems somewhat odd to me. Perhaps it
should be called 'extra-precise', 'improve-accuracy', or something like
that?

S?ren


From soren at hauberg.org  Tue Oct 13 06:21:58 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Tue, 13 Oct 2009 13:21:58 +0200
Subject: opengl and images
In-Reply-To: <420fb9e60910130116td4c2abev391be1eb832872b9@mail.gmail.com>
References: <420fb9e60909262312q25505bcclc16da8b56deb753d@mail.gmail.com>
	<4AC98F00.9070507@isl.stanford.edu>
	<420fb9e60910050055kb841660ia8a7c22f0fdfebb9@mail.gmail.com>
	<1254730349.4403.4.camel@sh-t400>
	<128f38bd0910050119t400ca7dep12f620a32eba232a@mail.gmail.com>
	<420fb9e60910050121y1979b660r6b55c76ed2d110cc@mail.gmail.com>
	<4ACA712F.6050507@isl.stanford.edu>
	<420fb9e60910052239l1502620fva008b208d2eb9013@mail.gmail.com>
	<1254809130.4620.2.camel@sh-t400> <1255197305.4615.5.camel@sh-t400>
	<420fb9e60910130116td4c2abev391be1eb832872b9@mail.gmail.com>
Message-ID: <1255432918.5215.7.camel@sh-t400>

tir, 13 10 2009 kl. 10:16 +0200, skrev Shai Ayal:
> > For some reason the Intel graphics driver broke for me recently. I have
> > one of these fancy laptops that both have an Intel and an AMD graphics
> > card, so I've changed to use the AMD card (using the FGLRX driver).
> >
> > Using this card / driver I still see the issue where the image is on top
> > of the plot. So, this is not a driver issue.
> 
> The only easy solution I see now is the one I suggested before --
> displaying the image as a surface.
> At least on my debian/nvidia system this is significantly slower.
> While using the OpenGL draw pixels command allows me to smoothly zoom
> and pan a 4 Megapixel photograph, doing so with a similarly sized
> surface is quite slow and jumpy.

I agree with this logic. To me, the problem is simply that the current
approach doesn't allow me to plot on top of images on both my Intel card
and my AMD card. This might be my version of Ubuntu (which is known to
have graphics problems), but I can't tell until a more recent version is
released.

S?ren


From jwe at octave.org  Tue Oct 13 05:42:04 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 13 Oct 2009 06:42:04 -0400
Subject: Brittleness with texinfo and version numbering
In-Reply-To: <MTAwMDAzNi5ub21hZA.1255369601@quikprotect>
References: <MTAwMDAzNi5ub21hZA.1255369601@quikprotect>
Message-ID: <19156.22908.790892.25147@hugo.lan>

On 12-Oct-2009, octave at nomad.inbox5.com wrote:

| The current octave development version number is 3.3.50+.  The '+'
| character is rather special in UNIX naming and in this case it is
| breaking the macro @verbatiminclude which is used, for example, in oop.texi.
| 
| The actual problem is the value of abs_top_srcdir.  For Mercurial
| archives this is whatever the user named the directory when cloning the
| repository.  In my case I just used the name 'octave-dev' and my
| Mercurial code compiles fine.  However, if one does 'make dist' the
| resulting file includes the version (octave-3.3.50+.tar.gz) and this
| code will extract to the directory octave-3.3.50+ and will not compile
| the documentation.
| 
| Offhand I can think of two simple solutions.
| 1) Stop using '+' or other special characters in version numbering
| 2) Switch from absolute srcdir naming to relative path naming (../../
| avoids any reference to octave-3.3.50+)
| 
| Which solution does the community prefer?

I think this is a but in Texinfo.  If I create a directory called foo+
and process the file

  \input texinfo
  @setfilename foo.info
  @set srcdir foo+
  @verbatiminclude @value{srcdir}/foo
  @bye

with tex, I see the following error:

  $ tex foo.texi
  This is TeX, Version 3.141592 (Web2C 7.5.6)
  (./foo.texi (/usr/share/texmf/tex/texinfo/texinfo.tex
  Loading texinfo [version 2008-04-18.10]: pdf, fonts, page headings, tables,
  conditionals, indexing, sectioning, toc, environments, defuns, macros,
  cross references, insertions,
  (/usr/share/texmf-texlive/tex/generic/epsf/epsf.tex
  This is `epsf.tex' v2.7.3 <23 July 2005>
  ) localization, formatting, and turning on texinfo input format.) (./foo.aux)
  ! I can't find file `foo{'.
  <to be read again> 
		     @fam 
  @tt ->@fam 
	     =@ttfam @setfontstyle {tt}
  +->{@tt 
	  @char 43}
  @value ... not set.}@else @csname SET#1 at endcsname 
						    @fi 
  <argument> @value {srcdir}
			    /foo
  @doverbatiminclude ...ble @setupverbatim @input #1
						     @afterenvbreak }
  l.7 @verbatiminclude @value{srcdir}/foo

  Please type another input file name: 

If I comment out the "@setfilename foo.info" line it works.  Also,
makeinfo can process this either way.

Would you please report the problem to the Texinfo maintainers?

Thanks,

jwe

From jwe at octave.org  Tue Oct 13 05:45:24 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 13 Oct 2009 06:45:24 -0400
Subject: Patch to stop counting missing tests on internal functions
In-Reply-To: <69d8d540910130412r1c46d578rdf758fcb075ac3f1@mail.gmail.com>
References: <MTAwMDAyMS5ub21hZA.1255107996@quikprotect>
	<19156.20197.242290.724607@hugo.lan>
	<69d8d540910130412r1c46d578rdf758fcb075ac3f1@mail.gmail.com>
Message-ID: <19156.23108.112355.878361@hugo.lan>

On 13-Oct-2009, Jaroslav Hajek wrote:

| I would also like to see more private functions become really private;

I would also like to see this happen, but it will mean some changes in
the build system, and as I'm currently working on converting the
Octave build system to use automake (I should have something to show
soon) I'd like to delay any such change until after the automake
changes are done.

| one problem I see is that a number of __helper__ functions are
| compiled codes, which are all bundled in one directory in the current
| Octave's binary files organization.
| Regarding the test log, it is surely not realistic to expect every
| source file to have tests; the list in fntests.log includes assistant
| sources, such as oct-locbuf.cc, for which no test is really
| meaningful, or even auto-generated sources, such as mx-cm-dm.cc.
| Maybe C++ files that are expected to have tests some day can be marked
| as such, and only those files listed.

How about only noting the C++ source files that have DEFUNs?

jwe

From jordigh at gmail.com  Tue Oct 13 08:57:58 2009
From: jordigh at gmail.com (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermoso?=)
Date: Tue, 13 Oct 2009 08:57:58 -0500
Subject: Debian packaging
Message-ID: <9543b3a40910130657o2cc03b46r8cf77d2d7f36efc0@mail.gmail.com>

2009/10/11 John W. Eaton <jwe at octave.org>:
> | and must instead rely on specific packagers like Rafael Laboissiere,
> | Thomas Weber, and infrequently myself.
>
> After years doing great work building Octave packages for Debian,
> Rafael is no longer active. ?So it would be really great if some other
> users stepped in and helped.

Oh dear. I hadn't noticed. Did he officially announce he was stepping
down or did he quietly vanish?

I'm not sure I can pick up the work, but I can try a little.


From shaiay at users.sourceforge.net  Tue Oct 13 12:43:41 2009
From: shaiay at users.sourceforge.net (Shai Ayal)
Date: Tue, 13 Oct 2009 19:43:41 +0200
Subject: hardcopy support for gl-render and the fltk_backend
Message-ID: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>

Hi

I attach a changeset which adds postscript output to the fltk backend,
based on the gl-renderer and the gl2ps library
(http://www.geuz.org/gl2ps).
This changeset is relatively big because the gl2ps library is
distributed as 2 files - gl2ps.c and gl2ps.h which need to be included
in the distribution of the project using it. There is no binary
library.
to use :
backend("fltk"); plot(randn(1e3,1)); print("test.eps")

Limitations (which I will try to fix in the future):
1. no support for images
2. only supports the postscript core fonts Helvetica, Times-Roman,
Courier, Symbol, ZapfDingbats (defaults to Helvetica)
3. no support for bold/italic fonts
4. outputs only eps

Shai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gl2ps.gz
Type: application/x-gzip
Size: 47807 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091013/6594a9b5/attachment-0001.bin 

From godfrey at isl.stanford.edu  Tue Oct 13 13:18:17 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Tue, 13 Oct 2009 11:18:17 -0700
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
Message-ID: <4AD4C469.1080604@isl.stanford.edu>

On 10/13/2009 10:43 AM, Shai Ayal wrote:
> Limitations (which I will try to fix in the future):
>    
This is a GREAT step forward!  Thanks very much
Shai.

One thing to add to the limitations:

5. No TeX interpretation.

This will be important for many users.
> 4. outputs only eps
>    
This is not too serious since simple ghostscript
scripts can do most translations.  Matlab uses
ghostscript for this purpose.

Michael




From shaiay at users.sourceforge.net  Tue Oct 13 14:17:38 2009
From: shaiay at users.sourceforge.net (Shai Ayal)
Date: Tue, 13 Oct 2009 21:17:38 +0200
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <4AD4C469.1080604@isl.stanford.edu>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
	<4AD4C469.1080604@isl.stanford.edu>
Message-ID: <420fb9e60910131217q17a46081k1f9ebb424b76c775@mail.gmail.com>

On Tue, Oct 13, 2009 at 8:18 PM, Michael D. Godfrey
<godfrey at isl.stanford.edu> wrote:
>>
>> 4. outputs only eps
>>
>
> This is not too serious since simple ghostscript
> scripts can do most translations. ?Matlab uses
> ghostscript for this purpose.

I think that even the current print.m does this (use gs to convert
from eps) for gnuplot. It just has to be adapted for use with all
backends

Shai


From godfrey at isl.stanford.edu  Tue Oct 13 14:19:43 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Tue, 13 Oct 2009 12:19:43 -0700
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <420fb9e60910131217q17a46081k1f9ebb424b76c775@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>	
	<4AD4C469.1080604@isl.stanford.edu>
	<420fb9e60910131217q17a46081k1f9ebb424b76c775@mail.gmail.com>
Message-ID: <4AD4D2CF.5010403@isl.stanford.edu>

On 10/13/2009 12:17 PM, Shai Ayal wrote:
> I think that even the current print.m does this (use gs to convert
> from eps) for gnuplot. It just has to be adapted for use with all
> backends
>    
Right.  And, it can be used for other output formats.

Michael


From octave at nomad.inbox5.com  Tue Oct 13 23:13:35 2009
From: octave at nomad.inbox5.com (Rik)
Date: Tue, 13 Oct 2009 21:13:35 -0700
Subject: Brittleness with texinfo and version numbering
In-Reply-To: <19156.22908.790892.25147@hugo.lan>
References: <MTAwMDAzNi5ub21hZA.1255369601@quikprotect>
	<19156.22908.790892.25147@hugo.lan>
Message-ID: <MTAwMDA0My5ub21hZA.1255493624@quikprotect>

John W. Eaton wrote:
> On 12-Oct-2009, octave at nomad.inbox5.com wrote:
>
> | The current octave development version number is 3.3.50+.  The '+'
> | character is rather special in UNIX naming and in this case it is
> | breaking the macro @verbatiminclude which is used, for example, in oop.texi.
> | 
> | The actual problem is the value of abs_top_srcdir.  For Mercurial
> | archives this is whatever the user named the directory when cloning the
> | repository.  In my case I just used the name 'octave-dev' and my
> | Mercurial code compiles fine.  However, if one does 'make dist' the
> | resulting file includes the version (octave-3.3.50+.tar.gz) and this
> | code will extract to the directory octave-3.3.50+ and will not compile
> | the documentation.
> | 
> | Offhand I can think of two simple solutions.
> | 1) Stop using '+' or other special characters in version numbering
> | 2) Switch from absolute srcdir naming to relative path naming (../../
> | avoids any reference to octave-3.3.50+)
> | 
> | Which solution does the community prefer?
>
> I think this is a but in Texinfo.  If I create a directory called foo+
> and process the file
>
>   \input texinfo
>   @setfilename foo.info
>   @set srcdir foo+
>   @verbatiminclude @value{srcdir}/foo
>   @bye
>
> with tex, I see the following error:
>
>   $ tex foo.texi
>   This is TeX, Version 3.141592 (Web2C 7.5.6)
>   (./foo.texi (/usr/share/texmf/tex/texinfo/texinfo.tex
>   Loading texinfo [version 2008-04-18.10]: pdf, fonts, page headings, tables,
>   conditionals, indexing, sectioning, toc, environments, defuns, macros,
>   cross references, insertions,
>   (/usr/share/texmf-texlive/tex/generic/epsf/epsf.tex
>   This is `epsf.tex' v2.7.3 <23 July 2005>
>   ) localization, formatting, and turning on texinfo input format.) (./foo.aux)
>   ! I can't find file `foo{'.
>   <to be read again> 
> 		     @fam 
>   @tt ->@fam 
> 	     =@ttfam @setfontstyle {tt}
>   +->{@tt 
> 	  @char 43}
>   @value ... not set.}@else @csname SET#1 at endcsname 
> 						    @fi 
>   <argument> @value {srcdir}
> 			    /foo
>   @doverbatiminclude ...ble @setupverbatim @input #1
> 						     @afterenvbreak }
>   l.7 @verbatiminclude @value{srcdir}/foo
>
>   Please type another input file name: 
>
> If I comment out the "@setfilename foo.info" line it works.  Also,
> makeinfo can process this either way.
>
> Would you please report the problem to the Texinfo maintainers?
>   
I agree it's a problem with texinfo, but I think it will take a longer
to fix it this way than simply avoiding the problem.  If there's a hole
in the sidewalk I can call the city and it might be repaired 6 months
from now.  Or I could just walk down a different street.
 
There were already problems with this exact macro in 2008 when it
wouldn't accept the '@' character and David Bateman had to query and
track down a bug fix.  Not to be mean to the texinfo developers, but I
just don't have time to pursue that process.

--Rik

From highegg at gmail.com  Wed Oct 14 00:52:52 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 14 Oct 2009 07:52:52 +0200
Subject: FYI: sum improved
In-Reply-To: <1255432394.5215.4.camel@sh-t400>
References: <69d8d540910130338i1de5486dv12aa084fee2927cc@mail.gmail.com>
	<1255432394.5215.4.camel@sh-t400>
Message-ID: <69d8d540910132252x2e66f798qda8e515f1357c9f9@mail.gmail.com>

On Tue, Oct 13, 2009 at 1:13 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> tir, 13 10 2009 kl. 12:38 +0200, skrev Jaroslav Hajek:
>> the built-in "sum" function was improved:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/192d94cff6c1
>
> Nice :-) It's always great to see improvements to the basic stuff.
>
>> "sum" now accepts an 'extra' option that makes it use a special
>> summation algorithm, compensating for loss of precision (slightly more
>> sophisticated than the well-known Kahan's).
>
> The name of the 'extra' option seems somewhat odd to me. Perhaps it
> should be called 'extra-precise', 'improve-accuracy', or something like
> that?
>

Well, since the option argument is currently only used to indicate
summation precision ("native" or "double"), I thought "extra" was
pretty good. I'm not against changing, but I would prefer a single
word if possible ("compensated"?). Multiword options should probably
use CamelCasing, like they do in many other functions.

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


From shaiay at users.sourceforge.net  Wed Oct 14 01:43:20 2009
From: shaiay at users.sourceforge.net (Shai Ayal)
Date: Wed, 14 Oct 2009 08:43:20 +0200
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
Message-ID: <420fb9e60910132343h5ad71e4dt6c82127b5c75b26@mail.gmail.com>

On Tue, Oct 13, 2009 at 7:43 PM, Shai Ayal <shaiay at users.sourceforge.net> wrote:
> Hi
>
> I attach a changeset which adds postscript output to the fltk backend,
> based on the gl-renderer and the gl2ps library
> (http://www.geuz.org/gl2ps).
> This changeset is relatively big because the gl2ps library is
> distributed as 2 files - gl2ps.c and gl2ps.h which need to be included
> in the distribution of the project using it. There is no binary
> library.

I just got word (on the gl2ps mailing list) that gl2ps has been
accepted to debian (although I still can't install it with apt-get),
and I see it is already in the fedora repositories, so maybe the gl2ps
repositories can be dropped soon?

sHAI

From jwe at octave.org  Wed Oct 14 04:55:07 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 14 Oct 2009 05:55:07 -0400
Subject: FYI: sum improved
In-Reply-To: <69d8d540910132252x2e66f798qda8e515f1357c9f9@mail.gmail.com>
References: <69d8d540910130338i1de5486dv12aa084fee2927cc@mail.gmail.com>
	<1255432394.5215.4.camel@sh-t400>
	<69d8d540910132252x2e66f798qda8e515f1357c9f9@mail.gmail.com>
Message-ID: <19157.40955.186266.897438@hugo.lan>

On 14-Oct-2009, Jaroslav Hajek wrote:

| Multiword options should probably
| use CamelCasing, like they do in many other functions.

Please don't force StudlyCaps on Octave users.  That is only done for
compatibility with Matlab, and in all cases that I know of, Matlab
also accepts notcamelcasing (and probably SCREAMINGNOTCAMELCASING as
well).  I'd also be happy to accept camel-casing as an option
(simply drop the hyphens, then do the comparison), but it would be
more work, and might cause some confusion among users, so I'm not sure
we should do it.

jwe

From octave at nomad.inbox5.com  Wed Oct 14 13:05:34 2009
From: octave at nomad.inbox5.com (Rik)
Date: Wed, 14 Oct 2009 11:05:34 -0700
Subject: Patch to stop counting missing tests on internal functions
In-Reply-To: <19156.23108.112355.878361@hugo.lan>
References: <MTAwMDAyMS5ub21hZA.1255107996@quikprotect>	<19156.20197.242290.724607@hugo.lan>	<69d8d540910130412r1c46d578rdf758fcb075ac3f1@mail.gmail.com>
	<19156.23108.112355.878361@hugo.lan>
Message-ID: <MTAwMDAxNi5ub21hZA.1255543543@quikprotect>

John W. Eaton wrote:
> On 13-Oct-2009, Jaroslav Hajek wrote:
>
> | I would also like to see more private functions become really private;
>
> I would also like to see this happen, but it will mean some changes in
> the build system, and as I'm currently working on converting the
> Octave build system to use automake (I should have something to show
> soon) I'd like to delay any such change until after the automake
> changes are done.
>
> | one problem I see is that a number of __helper__ functions are
> | compiled codes, which are all bundled in one directory in the current
> | Octave's binary files organization.
> | Regarding the test log, it is surely not realistic to expect every
> | source file to have tests; the list in fntests.log includes assistant
> | sources, such as oct-locbuf.cc, for which no test is really
> | meaningful, or even auto-generated sources, such as mx-cm-dm.cc.
> | Maybe C++ files that are expected to have tests some day can be marked
> | as such, and only those files listed.
>
> How about only noting the C++ source files that have DEFUNs?
>   
Maybe we are going about this the wrong way.  The current script
searches for all *.cc and *.m files and then checks whether there there
are any test features (%!test, %!assert, %!error, %!warning) in the
file.  This check is too simplistic and the results are both overly
pessimistic and overly optimistic.  First, they are overly pessimistic
because they seem to show that a lot of files are undocumented, but most
of these files do not contain user functions and instead are helping
code or auto-generated code.  Secondly, they are overly optimistic about
coverage because even a single test for a single function will count the
entire file as being covered.  The file utils.cc has 12 functions in it
and it would be useful to know which ones actually had coverage.

What if we start with the list of functions visible to Octave (using
calls to __builtins__ and __list_functions__) and then cycle through
that list trying to call any test functions?  If there are no tests then
the test function returns something to indicate that and we can mark the
function as needing work.

--Rik
> jwe
>
>   


From thomas.weber.mail at gmail.com  Wed Oct 14 15:11:44 2009
From: thomas.weber.mail at gmail.com (Thomas Weber)
Date: Wed, 14 Oct 2009 22:11:44 +0200
Subject: Debian packaging
In-Reply-To: <9543b3a40910130657o2cc03b46r8cf77d2d7f36efc0@mail.gmail.com>
References: <9543b3a40910130657o2cc03b46r8cf77d2d7f36efc0@mail.gmail.com>
Message-ID: <20091014201144.GA6459@atlan>

On Tue, Oct 13, 2009 at 08:57:58AM -0500, Jordi Guti?rrez Hermoso wrote:
> 2009/10/11 John W. Eaton <jwe at octave.org>:
> > | and must instead rely on specific packagers like Rafael Laboissiere,
> > | Thomas Weber, and infrequently myself.
> >
> > After years doing great work building Octave packages for Debian,
> > Rafael is no longer active. ?So it would be really great if some other
> > users stepped in and helped.
> 
> Oh dear. I hadn't noticed. Did he officially announce he was stepping
> down or did he quietly vanish?

http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2009-June/006403.html

	Thomas

From simonbour at gmail.com  Wed Oct 14 22:12:20 2009
From: simonbour at gmail.com (Simon Bourguigne)
Date: Thu, 15 Oct 2009 00:12:20 -0300
Subject: image and video processing capabilities
Message-ID: <332fe7910910142012y30159009u718729c7eda175ab@mail.gmail.com>

Hello everybody! There is a public domain software called ImageJ used widely
in biology. It comes with source code and documentation; and a lot, if not
all, of the functions and capabilities for image and video processing can be
used for octave. I try to do it myself, but i'm still learning and there's
still a lot more to learn. Among the non-processing tools there's image and
video importing code for a large list of different formats. It's entirely
written in Java. Here are a couple of links:

Description : http://en.wikipedia.org/wiki/ImageJ

Source Code: http://rsbweb.nih.gov/ij/docs/source/index.html

Official Website: http://rsbweb.nih.gov/ij/

thanx in advance for any answer,

simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091015/3fa1b520/attachment.html 

From soren at hauberg.org  Thu Oct 15 01:37:40 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Thu, 15 Oct 2009 08:37:40 +0200
Subject: FYI: sum improved
In-Reply-To: <69d8d540910132252x2e66f798qda8e515f1357c9f9@mail.gmail.com>
References: <69d8d540910130338i1de5486dv12aa084fee2927cc@mail.gmail.com>
	<1255432394.5215.4.camel@sh-t400>
	<69d8d540910132252x2e66f798qda8e515f1357c9f9@mail.gmail.com>
Message-ID: <1255588660.4557.5.camel@sh-t400>

ons, 14 10 2009 kl. 07:52 +0200, skrev Jaroslav Hajek:
> On Tue, Oct 13, 2009 at 1:13 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> > tir, 13 10 2009 kl. 12:38 +0200, skrev Jaroslav Hajek:
> >> the built-in "sum" function was improved:
> >> http://hg.savannah.gnu.org/hgweb/octave/rev/192d94cff6c1
> >
> > Nice :-) It's always great to see improvements to the basic stuff.
> >
> >> "sum" now accepts an 'extra' option that makes it use a special
> >> summation algorithm, compensating for loss of precision (slightly more
> >> sophisticated than the well-known Kahan's).
> >
> > The name of the 'extra' option seems somewhat odd to me. Perhaps it
> > should be called 'extra-precise', 'improve-accuracy', or something like
> > that?
> >
> 
> Well, since the option argument is currently only used to indicate
> summation precision ("native" or "double"), I thought "extra" was
> pretty good. I'm not against changing, but I would prefer a single
> word if possible ("compensated"?). Multiword options should probably
> use CamelCasing, like they do in many other functions.

Okay, I see the reason behind calling it 'extra'. My objection is simply
that I interpreted it is 'extra-double' or 'extra-native', which didn't
make that much sense to me. Since the word 'accurate' is used both in
the help text and in the title of the paper you followed, perhaps
'accurate' would be a good name of the option. 'compensated' also sounds
fine to me.

S?ren


From godfrey at isl.stanford.edu  Thu Oct 15 01:43:02 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 14 Oct 2009 23:43:02 -0700
Subject: FYI: sum improved
In-Reply-To: <1255588660.4557.5.camel@sh-t400>
References: <69d8d540910130338i1de5486dv12aa084fee2927cc@mail.gmail.com>	<1255432394.5215.4.camel@sh-t400>	<69d8d540910132252x2e66f798qda8e515f1357c9f9@mail.gmail.com>
	<1255588660.4557.5.camel@sh-t400>
Message-ID: <4AD6C476.9020501@isl.stanford.edu>

On 10/14/2009 11:37 PM, S?ren Hauberg wrote:
> "sum" now accepts an 'extra' option that makes it use a special
>>  >>  summation algorithm, compensating for loss of precision (slightly more
>>  >>  sophisticated than the well-known Kahan's).

Since Jaroslav did the work, I think he should decide
on the name for the extra precision.

So, lets get it done.

Michael

From highegg at gmail.com  Thu Oct 15 01:55:03 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 15 Oct 2009 08:55:03 +0200
Subject: FYI: sum improved
In-Reply-To: <1255588660.4557.5.camel@sh-t400>
References: <69d8d540910130338i1de5486dv12aa084fee2927cc@mail.gmail.com>
	<1255432394.5215.4.camel@sh-t400>
	<69d8d540910132252x2e66f798qda8e515f1357c9f9@mail.gmail.com>
	<1255588660.4557.5.camel@sh-t400>
Message-ID: <69d8d540910142355m1bd4431v3bd3a7ae8ce2c1b6@mail.gmail.com>

On Thu, Oct 15, 2009 at 8:37 AM, S?ren Hauberg <soren at hauberg.org> wrote:
> ons, 14 10 2009 kl. 07:52 +0200, skrev Jaroslav Hajek:
>> On Tue, Oct 13, 2009 at 1:13 PM, S?ren Hauberg <soren at hauberg.org> wrote:
>> > tir, 13 10 2009 kl. 12:38 +0200, skrev Jaroslav Hajek:
>> >> the built-in "sum" function was improved:
>> >> http://hg.savannah.gnu.org/hgweb/octave/rev/192d94cff6c1
>> >
>> > Nice :-) It's always great to see improvements to the basic stuff.
>> >
>> >> "sum" now accepts an 'extra' option that makes it use a special
>> >> summation algorithm, compensating for loss of precision (slightly more
>> >> sophisticated than the well-known Kahan's).
>> >
>> > The name of the 'extra' option seems somewhat odd to me. Perhaps it
>> > should be called 'extra-precise', 'improve-accuracy', or something like
>> > that?
>> >
>>
>> Well, since the option argument is currently only used to indicate
>> summation precision ("native" or "double"), I thought "extra" was
>> pretty good. I'm not against changing, but I would prefer a single
>> word if possible ("compensated"?). Multiword options should probably
>> use CamelCasing, like they do in many other functions.
>
> Okay, I see the reason behind calling it 'extra'. My objection is simply
> that I interpreted it is 'extra-double' or 'extra-native', which didn't
> make that much sense to me.

No, "extra" can't be specified together with "double" or "native",
it's just a third option for the working precision. Maybe it could be
clarified in the docstring. My idea was that you simply specify that
you want the sum to be extra precise. For single precision, this means
it's computed in double (same as 'double'), for double precision, the
compensated algorithm is used.

> Since the word 'accurate' is used both in
> the help text and in the title of the paper you followed, perhaps
> 'accurate' would be a good name of the option. 'compensated' also sounds
> fine to me.
>

To me, "accurate" doesn't seem any better than "extra". "compensated"
is pretty unambiguous, but slightly misleading, because using "extra"
on single prec numbers doesn't use the compensated summation in single
precision (that would make little sense, because summing in double is
better). I'm still unconvinced to abandon "extra", but I can easily
make alternative spellings like "extraPrecision" or "accurate".
I'll try to clarify the docstring a bit, though.

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  Thu Oct 15 02:15:21 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 15 Oct 2009 09:15:21 +0200
Subject: FYI: nth_element
Message-ID: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>

hi all,

Octave has just got a new function: nth_element:
http://hg.savannah.gnu.org/hgweb/octave/rev/aea3a3a950e1

the docstring:

 -- Built-in Function:  nth_element (X, N)
 -- Built-in Function:  nth_element (X, N, DIM)
     Select the n-th smallest element of a vector, using the ordering
     defined by `sort'.  In other words, the result is equivalent to
     `sort(X)(N)'.  N can also be a contiguous range, either ascending
     `l:u' or descending `u:-1:l', in which case a range of elements is
     returned.  If X is an array, `nth_element' operates along the
     dimension defined by DIM, or the first non-singleton dimension if
     DIM is not given.

     nth_element encapsulates the C++ STL algorithms nth_element and
     partial_sort.  On average, the complexity of the operation is
     O(M*log(K)), where `M = size(X, DIM)' and `K = length (N)'.  This
     function is intended for cases where the ratio K/M is small;
     otherwise, it may be better to use `sort'.

     See also: sort, min, max

In short, it allows extracting a small portion of sort(X) without
actually doing the full sort.
This is sometimes useful for statistics when computing quantiles and
the like... statisticians can surely tell better.

Maybe it can be used to boost some existing functions. As an example,
it can be readily used to speed up the "median" function:
http://hg.savannah.gnu.org/hgweb/octave/rev/b7b89061bd0e

the following benchmark demonstrates the speed-up:

for n = [2000, 2001]
  a = rand (n);
  disp (n);
  tic; median (a(:)); toc
  tic; median (a, 1); toc
  tic; median (a, 2); toc
endfor

using a recent tip, Core 2 Duo @ 2.83 GHz, g++ -O3 -march=native, I get:

 2000
Elapsed time is 0.62825 seconds.
Elapsed time is 0.34634 seconds.
Elapsed time is 0.40085 seconds.
 2001
Elapsed time is 0.62713 seconds.
Elapsed time is 0.34236 seconds.
Elapsed time is 0.39419 seconds.

with the new patch, I get

 2000
Elapsed time is 0.061557 seconds.
Elapsed time is 0.049 seconds.
Elapsed time is 0.074331 seconds.
 2001
Elapsed time is 0.047512 seconds.
Elapsed time is 0.047687 seconds.
Elapsed time is 0.075987 seconds.

Contributing tests would be warmly welcome.
There's a number of corner cases, esp. if NaNs come into play, so I
expect bugs to be still there.

enjoy!

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

From shaiay at gmail.com  Thu Oct 15 02:56:50 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 15 Oct 2009 09:56:50 +0200
Subject: FYI: nth_element
In-Reply-To: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>
References: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>
Message-ID: <420fb9e60910150056t439c5b69vdfe30920819bba8f@mail.gmail.com>

On Thu, Oct 15, 2009 at 9:15 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
> hi all,
>
> Octave has just got a new function: nth_element:
> http://hg.savannah.gnu.org/hgweb/octave/rev/aea3a3a950e1
>
> the docstring:
>
> ?-- Built-in Function: ?nth_element (X, N)
> ?-- Built-in Function: ?nth_element (X, N, DIM)
> ? ? Select the n-th smallest element of a vector, using the ordering
> ? ? defined by `sort'. ?In other words, the result is equivalent to
> ? ? `sort(X)(N)'. ?N can also be a contiguous range, either ascending
> ? ? `l:u' or descending `u:-1:l', in which case a range of elements is
> ? ? returned. ?If X is an array, `nth_element' operates along the
> ? ? dimension defined by DIM, or the first non-singleton dimension if
> ? ? DIM is not given.
>
> ? ? nth_element encapsulates the C++ STL algorithms nth_element and
> ? ? partial_sort. ?On average, the complexity of the operation is
> ? ? O(M*log(K)), where `M = size(X, DIM)' and `K = length (N)'. ?This
> ? ? function is intended for cases where the ratio K/M is small;
> ? ? otherwise, it may be better to use `sort'.
>
> ? ? See also: sort, min, max
>
> In short, it allows extracting a small portion of sort(X) without
> actually doing the full sort.
> This is sometimes useful for statistics when computing quantiles and
> the like... statisticians can surely tell better.
>
> Maybe it can be used to boost some existing functions. As an example,
> it can be readily used to speed up the "median" function:
> http://hg.savannah.gnu.org/hgweb/octave/rev/b7b89061bd0e
>
It can also help hist quite a lot.

Shai


From highegg at gmail.com  Thu Oct 15 05:36:56 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 15 Oct 2009 12:36:56 +0200
Subject: FYI: nth_element
In-Reply-To: <420fb9e60910150056t439c5b69vdfe30920819bba8f@mail.gmail.com>
References: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>
	<420fb9e60910150056t439c5b69vdfe30920819bba8f@mail.gmail.com>
Message-ID: <69d8d540910150336t4ea62732vb88f99a281b85f6@mail.gmail.com>

On Thu, Oct 15, 2009 at 9:56 AM, Shai Ayal <shaiay at gmail.com> wrote:
> On Thu, Oct 15, 2009 at 9:15 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>> hi all,
>>
>> Octave has just got a new function: nth_element:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/aea3a3a950e1
>>
>> the docstring:
>>
>> ?-- Built-in Function: ?nth_element (X, N)
>> ?-- Built-in Function: ?nth_element (X, N, DIM)
>> ? ? Select the n-th smallest element of a vector, using the ordering
>> ? ? defined by `sort'. ?In other words, the result is equivalent to
>> ? ? `sort(X)(N)'. ?N can also be a contiguous range, either ascending
>> ? ? `l:u' or descending `u:-1:l', in which case a range of elements is
>> ? ? returned. ?If X is an array, `nth_element' operates along the
>> ? ? dimension defined by DIM, or the first non-singleton dimension if
>> ? ? DIM is not given.
>>
>> ? ? nth_element encapsulates the C++ STL algorithms nth_element and
>> ? ? partial_sort. ?On average, the complexity of the operation is
>> ? ? O(M*log(K)), where `M = size(X, DIM)' and `K = length (N)'. ?This
>> ? ? function is intended for cases where the ratio K/M is small;
>> ? ? otherwise, it may be better to use `sort'.
>>
>> ? ? See also: sort, min, max
>>
>> In short, it allows extracting a small portion of sort(X) without
>> actually doing the full sort.
>> This is sometimes useful for statistics when computing quantiles and
>> the like... statisticians can surely tell better.
>>
>> Maybe it can be used to boost some existing functions. As an example,
>> it can be readily used to speed up the "median" function:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/b7b89061bd0e
>>
> It can also help hist quite a lot.
>

I don't see how. Can you clarify?


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


From shaiay at gmail.com  Thu Oct 15 07:22:59 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 15 Oct 2009 14:22:59 +0200
Subject: FYI: nth_element
In-Reply-To: <69d8d540910150336t4ea62732vb88f99a281b85f6@mail.gmail.com>
References: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>
	<420fb9e60910150056t439c5b69vdfe30920819bba8f@mail.gmail.com>
	<69d8d540910150336t4ea62732vb88f99a281b85f6@mail.gmail.com>
Message-ID: <420fb9e60910150522g2533dd8bu2e64034076d48a29@mail.gmail.com>

On Thu, Oct 15, 2009 at 12:36 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Thu, Oct 15, 2009 at 9:56 AM, Shai Ayal <shaiay at gmail.com> wrote:
>> On Thu, Oct 15, 2009 at 9:15 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>> hi all,
>>>
>>> Octave has just got a new function: nth_element:
>>> http://hg.savannah.gnu.org/hgweb/octave/rev/aea3a3a950e1
>>>
>>> the docstring:
>>>
>>> ?-- Built-in Function: ?nth_element (X, N)
>>> ?-- Built-in Function: ?nth_element (X, N, DIM)
>>> ? ? Select the n-th smallest element of a vector, using the ordering
>>> ? ? defined by `sort'. ?In other words, the result is equivalent to
>>> ? ? `sort(X)(N)'. ?N can also be a contiguous range, either ascending
>>> ? ? `l:u' or descending `u:-1:l', in which case a range of elements is
>>> ? ? returned. ?If X is an array, `nth_element' operates along the
>>> ? ? dimension defined by DIM, or the first non-singleton dimension if
>>> ? ? DIM is not given.
>>>
>>> ? ? nth_element encapsulates the C++ STL algorithms nth_element and
>>> ? ? partial_sort. ?On average, the complexity of the operation is
>>> ? ? O(M*log(K)), where `M = size(X, DIM)' and `K = length (N)'. ?This
>>> ? ? function is intended for cases where the ratio K/M is small;
>>> ? ? otherwise, it may be better to use `sort'.
>>>
>>> ? ? See also: sort, min, max
>>>
>>> In short, it allows extracting a small portion of sort(X) without
>>> actually doing the full sort.
>>> This is sometimes useful for statistics when computing quantiles and
>>> the like... statisticians can surely tell better.
>>>
>>> Maybe it can be used to boost some existing functions. As an example,
>>> it can be readily used to speed up the "median" function:
>>> http://hg.savannah.gnu.org/hgweb/octave/rev/b7b89061bd0e
>>>
>> It can also help hist quite a lot.
>>
>
> I don't see how. Can you clarify?

You are right -- I was confused. hist needs the number of elements
smaller than a given value (and uses sort to find out), while
nth_element gives the value of the nth element.
Writing hist in c++ is not hard and would really help since it uses
(M+K)log(M+K) sort in order to avoid a M*K loop just because looping
is slow in the scripting language. One of these days I'll get down to
doing that ...

Shai


From highegg at gmail.com  Thu Oct 15 07:31:22 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 15 Oct 2009 14:31:22 +0200
Subject: FYI: nth_element
In-Reply-To: <420fb9e60910150522g2533dd8bu2e64034076d48a29@mail.gmail.com>
References: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>
	<420fb9e60910150056t439c5b69vdfe30920819bba8f@mail.gmail.com>
	<69d8d540910150336t4ea62732vb88f99a281b85f6@mail.gmail.com>
	<420fb9e60910150522g2533dd8bu2e64034076d48a29@mail.gmail.com>
Message-ID: <69d8d540910150531g2d81cd2wdacb203eb36ee351@mail.gmail.com>

On Thu, Oct 15, 2009 at 2:22 PM, Shai Ayal <shaiay at gmail.com> wrote:
> On Thu, Oct 15, 2009 at 12:36 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>> On Thu, Oct 15, 2009 at 9:56 AM, Shai Ayal <shaiay at gmail.com> wrote:
>>> On Thu, Oct 15, 2009 at 9:15 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>> hi all,
>>>>
>>>> Octave has just got a new function: nth_element:
>>>> http://hg.savannah.gnu.org/hgweb/octave/rev/aea3a3a950e1
>>>>
>>>> the docstring:
>>>>
>>>> ?-- Built-in Function: ?nth_element (X, N)
>>>> ?-- Built-in Function: ?nth_element (X, N, DIM)
>>>> ? ? Select the n-th smallest element of a vector, using the ordering
>>>> ? ? defined by `sort'. ?In other words, the result is equivalent to
>>>> ? ? `sort(X)(N)'. ?N can also be a contiguous range, either ascending
>>>> ? ? `l:u' or descending `u:-1:l', in which case a range of elements is
>>>> ? ? returned. ?If X is an array, `nth_element' operates along the
>>>> ? ? dimension defined by DIM, or the first non-singleton dimension if
>>>> ? ? DIM is not given.
>>>>
>>>> ? ? nth_element encapsulates the C++ STL algorithms nth_element and
>>>> ? ? partial_sort. ?On average, the complexity of the operation is
>>>> ? ? O(M*log(K)), where `M = size(X, DIM)' and `K = length (N)'. ?This
>>>> ? ? function is intended for cases where the ratio K/M is small;
>>>> ? ? otherwise, it may be better to use `sort'.
>>>>
>>>> ? ? See also: sort, min, max
>>>>
>>>> In short, it allows extracting a small portion of sort(X) without
>>>> actually doing the full sort.
>>>> This is sometimes useful for statistics when computing quantiles and
>>>> the like... statisticians can surely tell better.
>>>>
>>>> Maybe it can be used to boost some existing functions. As an example,
>>>> it can be readily used to speed up the "median" function:
>>>> http://hg.savannah.gnu.org/hgweb/octave/rev/b7b89061bd0e
>>>>
>>> It can also help hist quite a lot.
>>>
>>
>> I don't see how. Can you clarify?
>
> You are right -- I was confused. hist needs the number of elements
> smaller than a given value (and uses sort to find out), while
> nth_element gives the value of the nth element.
> Writing hist in c++ is not hard and would really help since it uses
> (M+K)log(M+K) sort in order to avoid a M*K loop just because looping
> is slow in the scripting language. One of these days I'll get down to
> doing that ...
>
> Shai
>

Why not just use a binary search, via `lookup'? That would be
O(M*log(K) + K) (M the number of data and K the number of bins).
Look what histc does... maybe hist can even simply call histc.

hth

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


From shaiay at gmail.com  Thu Oct 15 07:34:46 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 15 Oct 2009 14:34:46 +0200
Subject: FYI: nth_element
In-Reply-To: <69d8d540910150531g2d81cd2wdacb203eb36ee351@mail.gmail.com>
References: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>
	<420fb9e60910150056t439c5b69vdfe30920819bba8f@mail.gmail.com>
	<69d8d540910150336t4ea62732vb88f99a281b85f6@mail.gmail.com>
	<420fb9e60910150522g2533dd8bu2e64034076d48a29@mail.gmail.com>
	<69d8d540910150531g2d81cd2wdacb203eb36ee351@mail.gmail.com>
Message-ID: <420fb9e60910150534i5d4394bcobb754bc73d0ace66@mail.gmail.com>

On Thu, Oct 15, 2009 at 2:31 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Thu, Oct 15, 2009 at 2:22 PM, Shai Ayal <shaiay at gmail.com> wrote:
>> On Thu, Oct 15, 2009 at 12:36 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>> On Thu, Oct 15, 2009 at 9:56 AM, Shai Ayal <shaiay at gmail.com> wrote:
>>>> On Thu, Oct 15, 2009 at 9:15 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>>>> hi all,
>>>>>
>>>>> Octave has just got a new function: nth_element:
>>>>> http://hg.savannah.gnu.org/hgweb/octave/rev/aea3a3a950e1
>>>>>
>>>>> the docstring:
>>>>>
>>>>> ?-- Built-in Function: ?nth_element (X, N)
>>>>> ?-- Built-in Function: ?nth_element (X, N, DIM)
>>>>> ? ? Select the n-th smallest element of a vector, using the ordering
>>>>> ? ? defined by `sort'. ?In other words, the result is equivalent to
>>>>> ? ? `sort(X)(N)'. ?N can also be a contiguous range, either ascending
>>>>> ? ? `l:u' or descending `u:-1:l', in which case a range of elements is
>>>>> ? ? returned. ?If X is an array, `nth_element' operates along the
>>>>> ? ? dimension defined by DIM, or the first non-singleton dimension if
>>>>> ? ? DIM is not given.
>>>>>
>>>>> ? ? nth_element encapsulates the C++ STL algorithms nth_element and
>>>>> ? ? partial_sort. ?On average, the complexity of the operation is
>>>>> ? ? O(M*log(K)), where `M = size(X, DIM)' and `K = length (N)'. ?This
>>>>> ? ? function is intended for cases where the ratio K/M is small;
>>>>> ? ? otherwise, it may be better to use `sort'.
>>>>>
>>>>> ? ? See also: sort, min, max
>>>>>
>>>>> In short, it allows extracting a small portion of sort(X) without
>>>>> actually doing the full sort.
>>>>> This is sometimes useful for statistics when computing quantiles and
>>>>> the like... statisticians can surely tell better.
>>>>>
>>>>> Maybe it can be used to boost some existing functions. As an example,
>>>>> it can be readily used to speed up the "median" function:
>>>>> http://hg.savannah.gnu.org/hgweb/octave/rev/b7b89061bd0e
>>>>>
>>>> It can also help hist quite a lot.
>>>>
>>>
>>> I don't see how. Can you clarify?
>>
>> You are right -- I was confused. hist needs the number of elements
>> smaller than a given value (and uses sort to find out), while
>> nth_element gives the value of the nth element.
>> Writing hist in c++ is not hard and would really help since it uses
>> (M+K)log(M+K) sort in order to avoid a M*K loop just because looping
>> is slow in the scripting language. One of these days I'll get down to
>> doing that ...
>>
>> Shai
>>
>
> Why not just use a binary search, via `lookup'? That would be
> O(M*log(K) + K) (M the number of data and K the number of bins).
> Look what histc does... maybe hist can even simply call histc.
yes, I think hist should call histc -- the main difference between
them is that hist plots the results

Shai


From marco.caliari at univr.it  Fri Oct 16 04:33:41 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Fri, 16 Oct 2009 11:33:41 +0200 (CEST)
Subject: ismember with empty arguments
Message-ID: <alpine.DEB.1.00.0910161033530.9634@profs.sci.univr.it>

Dear maintainers,

I discovered a different behaviour between Octave and Matlab for the 
function ismember when the option 'rows' is given and one of the two 
arguments is empty.
In Matlab:

>> ismember(ones(2),[],'rows')
ans =

      0
      0
>> ismember([],ones(2),'rows')
ans =

    Empty matrix: 0-by-1
>> ismember([],[],'rows')
ans =

    Empty matrix: 0-by-1

Although I don't completely understand this behaviour, I enclosed a patch 
(against 3.2.3) which reproduces it.

Changelog

2009-10-16  Marco Caliari  <marco.caliari at univr.it>

 	* ismember.m: Fix behaviour for empty arguments.

Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ismember.m.patch
Type: text/x-diff
Size: 584 bytes
Desc: 
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091016/99c255ab/attachment.bin 

From highegg at gmail.com  Fri Oct 16 06:38:14 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 16 Oct 2009 13:38:14 +0200
Subject: FYI: ArrayN gone
Message-ID: <69d8d540910160438s4f954d11j46041c387c306a27@mail.gmail.com>

as a step towards simplifying the liboctave array class hierarchy, I
removed the ArrayN template class:
http://hg.savannah.gnu.org/hgweb/octave/rev/b4fdfee405b5

Rationale:
I don't know the historical purpose of ArrayN, but it surely evolved
into being a mere thin wrapper over Array, adding no useful
functionality besides defining a stream output operator, which can be
easily absorbed into Array.cc (and I'm not sure it's used at all).
Since Array is already multi-dimensional, I think the existence of
ArrayN only added confusion - it certainly confused me when I became a
contributor.
Further, it implied occassional necessity for ugly typecasts - for
instance, Array<T> usually needed to be re-cast to ArrayN<T> in order
to be stored in octave_value.
So I removed the ArrayN layer and replaced its usage by Array
everywhere. This went surprisingly flawlessly; still it uncovered some
hidden bugs in operator handlers where implicit conversion
constructors were silently doing unexpected things, and also some
mismatching types being passed around. Hence the seemingly unrelated
changes.

the ArrayN.h include file still exists but only includes Array.h and
#defines ArrayN to Array. Therefore, a lot of existing code
referencing ArrayN will just silently work with Array instead.
However, I also added a warning for GNU-compatible compilers (this can
be debated), so that users become aware of the obsolete feature. This
layout of things may be debated; for instance, we may make ArrayN
forever a valid alias for Array and print no warning...

MArrayN is the next target (to be merged with MArray). I'm not yet
sure what to do with the Array2 classes.

comments?

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

From highegg at gmail.com  Fri Oct 16 07:29:00 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 16 Oct 2009 14:29:00 +0200
Subject: ismember with empty arguments
In-Reply-To: <alpine.DEB.1.00.0910161033530.9634@profs.sci.univr.it>
References: <alpine.DEB.1.00.0910161033530.9634@profs.sci.univr.it>
Message-ID: <69d8d540910160529m61af71b7j15c8b1660b85d517@mail.gmail.com>

On Fri, Oct 16, 2009 at 11:33 AM, Marco Caliari <marco.caliari at univr.it> wrote:
> Dear maintainers,
>
> I discovered a different behaviour between Octave and Matlab for the
> function ismember when the option 'rows' is given and one of the two
> arguments is empty.
> In Matlab:
>
>>> ismember(ones(2),[],'rows')
>
> ans =
>
> ? ? 0
> ? ? 0
>>>
>>> ismember([],ones(2),'rows')
>
> ans =
>
> ? Empty matrix: 0-by-1
>>>
>>> ismember([],[],'rows')
>
> ans =
>
> ? Empty matrix: 0-by-1
>
> Although I don't completely understand this behaviour, I enclosed a patch
> (against 3.2.3) which reproduces it.
>
> Changelog
>
> 2009-10-16 ?Marco Caliari ?<marco.caliari at univr.it>
>
> ? ? ? ?* ismember.m: Fix behaviour for empty arguments.
>
> Marco

Since you patch doesn't apply to development sources, I created another:
http://hg.savannah.gnu.org/hgweb/octave/rev/aab4f2aa9ed9

thanks

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


From thomas.weber.mail at gmail.com  Fri Oct 16 15:43:59 2009
From: thomas.weber.mail at gmail.com (Thomas Weber)
Date: Fri, 16 Oct 2009 22:43:59 +0200
Subject: image and video processing capabilities
In-Reply-To: <332fe7910910142012y30159009u718729c7eda175ab@mail.gmail.com>
References: <332fe7910910142012y30159009u718729c7eda175ab@mail.gmail.com>
Message-ID: <20091016204359.GC11899@atlan>

Hi Simon, 

On Thu, Oct 15, 2009 at 12:12:20AM -0300, Simon Bourguigne wrote:
> Hello everybody! There is a public domain software called ImageJ used widely
> in biology. It comes with source code and documentation; and a lot, if not
> all, of the functions and capabilities for image and video processing can be
> used for octave. I try to do it myself, but i'm still learning and there's
> still a lot more to learn. Among the non-processing tools there's image and
> video importing code for a large list of different formats. It's entirely
> written in Java. Here are a couple of links:
> 
> Description : http://en.wikipedia.org/wiki/ImageJ
> 
> Source Code: http://rsbweb.nih.gov/ij/docs/source/index.html
> 
> Official Website: http://rsbweb.nih.gov/ij/
> 
> thanx in advance for any answer,

Uh, what answers do you expect? I don't see any question.

	Thomas

From jordigh at gmail.com  Sat Oct 17 12:22:57 2009
From: jordigh at gmail.com (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermoso?=)
Date: Sat, 17 Oct 2009 12:22:57 -0500
Subject: FYI: nth_element
In-Reply-To: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>
References: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>
Message-ID: <9543b3a40910171022g1b87dabds8f95f95ba3ac0d81@mail.gmail.com>

2009/10/15 Jaroslav Hajek <highegg at gmail.com>:
>     nth_element encapsulates the C++ STL algorithms nth_element and
>     partial_sort.

Silly and pointless nitpickery: would you please refer to it as  the
C++ standard library instead of STL? Although nth_element and
partial_sort are indeed in the STL that SGI contribute to the C++
stdlib and the GNU implementation is based on SGI's contributions, the
term "STL", 11 years after being standardised and very well
implemented, still carries connotations of "strange, bloated, foreign,
and nonstandard part of C++".

For marketing purposes, I think it's better to say that these are
Octave functions that are wrapping standard C++ functions. That's all.
;-)

From highegg at gmail.com  Sat Oct 17 14:29:25 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sat, 17 Oct 2009 21:29:25 +0200
Subject: FYI: nth_element
In-Reply-To: <9543b3a40910171022g1b87dabds8f95f95ba3ac0d81@mail.gmail.com>
References: <69d8d540910150015k5b8ffb6dq92732025aa36b1d9@mail.gmail.com>
	<9543b3a40910171022g1b87dabds8f95f95ba3ac0d81@mail.gmail.com>
Message-ID: <69d8d540910171229g4b721578of487d6772046310f@mail.gmail.com>

2009/10/17 Jordi Guti?rrez Hermoso <jordigh at gmail.com>:
> 2009/10/15 Jaroslav Hajek <highegg at gmail.com>:
>> ? ? nth_element encapsulates the C++ STL algorithms nth_element and
>> ? ? partial_sort.
>
> Silly and pointless nitpickery: would you please refer to it as ?the
> C++ standard library instead of STL? Although nth_element and
> partial_sort are indeed in the STL that SGI contribute to the C++
> stdlib and the GNU implementation is based on SGI's contributions, the
> term "STL", 11 years after being standardised and very well
> implemented, still carries connotations of "strange, bloated, foreign,
> and nonstandard part of C++".
>

Sorry, I was not aware of the distinction. For me, STL was simply the
containers+algorithms part of C++ standard library.

> For marketing purposes, I think it's better to say that these are
> Octave functions that are wrapping standard C++ functions. That's all.
> ;-)
>

Marketing? I hope not :)


-- 
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  Sat Oct 17 12:23:58 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 17 Oct 2009 13:23:58 -0400
Subject: Brittleness with texinfo and version numbering
In-Reply-To: <MTAwMDA0My5ub21hZA.1255493624@quikprotect>
References: <MTAwMDAzNi5ub21hZA.1255369601@quikprotect>
	<19156.22908.790892.25147@hugo.lan>
	<MTAwMDA0My5ub21hZA.1255493624@quikprotect>
Message-ID: <19161.64942.357946.819476@hugo.lan>

On 13-Oct-2009, Rik wrote:

| I agree it's a problem with texinfo, but I think it will take a longer
| to fix it this way than simply avoiding the problem.

The problem only shows up if you do a "make dist" on an Octave version
from the hg archive, which isn't something that I expect to happen
often.  If I make a snapshot, then I use a "normal" version number.

| If there's a hole 
| in the sidewalk I can call the city and it might be repaired 6 months
| from now.  Or I could just walk down a different street.

Would you also call the city while walking down the different street,
or just leave it to someone else to do that job?

| There were already problems with this exact macro in 2008 when it
| wouldn't accept the '@' character and David Bateman had to query and
| track down a bug fix.  Not to be mean to the texinfo developers, but I
| just don't have time to pursue that process.

As I recall, Karl Berry fixed the problem promptly, and all we needed
to do was distribute a patched version of texinfo.tex until a fixed
version was released.  I expect the same might happen this time.

For me, one of the big plusses of free software is that we can fix
bugs rather than just work around them.  But that requires that people
actually report problems that they encounter rather than just trying
to avoid them.

jwe

From jwe at octave.org  Sat Oct 17 12:28:32 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 17 Oct 2009 13:28:32 -0400
Subject: Patch to stop counting missing tests on internal functions
In-Reply-To: <MTAwMDAxNi5ub21hZA.1255543543@quikprotect>
References: <MTAwMDAyMS5ub21hZA.1255107996@quikprotect>
	<19156.20197.242290.724607@hugo.lan>
	<69d8d540910130412r1c46d578rdf758fcb075ac3f1@mail.gmail.com>
	<19156.23108.112355.878361@hugo.lan>
	<MTAwMDAxNi5ub21hZA.1255543543@quikprotect>
Message-ID: <19161.65216.641584.674803@hugo.lan>

On 14-Oct-2009, Rik wrote:

| Maybe we are going about this the wrong way.  The current script
| searches for all *.cc and *.m files and then checks whether there there
| are any test features (%!test, %!assert, %!error, %!warning) in the
| file.  This check is too simplistic and the results are both overly
| pessimistic and overly optimistic.  First, they are overly pessimistic
| because they seem to show that a lot of files are undocumented, but most
| of these files do not contain user functions and instead are helping
| code or auto-generated code.  Secondly, they are overly optimistic about
| coverage because even a single test for a single function will count the
| entire file as being covered.  The file utils.cc has 12 functions in it
| and it would be useful to know which ones actually had coverage.
| 
| What if we start with the list of functions visible to Octave (using
| calls to __builtins__ and __list_functions__) and then cycle through
| that list trying to call any test functions?  If there are no tests then
| the test function returns something to indicate that and we can mark the
| function as needing work.

Searching for .m files seems reasonable because there is one
user-visible function per file.  But yes, we often have more than one
DEFUN in a single .cc file, so I agree that it would be better to do
tests for each DEFUN instead of for each .cc file.  However, we
currently have no way to tag a test as being for a particular
function, so I don't see how to do what you propose.

jwe

From jwe at octave.org  Sat Oct 17 12:36:56 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 17 Oct 2009 13:36:56 -0400
Subject: FYI: ArrayN gone
In-Reply-To: <69d8d540910160438s4f954d11j46041c387c306a27@mail.gmail.com>
References: <69d8d540910160438s4f954d11j46041c387c306a27@mail.gmail.com>
Message-ID: <19162.184.368378.840787@hugo.lan>

On 16-Oct-2009, Jaroslav Hajek wrote:

| as a step towards simplifying the liboctave array class hierarchy, I
| removed the ArrayN template class:
| http://hg.savannah.gnu.org/hgweb/octave/rev/b4fdfee405b5
| 
| Rationale:
| I don't know the historical purpose of ArrayN, but it surely evolved
| into being a mere thin wrapper over Array, adding no useful

I think the original classes had Array as a single-dimensional array
only, Array2 as a 2-dimensional array, and ArrayN providing
N-dimensional arrays.  But then at some point, Array was extended to
handle all dimensions.  So I think it is good to get rid of ArrayN.
Thanks for doing this job.

| MArrayN is the next target (to be merged with MArray).

OK.

| I'm not yet sure what to do with the Array2 classes.

I suppose the funtionality of Array2 might be absorbed by Array.  For
things that only make sense for 2-d arrays (transpose, hermitian,
etc.) we would simply need checks to ensure that the object actually
has exactly 2 dimensions and otherwise throw an error.  Would that work?

jwe

From jwe at octave.org  Sat Oct 17 12:47:21 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 17 Oct 2009 13:47:21 -0400
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <4AD4C469.1080604@isl.stanford.edu>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
	<4AD4C469.1080604@isl.stanford.edu>
Message-ID: <19162.809.445103.387353@hugo.lan>

On 13-Oct-2009, Michael D. Godfrey wrote:

| One thing to add to the limitations:
| 
| 5. No TeX interpretation.

The simple TeX interpretation used by the gnuplot backend is done in a
.m file, so perhaps this code could be used as is and shared among
multiple backends, or translated to C++ (and also shared)?

jwe

From octave at nomad.inbox5.com  Sat Oct 17 19:55:04 2009
From: octave at nomad.inbox5.com (Rik)
Date: Sat, 17 Oct 2009 17:55:04 -0700
Subject: Brittleness with texinfo and version numbering
In-Reply-To: <19161.64942.357946.819476@hugo.lan>
References: <MTAwMDAzNi5ub21hZA.1255369601@quikprotect>	<19156.22908.790892.25147@hugo.lan>	<MTAwMDA0My5ub21hZA.1255493624@quikprotect>
	<19161.64942.357946.819476@hugo.lan>
Message-ID: <MTAwMDAwNC5ub21hZA.1255827312@quikprotect>

John W. Eaton wrote:
> On 13-Oct-2009, Rik wrote:
>
> | I agree it's a problem with texinfo, but I think it will take a longer
> | to fix it this way than simply avoiding the problem.
>
> The problem only shows up if you do a "make dist" on an Octave version
> from the hg archive, which isn't something that I expect to happen
> often.  If I make a snapshot, then I use a "normal" version number.
>
>   
This is fine.  If it is a low frequency event then it is easier to avoid
it then to fix it.   That was the point I was trying to convey regarding
texinfo as well.

--Rik

From godfrey at isl.stanford.edu  Sat Oct 17 22:53:58 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 17 Oct 2009 20:53:58 -0700
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <19162.809.445103.387353@hugo.lan>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>	<4AD4C469.1080604@isl.stanford.edu>
	<19162.809.445103.387353@hugo.lan>
Message-ID: <4ADA9156.30800@isl.stanford.edu>

On 10/17/2009 10:47 AM, John W. Eaton wrote:
> On 13-Oct-2009, Michael D. Godfrey wrote:
>
> | One thing to add to the limitations:
> |
> | 5. No TeX interpretation.
>
> The simple TeX interpretation used by the gnuplot backend is done in a
> .m file, so perhaps this code could be used as is and shared among
> multiple backends, or translated to C++ (and also shared)?
>
> jwe

Right. This is a good first step.  I will try to learn more about
more complete solutions.

Michael

From shaiay at gmail.com  Sat Oct 17 23:38:16 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sun, 18 Oct 2009 06:38:16 +0200
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <4ADA9156.30800@isl.stanford.edu>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
	<4AD4C469.1080604@isl.stanford.edu> <19162.809.445103.387353@hugo.lan>
	<4ADA9156.30800@isl.stanford.edu>
Message-ID: <420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>

On Sun, Oct 18, 2009 at 5:53 AM, Michael D Godfrey
<godfrey at isl.stanford.edu> wrote:
> On 10/17/2009 10:47 AM, John W. Eaton wrote:
>>
>> On 13-Oct-2009, Michael D. Godfrey wrote:
>>
>> | One thing to add to the limitations:
>> |
>> | 5. No TeX interpretation.
>>
>> The simple TeX interpretation used by the gnuplot backend is done in a
>> .m file, so perhaps this code could be used as is and shared among
>> multiple backends, or translated to C++ (and also shared)?
>>
>> jwe
>
> Right. This is a good first step. ?I will try to learn more about
> more complete solutions.

No to discourage anyone but gnuplot supports all the elements needed
for nice math typesettings (e.g. super & subscript), "all" that is
needed is a translation from TeX to gnuplot. There is nothing
equivalent in postscript and/or gl2ps which just know how to "render"
strings of a fixed font and size, so the problem might be bigger ...

Shai


From godfrey at isl.stanford.edu  Sun Oct 18 00:36:49 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sat, 17 Oct 2009 22:36:49 -0700
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>	
	<4AD4C469.1080604@isl.stanford.edu>
	<19162.809.445103.387353@hugo.lan>	
	<4ADA9156.30800@isl.stanford.edu>
	<420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>
Message-ID: <4ADAA971.8020409@isl.stanford.edu>

On 10/17/2009 09:38 PM, Shai Ayal wrote:
> No to discourage anyone but gnuplot supports all the elements needed
> for nice math typesettings (e.g. super&  subscript), "all" that is
> needed is a translation from TeX to gnuplot. There is nothing
> equivalent in postscript and/or gl2ps which just know how to "render"
> strings of a fixed font and size, so the problem might be bigger ...
>
> Shai

Well, you are right.  In any case it would be good to work
toward a complete solution that allows full TeX/LaTeX.  It may be
that learning from Asymptote is a place to start.  Asymptote is
on SourceForge.  It provides "LaTeX typesetting of labels,"
so it might be useful to look at how they do it.  It also claims
to be "inspired by MetaPost..."  I have used MetaPost quite a bit
and it is very useful and well done.

The Asymptote URL is:
http://asymptote.sourceforge.net/

Michael

From soren at hauberg.org  Sun Oct 18 02:16:42 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sun, 18 Oct 2009 09:16:42 +0200
Subject: base-qr.h: No such file or directory
Message-ID: <1255850202.5086.10.camel@sh-t400>

Hi All

Running a very recent checkout. I'm trying to compile some C++ code that
was sent to the Octave-Forge list. This code contains

  #include <octave/oct.h>

which results in the following compile-time error:

        /home/sh/Programmer/include/octave-3.3.50
        +/octave/dbleQR.h:33:21: error: base-qr.h: No such file or
        directory

I have 'base-qr.h' in my checkout of the repository, but it does not
seem to be in my installation directory. Does it need to be added to
some Makefile?

S?ren


From michael.goffioul at gmail.com  Sun Oct 18 03:02:20 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Sun, 18 Oct 2009 09:02:20 +0100
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
	<4AD4C469.1080604@isl.stanford.edu> <19162.809.445103.387353@hugo.lan>
	<4ADA9156.30800@isl.stanford.edu>
	<420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>
Message-ID: <128f38bd0910180102k68e2e278sf296f1064d376b1d@mail.gmail.com>

On Sun, Oct 18, 2009 at 5:38 AM, Shai Ayal <shaiay at gmail.com> wrote:
> No to discourage anyone but gnuplot supports all the elements needed
> for nice math typesettings (e.g. super & subscript), "all" that is
> needed is a translation from TeX to gnuplot. There is nothing
> equivalent in postscript and/or gl2ps which just know how to "render"
> strings of a fixed font and size, so the problem might be bigger ...

You might want to have a look at the gl2ps code shipped with JHandles.
This is a modified version that can do some additional formatting
(like subscript or superscripts) and produce corresponding PS code.

Michael.

From highegg at gmail.com  Sun Oct 18 04:39:02 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sun, 18 Oct 2009 11:39:02 +0200
Subject: base-qr.h: No such file or directory
In-Reply-To: <1255850202.5086.10.camel@sh-t400>
References: <1255850202.5086.10.camel@sh-t400>
Message-ID: <69d8d540910180239wb7d2b07j392fce87eb5784a1@mail.gmail.com>

On Sun, Oct 18, 2009 at 9:16 AM, S?ren Hauberg <soren at hauberg.org> wrote:
> Hi All
>
> Running a very recent checkout. I'm trying to compile some C++ code that
> was sent to the Octave-Forge list. This code contains
>
> ?#include <octave/oct.h>
>
> which results in the following compile-time error:
>
> ? ? ? ?/home/sh/Programmer/include/octave-3.3.50
> ? ? ? ?+/octave/dbleQR.h:33:21: error: base-qr.h: No such file or
> ? ? ? ?directory
>
> I have 'base-qr.h' in my checkout of the repository, but it does not
> seem to be in my installation directory. Does it need to be added to
> some Makefile?
>
> S?ren
>
>

Oops, my bad. Fixed.

thanks

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


From soren at hauberg.org  Sun Oct 18 13:43:49 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Sun, 18 Oct 2009 20:43:49 +0200
Subject: Doxygen documentation
Message-ID: <1255891429.5086.85.camel@sh-t400>

Hi All

We're in the process of changing the Octave-Forge website to allow for a
different release procedure. The current test-version of the website is
available at

  http://octave.sf.net/test

One issue about the webpage that is being discussed is if we should host
Doxygen generated documentation on this webpage (as we are doing now).
The argument against having this on octave.sf.net is that such
documentation is about core Octave and not about the packages.

So, I'd like to ask if we should host Doxygen generated documentation on
www.octave.org instead? The argument against having this on
www.octave.org is that it might give the impression that the C++ API is
stable.

Any thoughts on this?

S?ren

P.S. Most of the stuff on the new webpage is auto-generated and the code
for this should scale to other websites. So, it could be used for
www.octave.org as well.


From octave at phaselockedsystems.com  Sun Oct 18 14:31:38 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Sun, 18 Oct 2009 12:31:38 -0700
Subject: Doxygen documentation
In-Reply-To: <1255891429.5086.85.camel@sh-t400>
References: <1255891429.5086.85.camel@sh-t400>
Message-ID: <4ADB6D1A.8080105@phaselockedsystems.com>

S?ren Hauberg wrote:
> Hi All
>
> We're in the process of changing the Octave-Forge website to allow for a
> different release procedure. The current test-version of the website is
> available at
>
>   http://octave.sf.net/test
>
> One issue about the webpage that is being discussed is if we should host
> Doxygen generated documentation on this webpage (as we are doing now).
> The argument against having this on octave.sf.net is that such
> documentation is about core Octave and not about the packages.
>
> So, I'd like to ask if we should host Doxygen generated documentation on
> www.octave.org instead? The argument against having this on
> www.octave.org is that it might give the impression that the C++ API is
> stable.
>
> Any thoughts on this?
>
> S?ren
>
> P.S. Most of the stuff on the new webpage is auto-generated and the code
> for this should scale to other websites. So, it could be used for
> www.octave.org as well.
>
>
>
>   
I can't see how the stability argument is any argument at all.  Open 
source code is rarely very stable and backwards compatibility is seldom 
a design goal.  I personally think well in pictures and the results from 
doxygen are helpful.

Personally, I think we should include doxygen markup in all the octave 
sources.  I realize it is a lot of work, but worth it.  I have said 
before that the biggest obstacle to newbies making real contributions to 
the octave core is the enormous learning curve involved in understanding 
the sources.  I really think the number of people that understand the 
sources is so small as to be frightening.  If JWE and Jaroslav were to 
suddenly be unavailable, I fear that octave development would be 
crippled, possibly beyond recovery.

I guess I should clarify - I don't care WHAT markup we use, but doxygen 
seems to be the de facto standard.

Bob


From shaiay at gmail.com  Sun Oct 18 15:30:53 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Sun, 18 Oct 2009 22:30:53 +0200
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <128f38bd0910180102k68e2e278sf296f1064d376b1d@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
	<4AD4C469.1080604@isl.stanford.edu> <19162.809.445103.387353@hugo.lan>
	<4ADA9156.30800@isl.stanford.edu>
	<420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>
	<128f38bd0910180102k68e2e278sf296f1064d376b1d@mail.gmail.com>
Message-ID: <420fb9e60910181330k7928f321h7c3d2cd5f71628e@mail.gmail.com>

On Sun, Oct 18, 2009 at 10:02 AM, Michael Goffioul
<michael.goffioul at gmail.com> wrote:
> On Sun, Oct 18, 2009 at 5:38 AM, Shai Ayal <shaiay at gmail.com> wrote:
>> No to discourage anyone but gnuplot supports all the elements needed
>> for nice math typesettings (e.g. super & subscript), "all" that is
>> needed is a translation from TeX to gnuplot. There is nothing
>> equivalent in postscript and/or gl2ps which just know how to "render"
>> strings of a fixed font and size, so the problem might be bigger ...
>
> You might want to have a look at the gl2ps code shipped with JHandles.
> This is a modified version that can do some additional formatting
> (like subscript or superscripts) and produce corresponding PS code.

Can this be done w/o additional work in the renderer -- i.e. only by
using the new PS macros in the modified gl2ps, or do you need to
implement some sort of a simple TeX interpreter as you do in
SimpleTextEngine.java?

Shai

From godfrey at isl.stanford.edu  Sun Oct 18 15:48:13 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Sun, 18 Oct 2009 13:48:13 -0700
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <420fb9e60910181330k7928f321h7c3d2cd5f71628e@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>	
	<4AD4C469.1080604@isl.stanford.edu>
	<19162.809.445103.387353@hugo.lan>	
	<4ADA9156.30800@isl.stanford.edu>	
	<420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>	
	<128f38bd0910180102k68e2e278sf296f1064d376b1d@mail.gmail.com>
	<420fb9e60910181330k7928f321h7c3d2cd5f71628e@mail.gmail.com>
Message-ID: <4ADB7F0D.2080701@isl.stanford.edu>

On 10/18/2009 01:30 PM, Shai Ayal wrote:
> On Sun, Oct 18, 2009 at 10:02 AM, Michael Goffioul
> <michael.goffioul at gmail.com>  wrote:
>    
>> >  On Sun, Oct 18, 2009 at 5:38 AM, Shai Ayal<shaiay at gmail.com>  wrote:
>>      
>>> >>  No to discourage anyone but gnuplot supports all the elements needed
>>> >>  for nice math typesettings (e.g. super&  subscript), "all" that is
>>> >>  needed is a translation from TeX to gnuplot. There is nothing
>>> >>  equivalent in postscript and/or gl2ps which just know how to "render"
>>> >>  strings of a fixed font and size, so the problem might be bigger ...
>>>        
>> >
>> >  You might want to have a look at the gl2ps code shipped with JHandles.
>> >  This is a modified version that can do some additional formatting
>> >  (like subscript or superscripts) and produce corresponding PS code.
>>      
> Can this be done w/o additional work in the renderer -- i.e. only by
> using the new PS macros in the modified gl2ps, or do you need to
> implement some sort of a simple TeX interpreter as you do in
> SimpleTextEngine.java?
>
> Shai
>    
If it is easy to handle PS (or PDF) code for text strings you could consider
just running pdflatex on the string (with suitable header and trailer) and
use the resulting PDF.

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091018/51b76307/attachment.html 

From michael.goffioul at gmail.com  Mon Oct 19 03:08:35 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Mon, 19 Oct 2009 09:08:35 +0100
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <420fb9e60910181330k7928f321h7c3d2cd5f71628e@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
	<4AD4C469.1080604@isl.stanford.edu> <19162.809.445103.387353@hugo.lan>
	<4ADA9156.30800@isl.stanford.edu>
	<420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>
	<128f38bd0910180102k68e2e278sf296f1064d376b1d@mail.gmail.com>
	<420fb9e60910181330k7928f321h7c3d2cd5f71628e@mail.gmail.com>
Message-ID: <128f38bd0910190108j3def3af4o41d764624fd6a826@mail.gmail.com>

On Sun, Oct 18, 2009 at 9:30 PM, Shai Ayal <shaiay at gmail.com> wrote:
> Can this be done w/o additional work in the renderer -- i.e. only by
> using the new PS macros in the modified gl2ps, or do you need to
> implement some sort of a simple TeX interpreter as you do in
> SimpleTextEngine.java?

I guess it is imaginable to process something like:
a_{12}+x^2*\theta_1 entirely in PS, but I guess it can be a little
bit tedious. What I did is to re-use the visitor pattern I had implemented
for normal rendering to split a string into elements and add the PS code
to render those elements.

Michael.

From soren at hauberg.org  Mon Oct 19 13:28:25 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Mon, 19 Oct 2009 20:28:25 +0200
Subject: 'strread' and 'textread'
Message-ID: <1255976905.4518.26.camel@sh-t400>

Hi All

A bug that wasn't easy to fix was reported against the implementation of
'textread' available in the 'io' package at the Octave-Forge mailing
list. Eric Chassande-Mottin volunteered to provide a Matlab compatible
m-file implementation of the function, that Jaroslav and myself then
vectorised.

Since 'textread' (and its string counterpart 'strread') are part of core
Matlab, I thought I'd suggest the code for inclusion in core Octave
instead of the 'io' package. Attached is a changeset that adds the two
functions.

S?ren
-------------- next part --------------
# HG changeset patch
# User Soren Hauberg <hauberg at gmail.com>
# Date 1255976380 -7200
# Node ID 733359750f7c0eec057342aa9dd27a329e6e6c2a
# Parent  78ac37d735577196763c36249727557a1e9ce3da
scripts/io/strread.m scripts/io/textread.m: new functions

diff -r 78ac37d73557 -r 733359750f7c scripts/ChangeLog
--- a/scripts/ChangeLog	Mon Oct 19 12:12:58 2009 +0200
+++ b/scripts/ChangeLog	Mon Oct 19 20:19:40 2009 +0200
@@ -1,3 +1,7 @@
+2009-10-19  Soren Hauberg  <hauberg at gmail.com>
+
+	* io/strread.m io/textread.m: New functions.
+
 2009-10-15  David Bateman  <dbateman at free.fr>
 
 	* plot/__go_draw_axes__.m: Allow line and surface markerfacecolor
diff -r 78ac37d73557 -r 733359750f7c scripts/io/Makefile.in
--- a/scripts/io/Makefile.in	Mon Oct 19 12:12:58 2009 +0200
+++ b/scripts/io/Makefile.in	Mon Oct 19 20:19:40 2009 +0200
@@ -32,7 +32,7 @@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
 INSTALL_DATA = @INSTALL_DATA@
 
-SOURCES = beep.m csvread.m csvwrite.m dlmwrite.m
+SOURCES = beep.m csvread.m csvwrite.m dlmwrite.m strread.m textread.m
 
 DISTFILES = $(addprefix $(srcdir)/, Makefile.in $(SOURCES))
 
diff -r 78ac37d73557 -r 733359750f7c scripts/io/strread.m
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/scripts/io/strread.m	Mon Oct 19 20:19:40 2009 +0200
@@ -0,0 +1,248 @@
+## Copyright (C) 2009 Eric Chassande-Mottin, CNRS (France)
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 3 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, see
+## <http://www.gnu.org/licenses/>.
+
+## -*- texinfo -*-
+## @deftypefn {Function File}  {[@var{a}, @dots{}] =} strread (@var{str})
+## @deftypefnx {Function File}  {[@var{a}, @dots{}] =} strread (@var{str}, @var{format})
+## @deftypefnx {Function File} {[@var{a}, @dots{}] =} strread (@var{str}, @var{format}, @
+## @var{prop1}, @var{value1}, @dots{})
+## Read data from a string.
+##
+## The string @var{str} is split into words that are repeatedly matched to the
+## specifiers in @var{format}. The first word is matched to the first specifier,
+## the second to the second specifier and so forth. If there are more words than
+## specifiers, the process is repeated until all words have been processed.
+##
+## The string @var{format} describes how the words in @var{str} should be parsed.
+## It may contain any combination of the following specifiers:
+## @table @code
+## @item %s
+## The word is parsed as a string.
+## @item %d
+## @itemx %f
+## The word is parsed as a number.
+## @item %*
+## The word is skipped.
+## @end table
+##
+## Parsed word corresponding to the first specifier are returned in the first
+## output argument and likewise for the rest of the specifiers.
+##
+## By default, @var{format} is @t{"%f"}, meaning that numbers are read from @var{str}.
+##
+## For example, the string
+##
+## @example
+## @group
+## @var{str} = "\
+## Bunny Bugs   5.5\n\
+## Duck Daffy  -7.5e-5\n\
+## Penguin Tux   6"
+## @end group
+## @end example
+##
+## can be read using
+##
+## @example
+## [@var{a}, @var{b}, @var{c}] = strread (@var{str}, "%s %s %f");
+## @end example
+##
+## The behaviour of @code{strread} can be changed via properties @var{prop}
+## @itemize @code
+## @item "headerlines":
+## The first @var{value} number of lines of @var{str} are skipped.
+## @item "commentstyle":
+## Parts of @var{str} are considered comments and will be skipped.
+## @var{value} is the comment style and can be any of the following.
+## @itemize
+## @item "shell"
+## Everything from @code{#} characters to the nearest end-line is skipped.
+## @item "c"
+## Everything between @code{/*} and @code{*/} is skipped.
+## @item "c++"
+## Everything from @code{//} characters to the nearest end-line is skipped.
+## @item "matlab"
+## Everything from @code{%} characters to the nearest end-line is skipped.
+## @end itemize
+## @item "delimiter"
+## Any character in @var{value} will be used to split @var{str} into words.
+## @item "emptyvalue"
+## Parts of the output where no word is available is filled with @var{value}.
+## @end itemize
+##
+## @seealso{textread, load, dlmread, fscanf}
+## @end deftypefn
+
+function varargout = strread (str, formatstr = "%f", varargin)
+  ## Check input
+  if (nargin < 1)
+    print_usage ();
+  endif
+  
+  if (!ischar (str) || !ischar (str))
+    error ("strread: first and second input arguments must be strings");
+  endif
+
+  ## Parse options
+  comment_flag = false;
+  header_skip = 0;
+  numeric_fill_value = 0;
+  white_spaces = " \n\r\t\b";
+  for n = 1:2:length (varargin)
+    switch (lower (varargin {n}))
+      case "commentstyle"
+        comment_flag = true;
+        switch (lower (varargin {n+1}))
+          case "c"
+            comment_specif = {"/*", "*/"};
+          case "c++"
+            comment_specif = {"//", "\n"};
+          case "shell"
+            comment_specif = {"#", "\n"};
+          case "matlab"
+            comment_specif = {"%", "\n"};
+          otherwise
+            warning ("strread: unknown comment style '%s'", val);
+        endswitch
+      case "headerlines"
+        header_skip = varargin {n+1};
+      case "delimiter"
+	delimiter_str = varargin {n+1};
+      case "emptyvalue"
+	numeric_fill_value = varargin {n+1};
+      case "bufsize"
+        ## XXX: We could synthesize this, but that just seems weird...
+	warning ("strread: property \"bufsize\"  is not implemented");
+      case "whitespace"
+	white_spaces = varargin {n+1}; 
+      case "expchars"
+	warning ("strread: property \"expchars\"  is not implemented");
+      otherwise
+        warning ("strread: unknown property \"%s\"", varargin {n});
+    endswitch
+  endfor
+
+  ## Parse format string
+  idx = strfind (formatstr, "%")';
+  specif = formatstr ([idx, idx+1]);
+  nspecif = length (idx);
+  idx_star = strfind (formatstr, "%*");
+  nfields = length (idx) - length (idx_star);
+
+  if (max (nargout, 1) != nfields)
+    error ("strread: the number of output variables must match that of format specifiers");
+  endif
+
+  ## Remove header
+  if (header_skip > 0)
+    e = find (str == "\n", header_skip);
+    if (length (e) >= header_skip)
+      str = str (e (end)+1:end);
+    else
+      ## We don't have enough data so we discard it all
+      str = "";
+    endif
+  endif
+
+  ## Remove comments
+  if (comment_flag)
+    cstart = strfind (str, comment_specif{1});
+    cstop  = strfind (str, comment_specif{2});
+    if (length (cstart) > 0)
+      ## Ignore nested openers.
+      [idx, cidx] = unique (lookup (cstop, cstart), "first");
+      if (idx(end) == length (cstop))
+        cidx(end) = []; # Drop the last one if orphaned.
+      endif
+      cstart = cstart(cidx);
+    endif
+    if (length (cstop) > 0)
+      ## Ignore nested closers.
+      [idx, cidx] = unique (lookup (cstart, cstop), "first");
+      if (idx(1) == 0)
+        cidx(1) = []; # Drop the first one if orphaned.
+      endif
+      cstop = cstop(cidx);
+    endif
+    len = length (str);
+    c2len = length (comment_specif{2});
+    str = cellslices (str, [1, cstop + c2len], [cstart - 1, len]);
+    str = [str{:}];
+  endif
+  
+  ## Split 'str' into words
+  words = split_by (str, white_spaces);
+  num_words = numel (words);
+  num_lines = ceil (num_words / nspecif);
+  
+  ## For each specifier
+  k = 1;
+  for m = 1:nspecif
+    data = words (m:nspecif:end);
+
+    ## Map to format
+    switch specif (m, :)
+      case "%s"
+        data (end+1:num_lines) = {""};
+        varargout {k} = data';
+        k++;
+      case {"%d", "%f"}
+        data = str2double (data);
+        data (end+1:num_lines) = numeric_fill_value;
+        varargout {k} = data.';
+        k++;
+      case "%*"
+        ## do nothing
+    endswitch
+  endfor
+endfunction
+
+function out = split_by (text, sep)
+  out = strtrim (strsplit (text, sep, true));
+endfunction
+
+%!test
+%! str = "# comment\n# comment\n1 2 3";
+%! [a, b] = strread (str, '%d %s', 'commentstyle', 'shell');
+%! assert (a, [1; 3]);
+%! assert (b, {"2"; ""});
+
+%!test
+%! str = '';
+%! a = rand (10, 1);
+%! b = char (round (65 + 20 * rand (10, 1)));
+%! for k = 1:10
+%!   str = sprintf ('%s %.6f %s\n', str, a (k), b (k));
+%! endfor
+%! [aa, bb] = strread (str, '%f %s');
+%! assert (a, aa, 1e-5);
+%! assert (cellstr (b), bb);
+
+%!test
+%! str = '';
+%! a = rand (10, 1);
+%! b = char (round (65 + 20 * rand (10, 1)));
+%! for k = 1:10
+%!   str = sprintf ('%s %.6f %s\n', str, a (k), b (k));
+%! endfor
+%! aa = strread (str, '%f %*s');
+%! assert (a, aa, 1e-5);
+
+%!test
+%! str = sprintf ('/* this is\nacomment*/ 1 2 3');
+%! a = strread (str, '%f', 'commentstyle', 'c');
+%! assert (a, [1; 2; 3]);
+
diff -r 78ac37d73557 -r 733359750f7c scripts/io/textread.m
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/scripts/io/textread.m	Mon Oct 19 20:19:40 2009 +0200
@@ -0,0 +1,51 @@
+## Copyright (C) 2009 Eric Chassande-Mottin, CNRS (France)
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 3 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, see
+## <http://www.gnu.org/licenses/>.
+
+## -*- texinfo -*-
+## @deftypefn {Function File}  {[@var{a}, @dots{}] =} textread (@var{filename})
+## @deftypefnx {Function File}  {[@var{a}, @dots{}] =} textread (@var{filename}, @var{format})
+## @deftypefnx {Function File} {[@var{a}, @dots{}] =} textread (@var{filename}, @var{format}, @
+## @var{prop1}, @var{value1}, @dots{})
+## Read data from a text file.
+##
+## The file @var{filename} is read and parsed according to @var{format}. The
+## function behaves like @code{strread} except it works by parsing a file instead
+## of a string. See the documentation of @code{strread} for details.
+## @seealso{strread, load, dlmread, fscanf}
+## @end deftypefn
+
+function varargout = textread (filename, formatstr = "%f", varargin)
+  ## Check input
+  if (nargin < 1)
+    print_usage ();
+  endif
+  
+  if (!ischar (filename) || !ischar (filename))
+    error ("textread: first and second input arguments must be strings");
+  endif
+
+  ## Read file
+  fid = fopen (filename, "r");
+  if (fid == -1)
+    error ("textread: could not open '%s' for reading", filename);
+  endif
+  
+  str = char (fread (fid, "char")');
+  fclose (fid);
+  
+  ## Call strread to make it do the real work
+  [varargout{1:max (nargout, 1)}] = strread (str, formatstr, varargin {:});
+endfunction

From shaiay at gmail.com  Tue Oct 20 03:39:56 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Tue, 20 Oct 2009 10:39:56 +0200
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <128f38bd0910190108j3def3af4o41d764624fd6a826@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>
	<4AD4C469.1080604@isl.stanford.edu> <19162.809.445103.387353@hugo.lan>
	<4ADA9156.30800@isl.stanford.edu>
	<420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>
	<128f38bd0910180102k68e2e278sf296f1064d376b1d@mail.gmail.com>
	<420fb9e60910181330k7928f321h7c3d2cd5f71628e@mail.gmail.com>
	<128f38bd0910190108j3def3af4o41d764624fd6a826@mail.gmail.com>
Message-ID: <420fb9e60910200139q46cee1bdk5f34422ba40069c4@mail.gmail.com>

On Mon, Oct 19, 2009 at 10:08 AM, Michael Goffioul
<michael.goffioul at gmail.com> wrote:
> On Sun, Oct 18, 2009 at 9:30 PM, Shai Ayal <shaiay at gmail.com> wrote:
>> Can this be done w/o additional work in the renderer -- i.e. only by
>> using the new PS macros in the modified gl2ps, or do you need to
>> implement some sort of a simple TeX interpreter as you do in
>> SimpleTextEngine.java?
>
> I guess it is imaginable to process something like:
> a_{12}+x^2*\theta_1 entirely in PS, but I guess it can be a little
> bit tedious. What I did is to re-use the visitor pattern I had implemented
> for normal rendering to split a string into elements and add the PS code
> to render those elements

I agree it doesn't make sense to try and implement this in PS.
There was also talk once of rendering text with LaTeX (I think Michael
wrote the text rendering engine anticipating we would use LaTeX to
produce bitmaps).

In any case there is still quite an amount of work to be done before
we have TeX support. I suggest the changeset be committed meanwhile.

Shai

From highegg at gmail.com  Tue Oct 20 04:13:14 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 20 Oct 2009 11:13:14 +0200
Subject: FYI: bsxfun optimized
Message-ID: <69d8d540910200213kea53801i3a1aa54ca910347f@mail.gmail.com>

hi all,
I optimized bsxfun (binary singleton expansion function applier) to be
faster when some common built-in functions are given. The bsxfun
operations are also available from liboctave as bsxfun_add (NDArray,
NDArray) etc.
http://hg.savannah.gnu.org/hgweb/octave/rev/26abff55f6fe

The following benchmark illustrates the speed-up (set n to suitable value)

n = 200;
i = ones (1, n);
a = rand (n, n, 1);
b = rand (n, n, n);
tic; bsxfun (@plus, a, b); toc
a = rand (n, 1, 1);
tic; bsxfun (@minus, a, b); toc
a = rand (1, n, 1);
tic; bsxfun (@times, a, b); toc

a = rand (n, n, 1);
b = rand (1, n, n);
tic; bsxfun (@rdivide, a, b); toc

b = rand (1, 1, n);
tic; bsxfun (@lt, a, b); toc

a = rand (2, n, n/2, n); # heavily multi-dim
b = rand (1, 1, n/2, n);
tic; bsxfun (@gt, a, b); toc

on a Core 2 Duo @ 2.83 GHz, g++ -O3 -march=native,
with a recent tip, I get:

Elapsed time is 0.697962 seconds.
Elapsed time is 0.645682 seconds.
Elapsed time is 0.709098 seconds.
Elapsed time is 0.720162 seconds.
Elapsed time is 0.608029 seconds.
Elapsed time is 24.2397 seconds.

with the new patch, I got

Elapsed time is 0.0434361 seconds.
Elapsed time is 0.048116 seconds.
Elapsed time is 0.0503559 seconds.
Elapsed time is 0.0644929 seconds.
Elapsed time is 0.0164821 seconds.
Elapsed time is 0.098119 seconds.

an interesting third option is a naive bsxfun replacement, which just
spreads the arrays to a common size and then applies the operator:

function r = bsxfun (op, x, y)
  nd = max (ndims (x), ndims (y));
  xidx = yidx = repmat({':'}, 1, nd);
  for i = 1:nd
    sx = size (x, i);
    sy = size (y, i);
    if (sx == 1)
      xidx{i} = ones (1, sy);
    endif
    if (sy == 1)
      yidx{i} = ones (1, sx);
    endif
  endfor

  r = op (x(xidx{:}), y(yidx{:}));
endfunction

with this replacement, I get:

Elapsed time is 0.0920911 seconds.
Elapsed time is 0.098748 seconds.
Elapsed time is 0.097363 seconds.
Elapsed time is 0.137549 seconds.
Elapsed time is 0.109806 seconds.
Elapsed time is 0.18157 seconds.

of course, the memory consumption will be up to 3x as big, but in
general these are closer to their optimized counterparts than the
original code.

Currently, only some common operations are covered, such as the basic
operations +,-,*,/, relations =,!=,<,>,<=,>= and pairwise min, max are
covered, and the optimizations only work if the operation is
homogeneous. More can be added if there is interest.

One further question that remains is whether to retain the old code,
or replace it with the spread-and-apply approach above.
The old code is more memory-efficient (it creates the result array and
then updates it), but apparently slower, sometimes significantly.
Opinions?

enjoy

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

From soren at hauberg.org  Tue Oct 20 04:57:56 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Tue, 20 Oct 2009 11:57:56 +0200
Subject: FYI: bsxfun optimized
In-Reply-To: <69d8d540910200213kea53801i3a1aa54ca910347f@mail.gmail.com>
References: <69d8d540910200213kea53801i3a1aa54ca910347f@mail.gmail.com>
Message-ID: <1256032677.4689.3.camel@sh-t400>

tir, 20 10 2009 kl. 11:13 +0200, skrev Jaroslav Hajek:
> One further question that remains is whether to retain the old code,
> or replace it with the spread-and-apply approach above.
> The old code is more memory-efficient (it creates the result array and
> then updates it), but apparently slower, sometimes significantly.
> Opinions?

Cool! I love these X-has-been-optimised mails :-)

Would it be possible to test if the system has enough memory to use the
spread-and-apply approach before hand? If so, then you could do
spread-and-apply when the memory is available and fall back to the
memory-efficient approach otherwise. the down-side is of course that
this gives more code to maintain.

S?ren


From highegg at gmail.com  Tue Oct 20 05:10:36 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 20 Oct 2009 12:10:36 +0200
Subject: FYI: bsxfun optimized
In-Reply-To: <1256032677.4689.3.camel@sh-t400>
References: <69d8d540910200213kea53801i3a1aa54ca910347f@mail.gmail.com>
	<1256032677.4689.3.camel@sh-t400>
Message-ID: <69d8d540910200310o79aca63bmfd598dc2c94987b3@mail.gmail.com>

On Tue, Oct 20, 2009 at 11:57 AM, S?ren Hauberg <soren at hauberg.org> wrote:
> tir, 20 10 2009 kl. 11:13 +0200, skrev Jaroslav Hajek:
>> One further question that remains is whether to retain the old code,
>> or replace it with the spread-and-apply approach above.
>> The old code is more memory-efficient (it creates the result array and
>> then updates it), but apparently slower, sometimes significantly.
>> Opinions?
>
> Cool! I love these X-has-been-optimised mails :-)
>
> Would it be possible to test if the system has enough memory to use the
> spread-and-apply approach before hand? If so, then you could do
> spread-and-apply when the memory is available and fall back to the
> memory-efficient approach otherwise. the down-side is of course that
> this gives more code to maintain.
>
> S?ren
>
>

That's an interesting idea; however, I have no idea how to check for
available memory, and I doubt there's a simple portable way. In fact I
think most systems, including Linux, hide the physical memory details
pretty well from applications. OTOH, it certainly is possible - cf.
GNOME system monitor...

In any case, I'll repeat my usual statement that if you're really
short of memory, Octave (or Matlab, for that matter) isn't a good
language to use at all, like probably any language that lacks a
pass-by-reference semantics (even though otherwise it's so cool
there's no mutable/immutable mess compared to, say, Python).

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


From highegg at gmail.com  Tue Oct 20 05:45:56 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 20 Oct 2009 12:45:56 +0200
Subject: FYI: bsxfun optimized
In-Reply-To: <69d8d540910200213kea53801i3a1aa54ca910347f@mail.gmail.com>
References: <69d8d540910200213kea53801i3a1aa54ca910347f@mail.gmail.com>
Message-ID: <69d8d540910200345o7a60d417m233921b22cf4df27@mail.gmail.com>

On Tue, Oct 20, 2009 at 11:13 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
> hi all,
> I optimized bsxfun (binary singleton expansion function applier) to be
> faster when some common built-in functions are given. The bsxfun
> operations are also available from liboctave as bsxfun_add (NDArray,
> NDArray) etc.
> http://hg.savannah.gnu.org/hgweb/octave/rev/26abff55f6fe
>
> The following benchmark illustrates the speed-up (set n to suitable value)
>
> n = 200;
> i = ones (1, n);
> a = rand (n, n, 1);
> b = rand (n, n, n);
> tic; bsxfun (@plus, a, b); toc
> a = rand (n, 1, 1);
> tic; bsxfun (@minus, a, b); toc
> a = rand (1, n, 1);
> tic; bsxfun (@times, a, b); toc
>
> a = rand (n, n, 1);
> b = rand (1, n, n);
> tic; bsxfun (@rdivide, a, b); toc
>
> b = rand (1, 1, n);
> tic; bsxfun (@lt, a, b); toc
>
> a = rand (2, n, n/2, n); # heavily multi-dim
> b = rand (1, 1, n/2, n);
> tic; bsxfun (@gt, a, b); toc
>
> on a Core 2 Duo @ 2.83 GHz, g++ -O3 -march=native,
> with a recent tip, I get:
>
> Elapsed time is 0.697962 seconds.
> Elapsed time is 0.645682 seconds.
> Elapsed time is 0.709098 seconds.
> Elapsed time is 0.720162 seconds.
> Elapsed time is 0.608029 seconds.
> Elapsed time is 24.2397 seconds.
>
> with the new patch, I got
>
> Elapsed time is 0.0434361 seconds.
> Elapsed time is 0.048116 seconds.
> Elapsed time is 0.0503559 seconds.
> Elapsed time is 0.0644929 seconds.
> Elapsed time is 0.0164821 seconds.
> Elapsed time is 0.098119 seconds.
>
> an interesting third option is a naive bsxfun replacement, which just
> spreads the arrays to a common size and then applies the operator:
>
> function r = bsxfun (op, x, y)
> ?nd = max (ndims (x), ndims (y));
> ?xidx = yidx = repmat({':'}, 1, nd);
> ?for i = 1:nd
> ? ?sx = size (x, i);
> ? ?sy = size (y, i);
> ? ?if (sx == 1)
> ? ? ?xidx{i} = ones (1, sy);
> ? ?endif
> ? ?if (sy == 1)
> ? ? ?yidx{i} = ones (1, sx);
> ? ?endif
> ?endfor
>
> ?r = op (x(xidx{:}), y(yidx{:}));
> endfunction
>
> with this replacement, I get:
>
> Elapsed time is 0.0920911 seconds.
> Elapsed time is 0.098748 seconds.
> Elapsed time is 0.097363 seconds.
> Elapsed time is 0.137549 seconds.
> Elapsed time is 0.109806 seconds.
> Elapsed time is 0.18157 seconds.
>
> of course, the memory consumption will be up to 3x as big, but in
> general these are closer to their optimized counterparts than the
> original code.
>
> Currently, only some common operations are covered, such as the basic
> operations +,-,*,/, relations =,!=,<,>,<=,>= and pairwise min, max are
> covered, and the optimizations only work if the operation is
> homogeneous. More can be added if there is interest.
>
> One further question that remains is whether to retain the old code,
> or replace it with the spread-and-apply approach above.
> The old code is more memory-efficient (it creates the result array and
> then updates it), but apparently slower, sometimes significantly.
> Opinions?
>
> enjoy
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>

Btw, as an example of usage, I optimized the "center" function - which
removes the means from an array along a specified dimension, and is a
typical example of a bsxfun-like operation...
http://hg.savannah.gnu.org/hgweb/octave/rev/fb3543975ed9

benchmark:

n = 4000;
a = rand (n);
tic; center (a); toc
tic; center (a(:)); toc

old:

Elapsed time is 0.192539 seconds.
Elapsed time is 0.210404 seconds.
Elapsed time is 0.114803 seconds.

new:
Elapsed time is 0.102689 seconds.
Elapsed time is 0.116499 seconds.
Elapsed time is 0.113716 seconds.

the vector case was already optimized before. In the matrix cases, the
expected factor ~2 speed-up is seen (and it saves one temporary
array).

enjoy

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


From highegg at gmail.com  Tue Oct 20 06:45:58 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 20 Oct 2009 13:45:58 +0200
Subject: 'strread' and 'textread'
In-Reply-To: <1255976905.4518.26.camel@sh-t400>
References: <1255976905.4518.26.camel@sh-t400>
Message-ID: <69d8d540910200445g6c4c2408wf6a21c62ddf190ab@mail.gmail.com>

On Mon, Oct 19, 2009 at 8:28 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> Hi All
>
> A bug that wasn't easy to fix was reported against the implementation of
> 'textread' available in the 'io' package at the Octave-Forge mailing
> list. Eric Chassande-Mottin volunteered to provide a Matlab compatible
> m-file implementation of the function, that Jaroslav and myself then
> vectorised.
>
> Since 'textread' (and its string counterpart 'strread') are part of core
> Matlab, I thought I'd suggest the code for inclusion in core Octave
> instead of the 'io' package. Attached is a changeset that adds the two
> functions.
>
> S?ren
>

I pushed the changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/31a22d48f41f

I added two more modifications:
first, doing
  str = char (fread (fid, "char")');
in textread is really wasteful; by default fread returns doubles.
Besides, it often fails since the results are often signed (I think
it's platform-dependent). I replaced it with
  str = fread (fid, "char=>char").';

Second, I believe the following segment in strread was wrong:

  ## Remove header
  if (header_skip > 0)
    e = find (str == "\n", header_skip);
    if (length (e) >= header_skip)
      str = str (e (end)+1:end);
    else
      ## We don't have enough data so we discard it all
      str = "";
    endif
  endif

because it doesn't handle all CR, LF and CRLF endings. Handling CR and
LF is simple, but CRLF spoil the picture. I see little need for the
headerlines option in strread (and Matlab doesn't provide it either),
so I removed it and moved the support directly to textread, where
fskipl is called to do the job (and fskipl has the advantage that it
can skip lines without actually reading them into memory).

comments, suggestions?

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


From soren at hauberg.org  Tue Oct 20 06:56:48 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Tue, 20 Oct 2009 13:56:48 +0200
Subject: 'strread' and 'textread'
In-Reply-To: <69d8d540910200445g6c4c2408wf6a21c62ddf190ab@mail.gmail.com>
References: <1255976905.4518.26.camel@sh-t400>
	<69d8d540910200445g6c4c2408wf6a21c62ddf190ab@mail.gmail.com>
Message-ID: <1256039808.4689.10.camel@sh-t400>

tir, 20 10 2009 kl. 13:45 +0200, skrev Jaroslav Hajek:
> I pushed the changeset:
> http://hg.savannah.gnu.org/hgweb/octave/rev/31a22d48f41f

Thanks

> I added two more modifications:
> first, doing
>   str = char (fread (fid, "char")');
> in textread is really wasteful; by default fread returns doubles.
> Besides, it often fails since the results are often signed (I think
> it's platform-dependent). I replaced it with
>   str = fread (fid, "char=>char").';

Much better; thanks.

> Second, I believe the following segment in strread was wrong:
> 
>   ## Remove header
>   if (header_skip > 0)
>     e = find (str == "\n", header_skip);
>     if (length (e) >= header_skip)
>       str = str (e (end)+1:end);
>     else
>       ## We don't have enough data so we discard it all
>       str = "";
>     endif
>   endif
> 
> because it doesn't handle all CR, LF and CRLF endings. Handling CR and
> LF is simple, but CRLF spoil the picture.

I do all my work on Unix so I don't know much (anything) about the
alternative operating systems, but I get the impression that these days
a '\n' is always present when a line ends. Sometimes you just also get
extra characters like '\r'. So, I think the above code should remove the
first lines just fine, but it may leave spurious '\r' (or similar)
characters. This shouldn't matter, though, as the following code splits
into words by any white-space.

>  I see little need for the
> headerlines option in strread (and Matlab doesn't provide it either),
> so I removed it and moved the support directly to textread, where
> fskipl is called to do the job (and fskipl has the advantage that it
> can skip lines without actually reading them into memory).

I agree that there is little need for the option in 'strread', so I
think your change is just fine.

S?ren


From highegg at gmail.com  Tue Oct 20 07:05:48 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 20 Oct 2009 14:05:48 +0200
Subject: 'strread' and 'textread'
In-Reply-To: <1256039808.4689.10.camel@sh-t400>
References: <1255976905.4518.26.camel@sh-t400>
	<69d8d540910200445g6c4c2408wf6a21c62ddf190ab@mail.gmail.com>
	<1256039808.4689.10.camel@sh-t400>
Message-ID: <69d8d540910200505j31326ees7c9f83bcae0e30a6@mail.gmail.com>

On Tue, Oct 20, 2009 at 1:56 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> tir, 20 10 2009 kl. 13:45 +0200, skrev Jaroslav Hajek:
>> I pushed the changeset:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/31a22d48f41f
>
> Thanks
>
>> I added two more modifications:
>> first, doing
>> ? str = char (fread (fid, "char")');
>> in textread is really wasteful; by default fread returns doubles.
>> Besides, it often fails since the results are often signed (I think
>> it's platform-dependent). I replaced it with
>> ? str = fread (fid, "char=>char").';
>
> Much better; thanks.
>
>> Second, I believe the following segment in strread was wrong:
>>
>> ? ## Remove header
>> ? if (header_skip > 0)
>> ? ? e = find (str == "\n", header_skip);
>> ? ? if (length (e) >= header_skip)
>> ? ? ? str = str (e (end)+1:end);
>> ? ? else
>> ? ? ? ## We don't have enough data so we discard it all
>> ? ? ? str = "";
>> ? ? endif
>> ? endif
>>
>> because it doesn't handle all CR, LF and CRLF endings. Handling CR and
>> LF is simple, but CRLF spoil the picture.
>
> I do all my work on Unix so I don't know much (anything) about the
> alternative operating systems, but I get the impression that these days
> a '\n' is always present when a line ends. Sometimes you just also get
> extra characters like '\r'. So, I think the above code should remove the
> first lines just fine, but it may leave spurious '\r' (or similar)
> characters. This shouldn't matter, though, as the following code splits
> into words by any white-space.
>

I think this is only true if you open the file in text mode (by
fopen), which textread doesn't. Surely it could, but does that work
well with fread? (I'm not sure). Alas, I work exclusively on
GNU/Linux, so I can't test either.
In any case, handling the option in textread using fskipl is both
simpler and faster...

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


From individ at acc.umu.se  Tue Oct 20 07:12:04 2009
From: individ at acc.umu.se (David Grundberg)
Date: Tue, 20 Oct 2009 14:12:04 +0200
Subject: error: bsxfun-decl.h: No such file or directory
Message-ID: <4ADDA914.8060103@acc.umu.se>

Hello all,

I'm trying to build Octave from the tip, but there seems to be a file 
missing:

make -C liboctave all
make[2]: Entering directory `/scratch/octaveorgvpath/liboctave'
g++ -c -I/Home/staff/davidg/octave-patching/dependencies/UFconfig/ 
-I/usr/include/freetype2 -fPIC -I. 
-I/Home/staff/davidg/octave-patching/octaveorg/liboctave -I.. 
-I../liboctave -I../src -I../libcruft/misc 
-I/Home/staff/davidg/octave-patching/octaveorg 
-I/Home/staff/davidg/octave-patching/octaveorg/liboctave 
-I/Home/staff/davidg/octave-patching/octaveorg/src 
-I/Home/staff/davidg/octave-patching/octaveorg/libcruft/misc 
-DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -Wformat -g 
-O2 -I/usr/include/freetype2 -pthread 
/Home/staff/davidg/octave-patching/octaveorg/liboctave/lo-specfun.cc -o 
pic/lo-specfun.o
In file included from 
/Home/staff/davidg/octave-patching/octaveorg/liboctave/intNDArray.h:27,
from /Home/staff/davidg/octave-patching/octaveorg/liboctave/dNDArray.h:29,
from 
/Home/staff/davidg/octave-patching/octaveorg/liboctave/lo-specfun.cc:33:
/Home/staff/davidg/octave-patching/octaveorg/liboctave/boolNDArray.h:30:25: 
error: bsxfun-decl.h: No such file or directory
In file included from 
/Home/staff/davidg/octave-patching/octaveorg/liboctave/intNDArray.h:27,
from /Home/staff/davidg/octave-patching/octaveorg/liboctave/dNDArray.h:29,
from 
/Home/staff/davidg/octave-patching/octaveorg/liboctave/lo-specfun.cc:33:
/Home/staff/davidg/octave-patching/octaveorg/liboctave/boolNDArray.h:142: 
error: expected constructor, destructor, or type conversion before ?(? token
/Home/staff/davidg/octave-patching/octaveorg/liboctave/boolNDArray.h:143: 
error: expected constructor, destructor, or type conversion before ?(? token
In file included from 
/Home/staff/davidg/octave-patching/octaveorg/liboctave/lo-specfun.cc:33:
/Home/staff/davidg/octave-patching/octaveorg/liboctave/dNDArray.h:199: 
error: expected identifier before ?)? token
/Home/staff/davidg/octave-patching/octaveorg/liboctave/dNDArray.h:200: 
error: expected constructor, destructor, or type conversion before 
?BSXFUN_STDREL_DECLS?
make[2]: *** [pic/lo-specfun.o] Error 1
make[2]: Leaving directory `/scratch/octaveorgvpath/liboctave'
make[1]: *** [liboctave] Error 2
make[1]: Leaving directory `/scratch/octaveorgvpath'
make: *** [all] Error 2


/David

From highegg at gmail.com  Tue Oct 20 08:46:41 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 20 Oct 2009 15:46:41 +0200
Subject: error: bsxfun-decl.h: No such file or directory
In-Reply-To: <4ADDA914.8060103@acc.umu.se>
References: <4ADDA914.8060103@acc.umu.se>
Message-ID: <69d8d540910200646t791d2fb9m4d6d0e4435079446@mail.gmail.com>

On Tue, Oct 20, 2009 at 2:12 PM, David Grundberg <individ at acc.umu.se> wrote:
> Hello all,
>
> I'm trying to build Octave from the tip, but there seems to be a file
> missing:
>
> make -C liboctave all
> make[2]: Entering directory `/scratch/octaveorgvpath/liboctave'
> g++ -c -I/Home/staff/davidg/octave-patching/dependencies/UFconfig/
> -I/usr/include/freetype2 -fPIC -I.
> -I/Home/staff/davidg/octave-patching/octaveorg/liboctave -I.. -I../liboctave
> -I../src -I../libcruft/misc -I/Home/staff/davidg/octave-patching/octaveorg
> -I/Home/staff/davidg/octave-patching/octaveorg/liboctave
> -I/Home/staff/davidg/octave-patching/octaveorg/src
> -I/Home/staff/davidg/octave-patching/octaveorg/libcruft/misc -DHAVE_CONFIG_H
> -mieee-fp -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2
> -I/usr/include/freetype2 -pthread
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/lo-specfun.cc -o
> pic/lo-specfun.o
> In file included from
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/intNDArray.h:27,
> from /Home/staff/davidg/octave-patching/octaveorg/liboctave/dNDArray.h:29,
> from
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/lo-specfun.cc:33:
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/boolNDArray.h:30:25:
> error: bsxfun-decl.h: No such file or directory
> In file included from
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/intNDArray.h:27,
> from /Home/staff/davidg/octave-patching/octaveorg/liboctave/dNDArray.h:29,
> from
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/lo-specfun.cc:33:
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/boolNDArray.h:142:
> error: expected constructor, destructor, or type conversion before ?(? token
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/boolNDArray.h:143:
> error: expected constructor, destructor, or type conversion before ?(? token
> In file included from
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/lo-specfun.cc:33:
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/dNDArray.h:199:
> error: expected identifier before ?)? token
> /Home/staff/davidg/octave-patching/octaveorg/liboctave/dNDArray.h:200:
> error: expected constructor, destructor, or type conversion before
> ?BSXFUN_STDREL_DECLS?
> make[2]: *** [pic/lo-specfun.o] Error 1
> make[2]: Leaving directory `/scratch/octaveorgvpath/liboctave'
> make[1]: *** [liboctave] Error 2
> make[1]: Leaving directory `/scratch/octaveorgvpath'
> make: *** [all] Error 2
>
>
> /David
>

Damn, I knew it. Sorry. Please pull again.
http://hg.savannah.gnu.org/hgweb/octave/rev/7bda650b691a

regards

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


From individ at acc.umu.se  Tue Oct 20 10:28:00 2009
From: individ at acc.umu.se (David Grundberg)
Date: Tue, 20 Oct 2009 17:28:00 +0200
Subject: error: bsxfun-decl.h: No such file or directory
In-Reply-To: <69d8d540910200646t791d2fb9m4d6d0e4435079446@mail.gmail.com>
References: <4ADDA914.8060103@acc.umu.se>
	<69d8d540910200646t791d2fb9m4d6d0e4435079446@mail.gmail.com>
Message-ID: <4ADDD700.8010902@acc.umu.se>

Jaroslav Hajek wrote:
> On Tue, Oct 20, 2009 at 2:12 PM, David Grundberg <individ at acc.umu.se> wrote:
>   
>> Hello all,
>>
>> I'm trying to build Octave from the tip, but there seems to be a file
>> missing:
>>
>>     
>
> Damn, I knew it. Sorry. Please pull again.
> http://hg.savannah.gnu.org/hgweb/octave/rev/7bda650b691a
>
> regards
>
>   

Thanks!



From godfrey at isl.stanford.edu  Tue Oct 20 12:00:05 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Tue, 20 Oct 2009 10:00:05 -0700
Subject: FYI: bsxfun optimized
In-Reply-To: <69d8d540910200310o79aca63bmfd598dc2c94987b3@mail.gmail.com>
References: <69d8d540910200213kea53801i3a1aa54ca910347f@mail.gmail.com>	<1256032677.4689.3.camel@sh-t400>
	<69d8d540910200310o79aca63bmfd598dc2c94987b3@mail.gmail.com>
Message-ID: <4ADDEC95.4000801@isl.stanford.edu>

On 10/20/2009 03:10 AM, Jaroslav Hajek wrote:
> In fact I
> think most systems, including Linux, hide the physical memory details
> pretty well from applications. OTOH, it certainly is possible - cf.
> GNOME system monitor...
>    
On Linux systems cat /proc/meminfo tells you quite
a lot.
> In any case, I'll repeat my usual statement that if you're really
> short of memory, Octave (or Matlab, for that matter) isn't a good
> language to use at all, like probably any language that lacks a
> pass-by-reference semantics (even though otherwise it's so cool
> there's no mutable/immutable mess compared to, say, Python).
>    
Agreed.  In any case most systems these days provide,
or at least allow large virtual address space so the only
problem is excessive swapping due to limited real memory.
Real memory is cheap these days...



From godfrey at isl.stanford.edu  Tue Oct 20 12:03:20 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Tue, 20 Oct 2009 10:03:20 -0700
Subject: hardcopy support for gl-render and the fltk_backend
In-Reply-To: <420fb9e60910200139q46cee1bdk5f34422ba40069c4@mail.gmail.com>
References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com>	
	<4AD4C469.1080604@isl.stanford.edu>
	<19162.809.445103.387353@hugo.lan>	
	<4ADA9156.30800@isl.stanford.edu>	
	<420fb9e60910172138i5351c339xab22c1a2ca5e5c6d@mail.gmail.com>	
	<128f38bd0910180102k68e2e278sf296f1064d376b1d@mail.gmail.com>	
	<420fb9e60910181330k7928f321h7c3d2cd5f71628e@mail.gmail.com>	
	<128f38bd0910190108j3def3af4o41d764624fd6a826@mail.gmail.com>
	<420fb9e60910200139q46cee1bdk5f34422ba40069c4@mail.gmail.com>
Message-ID: <4ADDED58.5020804@isl.stanford.edu>

On 10/20/2009 01:39 AM, Shai Ayal wrote:
> In any case there is still quite an amount of work to be done before
> we have TeX support. I suggest the changeset be committed meanwhile.
>    
I agree with this.  There is a lot to use and test in this update.
The TeX/LaTeX feature will take some thought and time to
implement.  I would encourage some careful thought about how to
do this right before any "quick fix."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091020/c2a0fcff/attachment.html 

From individ at acc.umu.se  Wed Oct 21 03:25:39 2009
From: individ at acc.umu.se (David Grundberg)
Date: Wed, 21 Oct 2009 10:25:39 +0200
Subject: Build fixes
Message-ID: <4ADEC583.8050702@acc.umu.se>

Hi,

I had to make some changes to build Octave. The changes regard ARPACK, 
UMFPACK, SparseCX and QHULL.

David
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: buildfixes.changeset
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091021/4073d71b/attachment.ksh 

From highegg at gmail.com  Wed Oct 21 05:38:24 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 21 Oct 2009 12:38:24 +0200
Subject: improving error messages?
Message-ID: <69d8d540910210338y7296f901n9f4a56ccbaaa4f7b@mail.gmail.com>

hi,

I'm thinking about possible way to improve some error messages. The problem:
It is a good custom to prefix an error message with the name of the
originating function.
The problem is that some messages originate from procedures that have
no information about the invoking procedure.
In particular, this concerns functions from liboctave. Some of these
simply assume the calling function (e.g. sub2ind),
use something general (like "A(I):"), or use nothing (idx_vector).

cf. this:
octave:1> cellslices (1:3, 1, 4)
error: A(I): Index exceeds matrix dimension.

the problem is that the message doesn't show it originated in
"cellslices". This is primarily because Array<T>::index, which throws
it, doesn't know where it's being called from. Even though a traceback
will show the line number, if this occurs within a script, an user may
be easily confused.

Another instance of the same problem, within the interpreter, are
functions like octave_value::int_value, which gripe about "conversion
failed", but don't show the calling function.
Basically, there are three existing approaches currently in use to
face the problem:

1. ignore it
2. check for the error and display a supplemental message (on a new
line) with a correct prefix
3. try to pass the name down the call chain

1 is done for liboctave, as explained. 2 is used by some functions, e.g.
octave:1> any(1, 1.5)
error: conversion of 1.5 to int value failed
error: any: expecting dimension argument to be an integer

the problem is that this duplicates some information and requires a
lot of checking.
Approach 3 is used by some of the gripe_xxx functions. Still, it is
not reasonable to pass the name everywhere, especially to liboctave.

Looking for a relatively simple solution, I thought that error handler
simply can optionally query the current function name and insert it
into the message.
Since a lot of functions already do it in the first place, it can
first check whether the prefix is already there.

I ended up with the attached patch. This seems to mostly solve my problems:

octave:1> cellslices (1:3, 1, 4)
error: cellslices: A(I): Index exceeds matrix dimension.
octave:1> any(1, 1.5)
error: any: conversion of 1.5 to int value failed
error: any: expecting dimension argument to be an integer

I know this is no candidate for the best software design award, but it
works and is a relatively harmless change...

Comments?

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errors.diff
Type: text/x-patch
Size: 5329 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091021/4b28d96f/attachment.bin 

From soren at hauberg.org  Wed Oct 21 05:48:56 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Wed, 21 Oct 2009 12:48:56 +0200
Subject: improving error messages?
In-Reply-To: <69d8d540910210338y7296f901n9f4a56ccbaaa4f7b@mail.gmail.com>
References: <69d8d540910210338y7296f901n9f4a56ccbaaa4f7b@mail.gmail.com>
Message-ID: <1256122136.11691.8.camel@sh-t400>

ons, 21 10 2009 kl. 12:38 +0200, skrev Jaroslav Hajek:
> I ended up with the attached patch. This seems to mostly solve my problems:
> 
> octave:1> cellslices (1:3, 1, 4)
> error: cellslices: A(I): Index exceeds matrix dimension.
> octave:1> any(1, 1.5)
> error: any: conversion of 1.5 to int value failed
> error: any: expecting dimension argument to be an integer
> 
> I know this is no candidate for the best software design award, but it
> works and is a relatively harmless change...
> 
> Comments?

Funny! I was thinking about the same problem just a few days ago, and I
arrived at the same solution. One question, though:

Let's say I'm developing a function 'A' that calls a bunch of other
functions, i.e.

  function A ()
    ...
    B ();
    ...
  endfunction

what then happens if 'B' raises an error? Will I then get an error
message from 'A' instead? This could potentially make it harder to
develop functions or am I missing something?

S?ren


From highegg at gmail.com  Wed Oct 21 05:57:42 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 21 Oct 2009 12:57:42 +0200
Subject: improving error messages?
In-Reply-To: <1256122136.11691.8.camel@sh-t400>
References: <69d8d540910210338y7296f901n9f4a56ccbaaa4f7b@mail.gmail.com>
	<1256122136.11691.8.camel@sh-t400>
Message-ID: <69d8d540910210357n11cc45b1xddb934c5eef61c52@mail.gmail.com>

On Wed, Oct 21, 2009 at 12:48 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> ons, 21 10 2009 kl. 12:38 +0200, skrev Jaroslav Hajek:
>> I ended up with the attached patch. This seems to mostly solve my problems:
>>
>> octave:1> cellslices (1:3, 1, 4)
>> error: cellslices: A(I): Index exceeds matrix dimension.
>> octave:1> any(1, 1.5)
>> error: any: conversion of 1.5 to int value failed
>> error: any: expecting dimension argument to be an integer
>>
>> I know this is no candidate for the best software design award, but it
>> works and is a relatively harmless change...
>>
>> Comments?
>
> Funny! I was thinking about the same problem just a few days ago, and I
> arrived at the same solution. One question, though:
>
> Let's say I'm developing a function 'A' that calls a bunch of other
> functions, i.e.
>
> ?function A ()
> ? ?...
> ? ?B ();
> ? ?...
> ?endfunction
>
> what then happens if 'B' raises an error? Will I then get an error
> message from 'A' instead? This could potentially make it harder to
> develop functions or am I missing something?
>
> S?ren
>

No, you'll see a message from the innermost function that raised the
error, be it B or something else. And it only applies to errors
originating from liboctave exceptions (which generally have no way of
knowing who called them) or those generated by the C++ function
error_with_cfn (or error_with_id_cfn). So most user-generated errors
are unaffected.

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


From soren at hauberg.org  Wed Oct 21 06:02:36 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Wed, 21 Oct 2009 13:02:36 +0200
Subject: improving error messages?
In-Reply-To: <69d8d540910210357n11cc45b1xddb934c5eef61c52@mail.gmail.com>
References: <69d8d540910210338y7296f901n9f4a56ccbaaa4f7b@mail.gmail.com>
	<1256122136.11691.8.camel@sh-t400>
	<69d8d540910210357n11cc45b1xddb934c5eef61c52@mail.gmail.com>
Message-ID: <1256122956.11691.15.camel@sh-t400>

ons, 21 10 2009 kl. 12:57 +0200, skrev Jaroslav Hajek:
> No, you'll see a message from the innermost function that raised the
> error, be it B or something else. And it only applies to errors
> originating from liboctave exceptions (which generally have no way of
> knowing who called them) or those generated by the C++ function
> error_with_cfn (or error_with_id_cfn). So most user-generated errors
> are unaffected.

Okay, that makes sense.

Thanks
S?ren


From jwe at octave.org  Wed Oct 21 06:20:01 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 21 Oct 2009 07:20:01 -0400
Subject: improving error messages?
In-Reply-To: <69d8d540910210357n11cc45b1xddb934c5eef61c52@mail.gmail.com>
References: <69d8d540910210338y7296f901n9f4a56ccbaaa4f7b@mail.gmail.com>
	<1256122136.11691.8.camel@sh-t400>
	<69d8d540910210357n11cc45b1xddb934c5eef61c52@mail.gmail.com>
Message-ID: <19166.61025.98847.756384@segfault.lan>

On 21-Oct-2009, Jaroslav Hajek wrote:

| On Wed, Oct 21, 2009 at 12:48 PM, S?ren Hauberg <soren at hauberg.org> wrote:
| > ons, 21 10 2009 kl. 12:38 +0200, skrev Jaroslav Hajek:
| >> I ended up with the attached patch. This seems to mostly solve my problems:
| >>
| >> octave:1> cellslices (1:3, 1, 4)
| >> error: cellslices: A(I): Index exceeds matrix dimension.
| >> octave:1> any(1, 1.5)
| >> error: any: conversion of 1.5 to int value failed
| >> error: any: expecting dimension argument to be an integer
| >>
| >> I know this is no candidate for the best software design award, but it
| >> works and is a relatively harmless change...
| >>
| >> Comments?
| >
| > Funny! I was thinking about the same problem just a few days ago, and I
| > arrived at the same solution. One question, though:
| >
| > Let's say I'm developing a function 'A' that calls a bunch of other
| > functions, i.e.
| >
| > ?function A ()
| > ? ?...
| > ? ?B ();
| > ? ?...
| > ?endfunction
| >
| > what then happens if 'B' raises an error? Will I then get an error
| > message from 'A' instead? This could potentially make it harder to
| > develop functions or am I missing something?
| >
| > S?ren
| >
| 
| No, you'll see a message from the innermost function that raised the
| error, be it B or something else. And it only applies to errors
| originating from liboctave exceptions (which generally have no way of
| knowing who called them) or those generated by the C++ function
| error_with_cfn (or error_with_id_cfn). So most user-generated errors
| are unaffected.

I think I'd rather not have to remember when it is appropriate to call
error_with_cfn.  Maybe it would be better if we changed things so that
the error function always reported the calling function information,
and then changed our style to not include the function name as an
error message prefix?

jwe


From highegg at gmail.com  Wed Oct 21 06:36:47 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 21 Oct 2009 13:36:47 +0200
Subject: improving error messages?
In-Reply-To: <19166.61025.98847.756384@segfault.lan>
References: <69d8d540910210338y7296f901n9f4a56ccbaaa4f7b@mail.gmail.com>
	<1256122136.11691.8.camel@sh-t400>
	<69d8d540910210357n11cc45b1xddb934c5eef61c52@mail.gmail.com>
	<19166.61025.98847.756384@segfault.lan>
Message-ID: <69d8d540910210436v78657963uf7d272e6b6edb2ad@mail.gmail.com>

On Wed, Oct 21, 2009 at 1:20 PM, John W. Eaton <jwe at octave.org> wrote:
> On 21-Oct-2009, Jaroslav Hajek wrote:
>
> | On Wed, Oct 21, 2009 at 12:48 PM, S?ren Hauberg <soren at hauberg.org> wrote:
> | > ons, 21 10 2009 kl. 12:38 +0200, skrev Jaroslav Hajek:
> | >> I ended up with the attached patch. This seems to mostly solve my problems:
> | >>
> | >> octave:1> cellslices (1:3, 1, 4)
> | >> error: cellslices: A(I): Index exceeds matrix dimension.
> | >> octave:1> any(1, 1.5)
> | >> error: any: conversion of 1.5 to int value failed
> | >> error: any: expecting dimension argument to be an integer
> | >>
> | >> I know this is no candidate for the best software design award, but it
> | >> works and is a relatively harmless change...
> | >>
> | >> Comments?
> | >
> | > Funny! I was thinking about the same problem just a few days ago, and I
> | > arrived at the same solution. One question, though:
> | >
> | > Let's say I'm developing a function 'A' that calls a bunch of other
> | > functions, i.e.
> | >
> | > ?function A ()
> | > ? ?...
> | > ? ?B ();
> | > ? ?...
> | > ?endfunction
> | >
> | > what then happens if 'B' raises an error? Will I then get an error
> | > message from 'A' instead? This could potentially make it harder to
> | > develop functions or am I missing something?
> | >
> | > S?ren
> | >
> |
> | No, you'll see a message from the innermost function that raised the
> | error, be it B or something else. And it only applies to errors
> | originating from liboctave exceptions (which generally have no way of
> | knowing who called them) or those generated by the C++ function
> | error_with_cfn (or error_with_id_cfn). So most user-generated errors
> | are unaffected.
>
> I think I'd rather not have to remember when it is appropriate to call
> error_with_cfn.

It's simple: if you want the auto-prepending. That is, almost never in
normal code. For liboctave exceptions, it's done automatically in the
handler; otherwise, you want to call it in places which want to throw
a generic error for multiple built-in functions, such as various
octave_value::XXX_value extractors.

> Maybe it would be better if we changed things so that
> the error function always reported the calling function information,
> and then changed our style to not include the function name as an
> error message prefix?
>

Better, maybe. The point is that code gets more easily changed than
style :) Besides, doing that would probably require massive changes
all over the place. The final thing is that we would have to make it
quite smart; often the user wants to ignore helper or internal
functions that actually invoke the error, without the need to catch,
subst the prefix and rethrow...

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


From godfrey at isl.stanford.edu  Wed Oct 21 10:24:11 2009
From: godfrey at isl.stanford.edu (Michael D Godfrey)
Date: Wed, 21 Oct 2009 08:24:11 -0700
Subject: improving error messages?
In-Reply-To: <69d8d540910210338y7296f901n9f4a56ccbaaa4f7b@mail.gmail.com>
References: <69d8d540910210338y7296f901n9f4a56ccbaaa4f7b@mail.gmail.com>
Message-ID: <4ADF279B.1050503@isl.stanford.edu>

On 10/21/2009 03:38 AM, Jaroslav Hajek wrote:
> I know this is no candidate for the best software design award, but it
> works and is a relatively harmless change...
>
> Comments?
>    
Major improvement.  Forget the design award. It works much
better than the present code.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091021/4dbe7ade/attachment.html 

From soren at hauberg.org  Wed Oct 21 15:47:28 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Wed, 21 Oct 2009 22:47:28 +0200
Subject: Colormap demos?
Message-ID: <1256158048.4477.9.camel@sh-t400>

Hi All

I often have problems remembering how different colour maps work ("does
red mean a high or a low value?"), so I'd like to have an easy way of
visualising the maps. If I made a patch adding demos to the various
colour map functions ('jet', 'hsv', ...) that all do something like this

    ## Show the 'hsv' colormap as an image
        image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
        axis ([1, 64, 0, 1], "ticy", "xy")
        colormap hsv

would such a patch be accepted?

S?ren
        


From jwe at octave.org  Wed Oct 21 15:58:01 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 21 Oct 2009 16:58:01 -0400
Subject: Colormap demos?
In-Reply-To: <1256158048.4477.9.camel@sh-t400>
References: <1256158048.4477.9.camel@sh-t400>
Message-ID: <19167.30169.258037.977169@segfault.lan>

On 21-Oct-2009, S?ren Hauberg wrote:

| I often have problems remembering how different colour maps work ("does
| red mean a high or a low value?"), so I'd like to have an easy way of
| visualising the maps. If I made a patch adding demos to the various
| colour map functions ('jet', 'hsv', ...) that all do something like this
| 
|     ## Show the 'hsv' colormap as an image
|         image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
|         axis ([1, 64, 0, 1], "ticy", "xy")
|         colormap hsv
| 
| would such a patch be accepted?

I have no objection to additional graphics demos.

jwe


From soren at hauberg.org  Thu Oct 22 06:28:22 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Thu, 22 Oct 2009 13:28:22 +0200
Subject: Colormap demos?
In-Reply-To: <19167.30169.258037.977169@segfault.lan>
References: <1256158048.4477.9.camel@sh-t400>
	<19167.30169.258037.977169@segfault.lan>
Message-ID: <1256210902.4536.1.camel@sh-t400>

ons, 21 10 2009 kl. 16:58 -0400, skrev John W. Eaton:
> On 21-Oct-2009, S?ren Hauberg wrote:
> 
> | I often have problems remembering how different colour maps work ("does
> | red mean a high or a low value?"), so I'd like to have an easy way of
> | visualising the maps. If I made a patch adding demos to the various
> | colour map functions ('jet', 'hsv', ...) that all do something like this
> | 
> |     ## Show the 'hsv' colormap as an image
> |         image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
> |         axis ([1, 64, 0, 1], "ticy", "xy")
> |         colormap hsv
> | 
> | would such a patch be accepted?
> 
> I have no objection to additional graphics demos.

Then how about the attached changeset?

S?ren
-------------- next part --------------
# HG changeset patch
# User Soren Hauberg <hauberg at gmail.com>
# Date 1256210820 -7200
# Node ID 9357d0e3d5e0a623509a864c8e09717ebdf621f4
# Parent  584ca012b9e84ea469447e43650b48c4ca315ce5
Add demos for colormap functions

diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/ChangeLog
--- a/scripts/ChangeLog	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/ChangeLog	Thu Oct 22 13:27:00 2009 +0200
@@ -1,3 +1,10 @@
+2009-10-22  Soren Hauberg  <hauberg at gmail.com>
+
+	* image/autumn.m, image/bone.m, image/cool.m, image/copper.m, image/flag.m,
+	image/gmap40.m, image/gray.m, image/hot.m, image/hsv.m, image/jet.m,
+	image/ocean.m, image/pink.m, image/prism.m, image/rainbow.m, image/spring.m,
+	image/summer.m, image/white.m, image/winter.m: add demos.
+
 2009-10-20  Soren Hauberg  <hauberg at gmail.com>
 
 	* general/interp2.m: improved error checking and support for bicubic
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/autumn.m
--- a/scripts/image/autumn.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/autumn.m	Thu Oct 22 13:27:00 2009 +0200
@@ -50,3 +50,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'autumn' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap autumn
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/bone.m
--- a/scripts/image/bone.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/bone.m	Thu Oct 22 13:27:00 2009 +0200
@@ -53,3 +53,10 @@
     map = [];
   endif
 endfunction
+
+%!demo
+%! ## Show the 'bone' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap bone
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/cool.m
--- a/scripts/image/cool.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/cool.m	Thu Oct 22 13:27:00 2009 +0200
@@ -50,3 +50,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'cool' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap cool
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/copper.m
--- a/scripts/image/copper.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/copper.m	Thu Oct 22 13:27:00 2009 +0200
@@ -51,3 +51,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'copper' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap copper
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/flag.m
--- a/scripts/image/flag.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/flag.m	Thu Oct 22 13:27:00 2009 +0200
@@ -51,3 +51,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'flag' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap flag
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/gmap40.m
--- a/scripts/image/gmap40.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/gmap40.m	Thu Oct 22 13:27:00 2009 +0200
@@ -47,3 +47,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'gmap40' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap gmap40
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/gray.m
--- a/scripts/image/gray.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/gray.m	Thu Oct 22 13:27:00 2009 +0200
@@ -45,3 +45,10 @@
   map = [ gr, gr, gr ] / (number - 1);
 
 endfunction
+
+%!demo
+%! ## Show the 'gray' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap gray
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/hot.m
--- a/scripts/image/hot.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/hot.m	Thu Oct 22 13:27:00 2009 +0200
@@ -51,3 +51,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'hot' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap hot
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/hsv.m
--- a/scripts/image/hsv.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/hsv.m	Thu Oct 22 13:27:00 2009 +0200
@@ -53,3 +53,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'hsv' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap hsv
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/jet.m
--- a/scripts/image/jet.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/jet.m	Thu Oct 22 13:27:00 2009 +0200
@@ -54,3 +54,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'jet' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap jet
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/ocean.m
--- a/scripts/image/ocean.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/ocean.m	Thu Oct 22 13:27:00 2009 +0200
@@ -54,3 +54,10 @@
   map = [ r, g, b ] / (number - 1);
 
 endfunction
+
+%!demo
+%! ## Show the 'ocean' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap ocean
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/pink.m
--- a/scripts/image/pink.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/pink.m	Thu Oct 22 13:27:00 2009 +0200
@@ -54,3 +54,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'pink' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap pink
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/prism.m
--- a/scripts/image/prism.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/prism.m	Thu Oct 22 13:27:00 2009 +0200
@@ -47,3 +47,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'prism' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap prism
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/rainbow.m
--- a/scripts/image/rainbow.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/rainbow.m	Thu Oct 22 13:27:00 2009 +0200
@@ -55,3 +55,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'rainbow' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap rainbow
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/spring.m
--- a/scripts/image/spring.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/spring.m	Thu Oct 22 13:27:00 2009 +0200
@@ -50,3 +50,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'spring' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap spring
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/summer.m
--- a/scripts/image/summer.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/summer.m	Thu Oct 22 13:27:00 2009 +0200
@@ -51,3 +51,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'summer' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap summer
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/white.m
--- a/scripts/image/white.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/white.m	Thu Oct 22 13:27:00 2009 +0200
@@ -45,3 +45,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'white' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap white
+
diff -r 584ca012b9e8 -r 9357d0e3d5e0 scripts/image/winter.m
--- a/scripts/image/winter.m	Tue Oct 20 20:22:10 2009 +0200
+++ b/scripts/image/winter.m	Thu Oct 22 13:27:00 2009 +0200
@@ -51,3 +51,10 @@
   endif
 
 endfunction
+
+%!demo
+%! ## Show the 'winter' colormap as an image
+%! image (1:64, linspace (0, 1, 64), repmat (1:64, 64, 1)')
+%! axis ([1, 64, 0, 1], "ticy", "xy")
+%! colormap winter
+

From marco.caliari at univr.it  Thu Oct 22 11:00:49 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Thu, 22 Oct 2009 18:00:49 +0200 (CEST)
Subject: Improved triu.m and tril.m
Message-ID: <alpine.DEB.1.00.0910221739550.8697@profs.sci.univr.it>

Dear maintainers,

although triu and tril are built-in functions in Matlab and then much 
faster, I discovered that it is possible to improve the m files in Octave, 
by eliminating the min/max evaluations inside the loops and selecting 
whether to replace numbers with zeros or zeros wih numbers.
The results, for my Octave 3.2.3, are:

> A=rand(100);
> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
i = -31
Elapsed time is 0.0221 seconds.
Elapsed time is 0.00397 seconds.
ans = 0
> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
i = -52
Elapsed time is 0.0224 seconds.
Elapsed time is 0.00114 seconds.
ans = 0
> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
i =  22
Elapsed time is 0.0174 seconds.
Elapsed time is 0.00495 seconds.
ans = 0
> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
i =  63
Elapsed time is 0.00873 seconds.
Elapsed time is 0.00261 seconds.
ans = 0
> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
i =  36
Elapsed time is 0.0146 seconds.
Elapsed time is 0.00413 seconds.
ans = 0

For me the speed-up is > 3. Enclosed, the patches wrt 3.2.3.

Best regards,

Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: triu.m.diff
Type: text/x-diff
Size: 2019 bytes
Desc: 
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091022/12e5fbc2/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tril.m.diff
Type: text/x-diff
Size: 1931 bytes
Desc: 
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091022/12e5fbc2/attachment-0001.bin 

From haakon.eriksen at far.no  Thu Oct 22 12:43:44 2009
From: haakon.eriksen at far.no (Haakon Meland Eriksen)
Date: Thu, 22 Oct 2009 19:43:44 +0200
Subject: Sharing an idea - easy downloading of code from a wiki
Message-ID: <4AE099D0.3000003@far.no>

Hi,

A friend of mine got me interested in GNU Octave. I looked at your wiki
and wanted to share an idea our Fram-project has implemented as an
extension for Mediawiki. It lets you write an explanation interspersed
with code, just like you do now, and adds extraction, concatenation and
downloading of the complete code for immediate use. Here is an example I
wrote called "Introduction to Haskell":

http://far.no/fram/index.php?title=Introduction_to_Haskell

If you like the functionality, you can find the code for the
Fram-extension itself at

http://far.no/fram/index.php?title=Fram

and adapt it to your own wiki under the terms of the GNU GPL v 3.


Yours sincerely,
Haakon Meland Eriksen




From highegg at gmail.com  Thu Oct 22 14:54:18 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 22 Oct 2009 21:54:18 +0200
Subject: Improved triu.m and tril.m
In-Reply-To: <alpine.DEB.1.00.0910221739550.8697@profs.sci.univr.it>
References: <alpine.DEB.1.00.0910221739550.8697@profs.sci.univr.it>
Message-ID: <69d8d540910221254x1a52b88fu12931aeaa34aafc1@mail.gmail.com>

2009/10/22 Marco Caliari <marco.caliari at univr.it>:
> Dear maintainers,
>
> although triu and tril are built-in functions in Matlab and then much
> faster, I discovered that it is possible to improve the m files in Octave,
> by eliminating the min/max evaluations inside the loops and selecting
> whether to replace numbers with zeros or zeros wih numbers.
> The results, for my Octave 3.2.3, are:
>
>> A=rand(100);
>>
>> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
>
> i = -31
> Elapsed time is 0.0221 seconds.
> Elapsed time is 0.00397 seconds.
> ans = 0
>>
>>
>> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
>
> i = -52
> Elapsed time is 0.0224 seconds.
> Elapsed time is 0.00114 seconds.
> ans = 0
>>
>>
>> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
>
> i = ?22
> Elapsed time is 0.0174 seconds.
> Elapsed time is 0.00495 seconds.
> ans = 0
>>
>>
>> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
>
> i = ?63
> Elapsed time is 0.00873 seconds.
> Elapsed time is 0.00261 seconds.
> ans = 0
>>
>>
>> i=randperm(200)(1)-100,tic,U=triu(A,i);,toc,tic,myU=mytriu(A,i);,toc,norm(U-myU)
>
> i = ?36
> Elapsed time is 0.0146 seconds.
> Elapsed time is 0.00413 seconds.
> ans = 0
>
> For me the speed-up is > 3. Enclosed, the patches wrt 3.2.3.
>
> Best regards,
>
> Marco

Interesting. For comparison, here is my benchmark:

n = 500;
A = rand (n);
k = 1;
tril (eye (2)); # to avoid startup penalty
for iter = 1:4
  tic; tril (A, k); toc
endfor

my tip gives:

Elapsed time is 0.0236731 seconds.
Elapsed time is 0.0239391 seconds.
Elapsed time is 0.0221 seconds.
Elapsed time is 0.022387 seconds.

the relevant code snippet is

  retval = resize (resize (x, 0), nr, nc);
  for j = 1 : min (nc, nr+k)
    nr_limit = max (1, j-k);
    retval (nr_limit:nr, j) = x (nr_limit:nr, j);
  endfor

one can save a lot by doing a vectorized max once and eliminating the
repeated range:

  retval = zeros (nr, nc, class (x));
  jj = 1:min (nc, nr+k);
  ii = max (1, jj - k);
  for j = jj
    i = ii(j):nr;
    retval (i, j) = x (i, j);
  endfor

this gives:

Elapsed time is 0.0148931 seconds.
Elapsed time is 0.0148301 seconds.
Elapsed time is 0.0152121 seconds.
Elapsed time is 0.014981 seconds.

using cellslices + vertcat + reshape is faster still:

  m = min (nc, nr+k);
  ii = max (1, (1:m) - k);

  sl(2,:) = cellslices (x(:), ii, nr*ones (1, m));
  sl(1,:) = cellslices (zeros (nr, 1), ones (1, m), ii - 1);

  retval = reshape (vertcat (sl{:}), nr, nc);

gives

Elapsed time is 0.00466204 seconds.
Elapsed time is 0.00521612 seconds.
Elapsed time is 0.00525379 seconds.
Elapsed time is 0.00514317 seconds.

for comparison, your patch:

Elapsed time is 0.00818515 seconds.
Elapsed time is 0.00864601 seconds.
Elapsed time is 0.00886297 seconds.
Elapsed time is 0.00826406 seconds.

(quite good, compared to the loop-free code). Winner is number 3.
triu can be handled similarly. Neither of these approaches works
efficiently for sparse functions, though, so it should get a special
code (probably using find). But anyway, I think implementing
triu/tril/vech as compiled functions should be trivial and likely the
fastest.

Out of interest, do you depend on triu/tril efficiency in an application?

regards

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


From marco.caliari at univr.it  Fri Oct 23 02:52:50 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Fri, 23 Oct 2009 09:52:50 +0200 (CEST)
Subject: Improved triu.m and tril.m
In-Reply-To: <69d8d540910221254x1a52b88fu12931aeaa34aafc1@mail.gmail.com>
References: <alpine.DEB.1.00.0910221739550.8697@profs.sci.univr.it>
	<69d8d540910221254x1a52b88fu12931aeaa34aafc1@mail.gmail.com>
Message-ID: <alpine.DEB.1.00.0910230931550.25522@profs.sci.univr.it>

> using cellslices + vertcat + reshape is faster still:
>
>  m = min (nc, nr+k);
>  ii = max (1, (1:m) - k);
>
>  sl(2,:) = cellslices (x(:), ii, nr*ones (1, m));
>  sl(1,:) = cellslices (zeros (nr, 1), ones (1, m), ii - 1);
>
>  retval = reshape (vertcat (sl{:}), nr, nc);

Great, even if, it does not work for me... I think the problem is related 
to what I get with 3.2.3

octave:1> cellslices([1,2],1,0)
error: subscript indices must be either positive integers or logicals.

Maybe the result should be

{
   [1,1] = [](1x0)
}

Also this appears strange to me

octave:1> cellslices([1,2,3],[2,3],[1,1])
error: invalid range used as index.

> Out of interest, do you depend on triu/tril efficiency in an application?

Not really. I had a code with fft and matrix manipulations and it was 
slower in Octave than in Matlab just because of a final triu.

Cheers,

Marco

From highegg at gmail.com  Fri Oct 23 04:01:48 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 23 Oct 2009 11:01:48 +0200
Subject: Improved triu.m and tril.m
In-Reply-To: <alpine.DEB.1.00.0910230931550.25522@profs.sci.univr.it>
References: <alpine.DEB.1.00.0910221739550.8697@profs.sci.univr.it>
	<69d8d540910221254x1a52b88fu12931aeaa34aafc1@mail.gmail.com>
	<alpine.DEB.1.00.0910230931550.25522@profs.sci.univr.it>
Message-ID: <69d8d540910230201n70599727h7ff010166915105c@mail.gmail.com>

On Fri, Oct 23, 2009 at 9:52 AM, Marco Caliari <marco.caliari at univr.it> wrote:
>> using cellslices + vertcat + reshape is faster still:
>>
>> ?m = min (nc, nr+k);
>> ?ii = max (1, (1:m) - k);
>>
>> ?sl(2,:) = cellslices (x(:), ii, nr*ones (1, m));
>> ?sl(1,:) = cellslices (zeros (nr, 1), ones (1, m), ii - 1);
>>
>> ?retval = reshape (vertcat (sl{:}), nr, nc);
>
> Great, even if, it does not work for me... I think the problem is related to
> what I get with 3.2.3
>
> octave:1> cellslices([1,2],1,0)
> error: subscript indices must be either positive integers or logicals.
>

Yes, this was already fixed in development tip.

> Maybe the result should be
>
> {
> ?[1,1] = [](1x0)
> }
>
> Also this appears strange to me
>
> octave:1> cellslices([1,2,3],[2,3],[1,1])
> error: invalid range used as index.
>

Huh. One more bug. A fix is here:
http://hg.savannah.gnu.org/hgweb/octave/rev/95ad9c2a27e2


>> Out of interest, do you depend on triu/tril efficiency in an application?
>
> Not really. I had a code with fft and matrix manipulations and it was slower
> in Octave than in Matlab just because of a final triu.
>
> Cheers,
>
> Marco
>

Based on a code sent today by David Bateman, I implemented a compiled
(and extended) version of triu/tril:
http://hg.savannah.gnu.org/hgweb/octave/rev/b134960cea23

so you may check that out. Btw, If you want to help improve Octave's
performance by measuring speed and benchmarks, I'd strongly recommend
you work with the development sources.

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  Fri Oct 23 04:22:49 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 23 Oct 2009 11:22:49 +0200
Subject: FYI: tril/triu optimized
Message-ID: <69d8d540910230222q721462ccs6889c8ebb79b72a3@mail.gmail.com>

hi all,

in cooperation with David Bateman, I contributed an optimized compiled
implementation of tril and triu:
http://hg.savannah.gnu.org/hgweb/octave/rev/b134960cea23

benchmark

n = 2000;
A = rand (n);
k = 1;
tril (eye (2)); # to avoid startup penalty
for iter = 1:4
 tic; tril (A, k); toc
endfor

I got these timings:

original version:

Elapsed time is 0.0026319 seconds.
Elapsed time is 0.00277996 seconds.
Elapsed time is 0.00257206 seconds.
Elapsed time is 0.00258803 seconds.
Elapsed time is 0.0137451 seconds.
Elapsed time is 0.0138719 seconds.
Elapsed time is 0.0140979 seconds.
Elapsed time is 0.0158539 seconds.
Elapsed time is 0.0766211 seconds.
Elapsed time is 0.0778449 seconds.
Elapsed time is 0.077647 seconds.
Elapsed time is 0.0763021 seconds.


the new patch

Elapsed time is 5.88894e-05 seconds.
Elapsed time is 5.4121e-05 seconds.
Elapsed time is 2.31266e-05 seconds.
Elapsed time is 2.19345e-05 seconds.
Elapsed time is 0.000933886 seconds.
Elapsed time is 0.00111985 seconds.
Elapsed time is 0.000917912 seconds.
Elapsed time is 0.000798941 seconds.
Elapsed time is 0.018568 seconds.
Elapsed time is 0.020371 seconds.
Elapsed time is 0.020745 seconds.
Elapsed time is 0.0183351 seconds.


speed-up is more than 100x for n = 100, up to 20x for n = 500 , about
4x for n = 2000...
further, tril/triu now accept a "pack" option, so that they pack the
extracted elements in a column...

octave:1> a = rand(5)
a =

   0.393561   0.913037   0.518761   0.859863   0.778841
   0.438795   0.925017   0.813088   0.823300   0.154816
   0.304567   0.232932   0.574848   0.437198   0.095469
   0.260991   0.733759   0.916659   0.408505   0.949647
   0.072507   0.706963   0.811008   0.908441   0.087412

octave:2> triu(a)
ans =

   0.39356   0.91304   0.51876   0.85986   0.77884
   0.00000   0.92502   0.81309   0.82330   0.15482
   0.00000   0.00000   0.57485   0.43720   0.09547
   0.00000   0.00000   0.00000   0.40850   0.94965
   0.00000   0.00000   0.00000   0.00000   0.08741

octave:3> triu(a,"pack")
ans =

   0.393561
   0.913037
   0.925017
   0.518761
   0.813088
   0.574848
   0.859863
   0.823300
   0.437198
   0.408505
   0.778841
   0.154816
   0.095469
   0.949647
   0.087412

enjoy

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

From godfrey at isl.stanford.edu  Fri Oct 23 14:17:04 2009
From: godfrey at isl.stanford.edu (Michael D. Godfrey)
Date: Fri, 23 Oct 2009 12:17:04 -0700
Subject: Fwd: changeset: Allow more relaxed font test
Message-ID: <4AE20130.7060204@isl.stanford.edu>

I sent in this minor update on 2 October.
It would be helpful if it could be applied.  I am quite
sure that the simpler test is correct, and no one has
an explanation for the additional

res != FcResultNoMatch


test.  Without this change Fedora systems fail for
all text processing the backend fltk.

Michael
-------- Original Message --------
Subject: 	changeset: Allow more relaxed font test
Date: 	Fri, 02 Oct 2009 14:48:51 -0700
From: 	Michael D. Godfrey <godfrey at isl.stanford.edu>
To: 	octave maintainers mailing list <maintainers at octave.org>



Fedora Linux systems seem to fail the current
font test when suitable fonts are available.  This
change results in fonts being found.  The reason
for the additional test, which this change comments out,
seems to be unclear.  I have left the test in the source
in case someone wants to explore  better ways of handling
the font matching.

Michael Godfrey



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091023/8fe2394f/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: changeset_font_upd
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091023/8fe2394f/attachment.ksh 

From tmacchant at yahoo.co.jp  Mon Oct 26 05:35:15 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 26 Oct 2009 19:35:15 +0900 (JST)
Subject: ginput bug ? for development branch
In-Reply-To: <20091024205355.87440.qmail@web3807.mail.bbt.yahoo.co.jp>
Message-ID: <20091026103515.75802.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello

It will be grateful for me if anybody inform to the ML whether ginput works correct for development
branch or not on his system.

Regards

Tatsuro  

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> I found that 'ginput(1)' does not work on binaries from the very recent  source trees on
> http://www.octave.org/hg/octave.
> 
> description	GNU Octave (development branch)
> owner	John W. Eaton
> last change	Fri, 23 Oct 2009 09:28:14 -0700
> project home	http://savannah.gnu.org/projects/octave
> 
> Windows XP home
> Complier gcc 4.4.0/mingw (Official but not TDM)
> 
> For octave 3.2.3, 'ginput(1)' works correct as, 
> octave.exe:1fplot ("cos", [0, 2*pi])
> octave.exe:2ginput(1)
> octave.exe:3>
> After mouse click once on the gnuplot graph window,  a new octave prompt appear.
> 
> However, for octave 3.3.50+ 
> octave.exe:1fplot ("cos", [0, 2*pi])
> octave.exe:2ginput(1)
> 
> No response happens ever after mouse click on gnuplot graphic  window.
> octave seem to fall into an infinite loop.
> 
> I have not yet see the difference code difference between those of 3.2.3 and those of 3.3.50+.
> 
> Regards
> 
> Tatsuro
> 
> --------------------------------------
> GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
> http://pr.mail.yahoo.co.jp/gyao/
> _______________________________________________
> Bug-octave mailing list
> Bug-octave at octave.org
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
> 


--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

From bpabbott at mac.com  Mon Oct 26 05:54:24 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Mon, 26 Oct 2009 06:54:24 -0400
Subject: ginput bug ? for development branch
In-Reply-To: <20091026103515.75802.qmail@web3808.mail.bbt.yahoo.co.jp>
References: <20091026103515.75802.qmail@web3808.mail.bbt.yahoo.co.jp>
Message-ID: <5C86DA36-3266-4593-90EC-1575B3B7DABA@mac.com>


On Oct 26, 2009, at 6:35 AM, Tatsuro MATSUOKA wrote:

> Hello
>
> It will be grateful for me if anybody inform to the ML whether  
> ginput works correct for development
> branch or not on his system.
>
> Regards
>
> Tatsuro
>
> --- Tatsuro MATSUOKA  wrote:
>
>> Hello
>>
>> I found that 'ginput(1)' does not work on binaries from the very  
>> recent  source trees on
>> http://www.octave.org/hg/octave.
>>
>> description	GNU Octave (development branch)
>> owner	John W. Eaton
>> last change	Fri, 23 Oct 2009 09:28:14 -0700
>> project home	http://savannah.gnu.org/projects/octave
>>
>> Windows XP home
>> Complier gcc 4.4.0/mingw (Official but not TDM)
>>
>> For octave 3.2.3, 'ginput(1)' works correct as,
>> octave.exe:1fplot ("cos", [0, 2*pi])
>> octave.exe:2ginput(1)
>> octave.exe:3>
>> After mouse click once on the gnuplot graph window,  a new octave  
>> prompt appear.
>>
>> However, for octave 3.3.50+
>> octave.exe:1fplot ("cos", [0, 2*pi])
>> octave.exe:2ginput(1)
>>
>> No response happens ever after mouse click on gnuplot graphic   
>> window.
>> octave seem to fall into an infinite loop.
>>
>> I have not yet see the difference code difference between those of  
>> 3.2.3 and those of 3.3.50+.
>>
>> Regards
>>
>> Tatsuro

ginput does work for me on OSX. My gnuplot is also the developers  
version.

Ben



From lindnerben at gmx.net  Mon Oct 26 06:04:44 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 26 Oct 2009 12:04:44 +0100
Subject: gnulib and automake
In-Reply-To: <19121.21838.419944.184758@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>
Message-ID: <4AE5824C.5040106@gmx.net>

John W. Eaton wrote:
> Instead of the current ad-hoc way of including portability and
> replacement functions (things like mkdir, rmdir, strftime, etc.) in
> Octave, I would like to start using functions from gnulib
> (http://www.gnu.org/software/gnulib).  By using gnulib, we should get
> improved portability and in some cases better or newer versions of
> some of the replacement functions that we are currently using.
> 
> To see what would be required, I started trying to modify Octave's
> configure scripts to use gnulib, but quickly found that it is fairly
> complex to use gnulib without also using automake.
> 
> I've resisted using automake in the past because it seemed that it
> would be a fairly large job to convert Octave's existing build
> environment.  But at this point, I'm willing to give it a try just to
> get gnulib working.
> 
> Switching to automake and using gnulib may mean some additional
> disruption in building Octave during the transition.  Some changes to
> the way Octave is built from the Mercurial archive may be needed.  At
> the very least, you will need to have some way to get modules from
> gnulib if you don't already have them.  But the rules for this should
> all be in the configure (or bootstrap/autogen.sh) script, so you
> should really only need a network connection, and then only if you
> don't already have the necessary modules.
> 
> Are there any strong objections to making this change?
> 
> Is anyone on the list an expert automake user who would be willing to
> help with the transition?

The topic does not seem to have aroused much interest...
Well, I am not an expert on automake and neither on gnulib so I'm not in 
the position to state objections.

I'd like to see the build process still work for windows/mingw platform. 
Some of octave's dependecy libraries use automake, so this seems to work 
all right. I have no experience with gnulib and windows, so I can't 
really judge on that.

benjamin

From lindnerben at gmx.net  Tue Oct 27 16:10:47 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 27 Oct 2009 22:10:47 +0100
Subject: Making forge-packages installation relocatable
Message-ID: <4AE761D7.7010701@gmx.net>

Hello all,

One item on my personal todo list for octave has long been to make the 
octave forge package installation via pkg.m relocatable, i.e. allowing 
an installed octave directory structure to be moved elsewhere and having 
everything work as before (thus making octave a truly portable application).

Currently this works for octave itself, but not if forge packages are 
installed.

This is, because installed packages are referred to by their absolute 
path at the time of installation.
My idea is to remove the absolute path and store only the package's 
actual subdirectory and restore the absolute path at runtime based on 
OCTAVE_HOME().

Thinking about it I realised that  this makes sense only for globally 
installed packages - not locally installed ones.

I have attached a first attempt to achieve this.

I'm not entirely satisified by the solution, but it is a first attempt 
and it does work for me for octave-3.2.3 on windows.

comments and suggestions are very welcome.

I see that the package list structure contains actually two directory paths:
  .dir
  .archprefix

In the attached patch I actually only deal with the .dir field, by 
creating a new function getdir() (similar to getarchdir()) and replacing 
all explicit references to the field .dir by a call to this new function.

The situation with .archprefix is different, as currently, this field is 
not referenced directly, rather than through the function getsrchdir(). 
So I modified this function to generate the actual absolute path at runtime.

But actually the field .archprefix is redundant, because this directory 
can be (and is) created from the package's description and version at 
runtime, so couldn't it be removed anyway?

benjamin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pkg.patch
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091027/fb321214/attachment.ksh 

From tmacchant at yahoo.co.jp  Wed Oct 28 04:09:13 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 28 Oct 2009 18:09:13 +0900 (JST)
Subject: tilde_expand ("^")=?ISO-2022-JP?B?GyRCGyRCISEbKEI=?= returns ~ octave
	built on mingw on windows XP pro sp3
Message-ID: <20091028090913.47392.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello

I have noticed today on octave 3.2.3/mingw by Benjamin
octave.exe:1> tilde_expand ("^")
ans = ^

The same phenomenon happened  all versions of octave on mingw that I have investigatred. 

3.0.5   Benjamin 
3.2.2   Benjamin 
3.2.3   Benjamin 
3.2.3+  Tatsuro
3.3.50+ Tatsuro

Hmmm?
I suspect that the recent Windows update is the origin of this anomalous behavior.
However no proof exist at present.    

A few weeks before  tilde_expand ("^") works correct on my computer.

I will test it on the computer in my house (windows XP Home sp3).

Anyway the collection of information is important.

I ask users of octave/ mingw test   tilde_expand ("^") reports results with information kind of OS.
(ex. XP Professional, VISTA Home Premium and so on. )

Regards

Tatsuro 

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

From tmacchant at yahoo.co.jp  Wed Oct 28 04:29:35 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 28 Oct 2009 18:29:35 +0900 (JST)
Subject: tilde_expand ("^")=?ISO-2022-JP?B?GyRCGyRCISEbKEI=?= returns ~
	octave built on mingw on windows XP pro sp3 (also on Cygwin)
In-Reply-To: <20091028090913.47392.qmail@web3808.mail.bbt.yahoo.co.jp>
Message-ID: <20091028092935.50287.qmail@web3809.mail.bbt.yahoo.co.jp>

Hello

I add to octave 3.0.3 on MSVC by Michael and octave 3.2.3 on cygwin by Marco to the following list 
> 
> 3.0.5   Benjamin 
> 3.2.2   Benjamin 
> 3.2.3   Benjamin 
> 3.2.3+  Tatsuro
> 3.3.50+ Tatsuro

Regards

Tatsuro

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> I have noticed today on octave 3.2.3/mingw by Benjamin
> octave.exe:1> tilde_expand ("^")
> ans = ^
> 
> The same phenomenon happened  all versions of octave on mingw that I have investigatred. 
> 
> 3.0.5   Benjamin 
> 3.2.2   Benjamin 
> 3.2.3   Benjamin 
> 3.2.3+  Tatsuro
> 3.3.50+ Tatsuro
> 
> Hmmm?
> I suspect that the recent Windows update is the origin of this anomalous behavior.
> However no proof exist at present.    
> 
> A few weeks before  tilde_expand ("^") works correct on my computer.
> 
> I will test it on the computer in my house (windows XP Home sp3).
> 
> Anyway the collection of information is important.
> 
> I ask users of octave/ mingw test   tilde_expand ("^") reports results with information kind of
> OS.
> (ex. XP Professional, VISTA Home Premium and so on. )
> 
> Regards
> 
> Tatsuro 
> 
> --------------------------------------
> GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
> http://pr.mail.yahoo.co.jp/gyao/
> 


--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

From individ at acc.umu.se  Wed Oct 28 04:43:51 2009
From: individ at acc.umu.se (David Grundberg)
Date: Wed, 28 Oct 2009 10:43:51 +0100
Subject: tilde_expand =?ISO-2022-JP?B?KCJeIikbJEIhIRsoQiByZXR1cm5zIH4g?=
	=?ISO-2022-JP?B?b2N0YXZlIGJ1aWx0IG9uIG1pbmd3IG9uIHdpbmRvd3MgWFAgcHJvIHNw?=
	=?ISO-2022-JP?B?Mw==?=
In-Reply-To: <20091028090913.47392.qmail@web3808.mail.bbt.yahoo.co.jp>
References: <20091028090913.47392.qmail@web3808.mail.bbt.yahoo.co.jp>
Message-ID: <4AE81257.1000106@acc.umu.se>

Tatsuro MATSUOKA wrote:
> Hello
>
> I have noticed today on octave 3.2.3/mingw by Benjamin
> octave.exe:1> tilde_expand ("^")
> ans = ^
>
> The same phenomenon happened  all versions of octave on mingw that I have investigatred. 
>
> 3.0.5   Benjamin 
> 3.2.2   Benjamin 
> 3.2.3   Benjamin 
> 3.2.3+  Tatsuro
> 3.3.50+ Tatsuro
>
> Hmmm?
> I suspect that the recent Windows update is the origin of this anomalous behavior.
> However no proof exist at present.    
>
> A few weeks before  tilde_expand ("^") works correct on my computer.
>
> I will test it on the computer in my house (windows XP Home sp3).
>
> Anyway the collection of information is important.
>
> I ask users of octave/ mingw test   tilde_expand ("^") reports results with information kind of OS.
> (ex. XP Professional, VISTA Home Premium and so on. )
>
> Regards
>
> Tatsuro 
>
> --------------------------------------
> GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
> http://pr.mail.yahoo.co.jp/gyao/
>   


I'm confused about what you are trying to say. From what I understand,
tilde_expand ("^") is to return just that (a 'hat' or 'caret'
character). tilde_expand("~") with a tilde, returns the path of the home
directory.

David

From marco_atzeri at yahoo.it  Wed Oct 28 05:02:37 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Wed, 28 Oct 2009 10:02:37 +0000 (GMT)
Subject: =?utf-8?B?UmU6IHRpbGRlX2V4cGFuZCAoIl4iKeOAgCByZXR1cm5zIH4gb2N0YXZlIGJ1?=
	=?utf-8?B?aWx0IG9uIG1pbmd3IG9uIHdpbmRvd3MgWFAgcHJvIHNwMyAoYWxzbyBvbiBD?=
	=?utf-8?B?eWd3aW4p?=
In-Reply-To: <20091028092935.50287.qmail@web3809.mail.bbt.yahoo.co.jp>
Message-ID: <30365.96350.qm@web25508.mail.ukl.yahoo.com>

Tatsuro,
are you mixing character ?

 tilde_expand ("~")
ans = /home/itq00146


--- Mer 28/10/09, Tatsuro MATSUOKA <tmacchant at yahoo.co.jp> ha scritto:

> Da: Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>
> Oggetto: Re: tilde_expand ("^")? returns ~ octave built on mingw on windows XP pro sp3 (also on Cygwin)
> A: tmacchant at yahoo.co.jp, maintainers at octave.org
> Cc: "Benjamin Lindner" <lindnerben at gmx.net>, marco_atzeri at yahoo.it
> Data: Mercoled? 28 ottobre 2009, 10:29
> Hello
> 
> I add to octave 3.0.3 on MSVC by Michael and octave 3.2.3
> on cygwin by Marco to the following list 
> > 
> > 3.0.5???Benjamin 
> > 3.2.2???Benjamin 
> > 3.2.3???Benjamin 
> > 3.2.3+? Tatsuro
> > 3.3.50+ Tatsuro
> 
> Regards
> 
> Tatsuro



      


From Rolf.Schirmacher at MuellerBBM.de  Wed Oct 28 04:53:16 2009
From: Rolf.Schirmacher at MuellerBBM.de (Schirmacher, Rolf)
Date: Wed, 28 Oct 2009 10:53:16 +0100
Subject: tilde_expand ("^")  returns ~ octave built on mingw on window
	s XP pro sp3 (also on Cygwin)
Message-ID: <2417729F3416D511A27E0090273A963B02911105@smex01.mbbm.de>


octave 3.0.3 MSVC on XP Professional, Version 2002, SP 3, used in emacs
octave mode works correctly:

	octave.exe> tilde_expand("~")
	ans = O:\

(o:\ is the drive & path set as $HOME in the environment).

HTH

Rolf
 

From tmacchant at yahoo.co.jp  Wed Oct 28 05:50:39 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 28 Oct 2009 19:50:39 +0900 (JST)
Subject: tilde_expand ("^")=?ISO-2022-JP?B?GyRCGyRCISEbKEI=?= returns ~
	octave built on mingw on windows XP pro sp3 (also on Cygwin)
In-Reply-To: <20091028090913.47392.qmail@web3808.mail.bbt.yahoo.co.jp>
Message-ID: <20091028105039.89394.qmail@web3801.mail.bbt.yahoo.co.jp>

Hello

I add to octave 3.0.3 on MSVC by Michael and octave 3.2.3 on cygwin by Marco to the following list 
> 
> 3.0.5   Benjamin 
> 3.2.2   Benjamin 
> 3.2.3   Benjamin 
> 3.2.3+  Tatsuro
> 3.3.50+ Tatsuro

Regards

Tatsuro

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> I have noticed today on octave 3.2.3/mingw by Benjamin
> octave.exe:1> tilde_expand ("^")
> ans = ^
> 
> The same phenomenon happened  all versions of octave on mingw that I have investigatred. 
> 
> 3.0.5   Benjamin 
> 3.2.2   Benjamin 
> 3.2.3   Benjamin 
> 3.2.3+  Tatsuro
> 3.3.50+ Tatsuro
> 
> Hmmm?
> I suspect that the recent Windows update is the origin of this anomalous behavior.
> However no proof exist at present.    
> 
> A few weeks before  tilde_expand ("^") works correct on my computer.
> 
> I will test it on the computer in my house (windows XP Home sp3).
> 
> Anyway the collection of information is important.
> 
> I ask users of octave/ mingw test   tilde_expand ("^") reports results with information kind of
> OS.
> (ex. XP Professional, VISTA Home Premium and so on. )
> 
> Regards
> 
> Tatsuro 
> 
> --------------------------------------
> GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
> http://pr.mail.yahoo.co.jp/gyao/
> 


--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

From tmacchant at yahoo.co.jp  Wed Oct 28 05:53:51 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 28 Oct 2009 19:53:51 +0900 (JST)
Subject: tilde_expand ("^")=?ISO-2022-JP?B?GyRCISEbKEI=?= returns ~ octave
	built on mingw on windows XP pro sp3 (also on Cygwin)
In-Reply-To: <30365.96350.qm@web25508.mail.ukl.yahoo.com>
Message-ID: <20091028105355.2437.qmail@web3807.mail.bbt.yahoo.co.jp>

Hello

Sorry! 
Please ignore the noise

Regards

Tatsuro

--- Marco Atzeri  wrote:

> Tatsuro,
> are you mixing character ?
> 
>  tilde_expand ("~")
> ans = /home/itq00146
> 
> 
> --- Mer 28/10/09, Tatsuro MATSUOKA <tmacchant at yahoo.co.jp> ha scritto:
> 
> > Da: Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>
> > Oggetto: Re: tilde_expand ("^") returns ~ octave built on mingw on windows XP pro sp3 (also
> on Cygwin)
> > A: tmacchant at yahoo.co.jp, maintainers at octave.org
> > Cc: "Benjamin Lindner" <lindnerben at gmx.net>, marco_atzeri at yahoo.it
> > Data: Mercoled? 28 ottobre 2009, 10:29
> > Hello
> > 
> > I add to octave 3.0.3 on MSVC by Michael and octave 3.2.3
> > on cygwin by Marco to the following list 
> > > 
> > > 3.0.5&#65533;&#65533;&#65533;Benjamin 
> > > 3.2.2&#65533;&#65533;&#65533;Benjamin 
> > > 3.2.3&#65533;&#65533;&#65533;Benjamin 
> > > 3.2.3+&#65533; Tatsuro
> > > 3.3.50+ Tatsuro
> > 
> > Regards
> > 
> > Tatsuro
> 
> 
> 
> 
> 


--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

From jwe at octave.org  Wed Oct 28 11:12:42 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 12:12:42 -0400
Subject: gnulib and automake
In-Reply-To: <4AE5824C.5040106@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
Message-ID: <19176.28026.31789.710006@segfault.lan>

On 26-Oct-2009, Benjamin Lindner wrote:

| John W. Eaton wrote:
| > Instead of the current ad-hoc way of including portability and
| > replacement functions (things like mkdir, rmdir, strftime, etc.) in
| > Octave, I would like to start using functions from gnulib
| > (http://www.gnu.org/software/gnulib).  By using gnulib, we should get
| > improved portability and in some cases better or newer versions of
| > some of the replacement functions that we are currently using.
| > 
| > To see what would be required, I started trying to modify Octave's
| > configure scripts to use gnulib, but quickly found that it is fairly
| > complex to use gnulib without also using automake.
| > 
| > I've resisted using automake in the past because it seemed that it
| > would be a fairly large job to convert Octave's existing build
| > environment.  But at this point, I'm willing to give it a try just to
| > get gnulib working.
| > 
| > Switching to automake and using gnulib may mean some additional
| > disruption in building Octave during the transition.  Some changes to
| > the way Octave is built from the Mercurial archive may be needed.  At
| > the very least, you will need to have some way to get modules from
| > gnulib if you don't already have them.  But the rules for this should
| > all be in the configure (or bootstrap/autogen.sh) script, so you
| > should really only need a network connection, and then only if you
| > don't already have the necessary modules.
| > 
| > Are there any strong objections to making this change?
| > 
| > Is anyone on the list an expert automake user who would be willing to
| > help with the transition?
| 
| The topic does not seem to have aroused much interest...
| Well, I am not an expert on automake and neither on gnulib so I'm not in 
| the position to state objections.
| 
| I'd like to see the build process still work for windows/mingw platform. 
| Some of octave's dependecy libraries use automake, so this seems to work 
| all right. I have no experience with gnulib and windows, so I can't 
| really judge on that.

I have no intention of breaking the build on Windows systems.

A preliminary changeset for the switch to automake is now available
here:

  http://jweaton.org/automake.gz

It would be helpful if you (and others) could try building Octave with
this changeset and see what happens.  Here's what you need to do:

  * download the changeset

  * clone a copy of the current hg archive

  * cd to the top-level directory of the cloned archive and use "hg
    import" to apply the changeset

  * run ./autogen.sh, configure, and make

To build from the mercurial archive, you will now need to have
automake and libtool installed in addition to the other tools (bison,
flex, gperf, etc.) that were required previously.

Building from a distribution tar file should not require any
additional tools beyond what is currently required.

Some things that have changed:

  * Compilation is handled by libtool, so dependency information is
    generated at compile time and the problem of bad or missing
    dependencies causing make to mysteriously exit should be gone.

  * There are fewer Makefiles.  All of libcruft is built from one
    Makefile now.  All of the scripts directory tree is handled by a
    single Makefile now.

  * Lists of files in the subdirectories (for example, in the libcruft
    and scripts directory trees) are listed in module.mk files 
    in those directories.

  * Some of the lists of files (for example, the lists of mx- and vx-
    files in the liboctave subdirectory) are now generated when
    autogen.sh runs instead of being generated by a script when Make
    runs.  This is done because automake needs to see a complete list
    of explicit file names.

  * Many, but not all GNU Makeisms have been removed from the
    Makefiles.  I may have gone too far, or maybe others would prefer
    it if the Makefiles were more portable.  I like to be fairly
    concise, but I would also be willing to work toward portability of
    the Makefiles if others think that is useful.  There is certainly
    more cleanup work that could be done.

  * The Octave version information is no longer extracted from
    src/version.h, but instead stored in configure.ac and inserted
    into src/version.h at build time.

Unresolved issues:

  * Building of .oct files is now done with libtool, which creates the
    dynamically loadable file and a .la file.  The .la file contains
    the name of the dynamically loadable library.  To generate the
    .oct file, we now extract the name from the .la file and link (at
    build time) or rename (at istall time) the dynamically loadable
    file to the .oct file.  The mkoctfile script has not been updated
    to use this method.  Once it is, I think we can delete all the
    hand-crafted shared library stuff from configure.ac.  But before
    we do that, we need to make sure that this all works properly on
    Windows and OS X systems.

  * When linking the final Octave exectuable, libtool generates a
    src/octave script which handles all the details of LD_LIBRARY_PATH
    so that Octave can run in the build directory.  The run-octave
    script no longer does that job.  Instead, it simply sets things
    like the load path and the info ile directory and calls the
    src/octave script.  However, since src/octave is a script, we
    can't run gdb or valgrind on it as before, so debugging with
    "run-octave -g" is currently broken.  I'd like to fix this, but I
    don't know what the best solution is.  The generated src/octave
    script doesn't seem to have a way to handle running a debugger on
    the real executable file.  What do other libtool-based projects
    do?

Comments or suggestions?

I would prefer to solve any problems before checking in this
change, so please help me out by testing this changeset on Windows and
OS X systems.  But I don't want to delay forever, so if I don't get
any feedback in the next week or so, I'll assume that it is working
and check it in.

Once this change is checked in, I will start to look at using gnulib
to handle portability and replacement functions.

jwe

From shaiay at gmail.com  Wed Oct 28 11:44:42 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Wed, 28 Oct 2009 18:44:42 +0200
Subject: gnulib and automake
In-Reply-To: <19176.28026.31789.710006@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
Message-ID: <420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>

On Wed, Oct 28, 2009 at 6:12 PM, John W. Eaton <jwe at octave.org> wrote:
> On 26-Oct-2009, Benjamin Lindner wrote:
>
> | John W. Eaton wrote:
> | > Instead of the current ad-hoc way of including portability and
> | > replacement functions (things like mkdir, rmdir, strftime, etc.) in
> | > Octave, I would like to start using functions from gnulib
> | > (http://www.gnu.org/software/gnulib). ?By using gnulib, we should get
> | > improved portability and in some cases better or newer versions of
> | > some of the replacement functions that we are currently using.
> | >
> | > To see what would be required, I started trying to modify Octave's
> | > configure scripts to use gnulib, but quickly found that it is fairly
> | > complex to use gnulib without also using automake.
> | >
> | > I've resisted using automake in the past because it seemed that it
> | > would be a fairly large job to convert Octave's existing build
> | > environment. ?But at this point, I'm willing to give it a try just to
> | > get gnulib working.
> | >
> | > Switching to automake and using gnulib may mean some additional
> | > disruption in building Octave during the transition. ?Some changes to
> | > the way Octave is built from the Mercurial archive may be needed. ?At
> | > the very least, you will need to have some way to get modules from
> | > gnulib if you don't already have them. ?But the rules for this should
> | > all be in the configure (or bootstrap/autogen.sh) script, so you
> | > should really only need a network connection, and then only if you
> | > don't already have the necessary modules.
> | >
> | > Are there any strong objections to making this change?
> | >
> | > Is anyone on the list an expert automake user who would be willing to
> | > help with the transition?
> |
> | The topic does not seem to have aroused much interest...
> | Well, I am not an expert on automake and neither on gnulib so I'm not in
> | the position to state objections.
> |
> | I'd like to see the build process still work for windows/mingw platform.
> | Some of octave's dependecy libraries use automake, so this seems to work
> | all right. I have no experience with gnulib and windows, so I can't
> | really judge on that.
>
> I have no intention of breaking the build on Windows systems.
>
> A preliminary changeset for the switch to automake is now available
> here:
>
> ?http://jweaton.org/automake.gz
>
I get a 404 No found error for this URL

Shai


From jwe at octave.org  Wed Oct 28 12:07:30 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 13:07:30 -0400
Subject: gnulib and automake
In-Reply-To: <420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
Message-ID: <19176.31314.572679.656960@segfault.lan>

On 28-Oct-2009, Shai Ayal wrote:

| > A preliminary changeset for the switch to automake is now available
| > here:
| >
| > ?http://jweaton.org/automake.gz
| >
| I get a 404 No found error for this URL

Oops, it is http://jweaton.org/automake-diffs.gz

jwe


From marco_atzeri at yahoo.it  Wed Oct 28 12:31:15 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Wed, 28 Oct 2009 17:31:15 +0000 (GMT)
Subject: gnulib and automake
In-Reply-To: <19176.28026.31789.710006@segfault.lan>
Message-ID: <749763.94875.qm@web25501.mail.ukl.yahoo.com>

--- Mer 28/10/09, John W. Eaton <jwe at octave.org> ha scritto:

> 
> I would prefer to solve any problems before checking in
> this
> change, so please help me out by testing this changeset on
> Windows and
> OS X systems.? But I don't want to delay forever, so
> if I don't get
> any feedback in the next week or so, I'll assume that it is
> working
> and check it in.
> 
> Once this change is checked in, I will start to look at
> using gnulib
> to handle portability and replacement functions.
> 
> jwe
> 

Hi John,
I need the "no match operator on mx-inlines.cc"

http://www-old.cae.wisc.edu/pipermail/bug-octave/2009-October/009667.html

solved, before trying the new build on cygwin

Thanks
Marco


      


From jwe at octave.org  Wed Oct 28 12:34:23 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 13:34:23 -0400
Subject: gnulib and automake
In-Reply-To: <749763.94875.qm@web25501.mail.ukl.yahoo.com>
References: <19176.28026.31789.710006@segfault.lan>
	<749763.94875.qm@web25501.mail.ukl.yahoo.com>
Message-ID: <19176.32927.774757.421731@segfault.lan>

On 28-Oct-2009, Marco Atzeri wrote:

| I need the "no match operator on mx-inlines.cc"
| 
| http://www-old.cae.wisc.edu/pipermail/bug-octave/2009-October/009667.html
| 
| solved, before trying the new build on cygwin

Can you determine precisely which patch it was that introduced this
problem?

jwe

From soren at hauberg.org  Wed Oct 28 13:09:34 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Wed, 28 Oct 2009 19:09:34 +0100
Subject: gnulib and automake
In-Reply-To: <19176.28026.31789.710006@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>
	<4AE5824C.5040106@gmx.net>  <19176.28026.31789.710006@segfault.lan>
Message-ID: <1256753374.3949.1.camel@sh-t400>

ons, 28 10 2009 kl. 12:12 -0400, skrev John W. Eaton:
> A preliminary changeset for the switch to automake is now available

After running, './autogen.sh', './configure
--prefix=/home/sh/Programmer' and 'make' I get the following output:

        make  all-recursive
        make[1]: Entering directory
        `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
        Making all in libcruft
        make[2]: Entering directory
        `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
        make[2]: *** No rule to make target `cacai.lo', needed by
        `libcruft.la'.  Stop.
        make[2]: Leaving directory
        `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
        make[1]: *** [all-recursive] Error 1
        make[1]: Leaving directory
        `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
        make: *** [all] Error 2

I don't know what that means :-(

S?ren


From jwe at octave.org  Wed Oct 28 13:37:43 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 14:37:43 -0400
Subject: gnulib and automake
In-Reply-To: <1256753374.3949.1.camel@sh-t400>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<1256753374.3949.1.camel@sh-t400>
Message-ID: <19176.36727.68839.830996@segfault.lan>

On 28-Oct-2009, S?ren Hauberg wrote:

| ons, 28 10 2009 kl. 12:12 -0400, skrev John W. Eaton:
| > A preliminary changeset for the switch to automake is now available
| 
| After running, './autogen.sh', './configure
| --prefix=/home/sh/Programmer' and 'make' I get the following output:
| 
|         make  all-recursive
|         make[1]: Entering directory
|         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
|         Making all in libcruft
|         make[2]: Entering directory
|         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
|         make[2]: *** No rule to make target `cacai.lo', needed by
|         `libcruft.la'.  Stop.
|         make[2]: Leaving directory
|         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
|         make[1]: *** [all-recursive] Error 1
|         make[1]: Leaving directory
|         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
|         make: *** [all] Error 2
| 
| I don't know what that means :-(

What version of automake are you using?

jwe


From soren at hauberg.org  Wed Oct 28 13:40:50 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Wed, 28 Oct 2009 19:40:50 +0100
Subject: gnulib and automake
In-Reply-To: <19176.36727.68839.830996@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>
	<4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan>
	<1256753374.3949.1.camel@sh-t400>
	<19176.36727.68839.830996@segfault.lan>
Message-ID: <1256755250.3949.2.camel@sh-t400>

ons, 28 10 2009 kl. 14:37 -0400, skrev John W. Eaton:
> On 28-Oct-2009, S?ren Hauberg wrote:
> 
> | ons, 28 10 2009 kl. 12:12 -0400, skrev John W. Eaton:
> | > A preliminary changeset for the switch to automake is now available
> | 
> | After running, './autogen.sh', './configure
> | --prefix=/home/sh/Programmer' and 'make' I get the following output:
> | 
> |         make  all-recursive
> |         make[1]: Entering directory
> |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
> |         Making all in libcruft
> |         make[2]: Entering directory
> |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
> |         make[2]: *** No rule to make target `cacai.lo', needed by
> |         `libcruft.la'.  Stop.
> |         make[2]: Leaving directory
> |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
> |         make[1]: *** [all-recursive] Error 1
> |         make[1]: Leaving directory
> |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
> |         make: *** [all] Error 2
> | 
> | I don't know what that means :-(
> 
> What version of automake are you using?

'automake --version' gives me

        automake (GNU automake) 1.10.2
        Copyright (C) 2008 Free Software Foundation, Inc.
        License GPLv2+: GNU GPL version 2 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.
        
        Written by Tom Tromey <tromey at redhat.com>
               and Alexandre Duret-Lutz <adl at gnu.org>.

S?ren


From jwe at octave.org  Wed Oct 28 13:45:32 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 14:45:32 -0400
Subject: gnulib and automake
In-Reply-To: <1256755250.3949.2.camel@sh-t400>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<1256753374.3949.1.camel@sh-t400>
	<19176.36727.68839.830996@segfault.lan>
	<1256755250.3949.2.camel@sh-t400>
Message-ID: <19176.37196.962055.187792@segfault.lan>

On 28-Oct-2009, S?ren Hauberg wrote:

| ons, 28 10 2009 kl. 14:37 -0400, skrev John W. Eaton:
| > On 28-Oct-2009, S?ren Hauberg wrote:
| > 
| > | ons, 28 10 2009 kl. 12:12 -0400, skrev John W. Eaton:
| > | > A preliminary changeset for the switch to automake is now available
| > | 
| > | After running, './autogen.sh', './configure
| > | --prefix=/home/sh/Programmer' and 'make' I get the following output:
| > | 
| > |         make  all-recursive
| > |         make[1]: Entering directory
| > |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
| > |         Making all in libcruft
| > |         make[2]: Entering directory
| > |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
| > |         make[2]: *** No rule to make target `cacai.lo', needed by
| > |         `libcruft.la'.  Stop.
| > |         make[2]: Leaving directory
| > |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
| > |         make[1]: *** [all-recursive] Error 1
| > |         make[1]: Leaving directory
| > |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
| > |         make: *** [all] Error 2
| > | 
| > | I don't know what that means :-(
| > 
| > What version of automake are you using?
| 
| 'automake --version' gives me
| 
|         automake (GNU automake) 1.10.2
|         Copyright (C) 2008 Free Software Foundation, Inc.
|         License GPLv2+: GNU GPL version 2 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.
|         
|         Written by Tom Tromey <tromey at redhat.com>
|                and Alexandre Duret-Lutz <adl at gnu.org>.

OK.  I have 1.11, and I don't have this problem.  Does automake 1.10.2
support the option

  AUTOMAKE_OPTIONS = subdir-objects

?  If not, I think we will have to require automake 1.11.

Ah, I see the following note in the NEWS file for automake 1.11:

  * Languages changes:

    - subdir-object mode works now with Fortran (F77, FC, preprocessed
      Fortran, and Ratfor).

so I guess 1.11 is required.

jwe


From soren at hauberg.org  Wed Oct 28 13:53:00 2009
From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg)
Date: Wed, 28 Oct 2009 19:53:00 +0100
Subject: gnulib and automake
In-Reply-To: <19176.37196.962055.187792@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>
	<4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan>
	<1256753374.3949.1.camel@sh-t400>
	<19176.36727.68839.830996@segfault.lan>
	<1256755250.3949.2.camel@sh-t400>
	<19176.37196.962055.187792@segfault.lan>
Message-ID: <1256755980.3949.4.camel@sh-t400>

ons, 28 10 2009 kl. 14:45 -0400, skrev John W. Eaton:
> OK.  I have 1.11, and I don't have this problem.  Does automake 1.10.2
> support the option
> 
>   AUTOMAKE_OPTIONS = subdir-objects
> 
> ?  If not, I think we will have to require automake 1.11.
> 
> Ah, I see the following note in the NEWS file for automake 1.11:
> 
>   * Languages changes:
> 
>     - subdir-object mode works now with Fortran (F77, FC, preprocessed
>       Fortran, and Ratfor).
> 
> so I guess 1.11 is required.

Okay, I guess I'll have to wait for this to be packaged for Ubuntu. It
should be part of the next release that's coming in a couple of days, so
this is not a big issue for me.

S?ren


From shaiay at gmail.com  Wed Oct 28 14:30:07 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Wed, 28 Oct 2009 21:30:07 +0200
Subject: gnulib and automake
In-Reply-To: <19176.31314.572679.656960@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
Message-ID: <420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>

On Wed, Oct 28, 2009 at 7:07 PM, John W. Eaton <jwe at octave.org> wrote:
> On 28-Oct-2009, Shai Ayal wrote:
>
> | > A preliminary changeset for the switch to automake is now available
> | > here:
> | >
> | > ?http://jweaton.org/automake.gz
> | >
> | I get a 404 No found error for this URL
>
> Oops, it is http://jweaton.org/automake-diffs.gz
It almost compiles for me except at the very end:
./octave.aux:4743: TeX capacity exceeded, sorry [save size=5000].
@otherbackslash ->@let \=@realbackslash

@xrdef #1#2->{@indexnofonts @turnoffactive
                                           @xdef @safexrefname {#1}}@expanda...
l.4743 @xrdef{doc-getenv-pg}{567}

No pages of output.
Transcript written on octave.log.
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[3]: *** [octave.dvi] Error 1
make[3]: Leaving directory `/home/shaia/hack/octave-amake/doc/interpreter'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/shaia/hack/octave-amake/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/shaia/hack/octave-amake'
make: *** [all] Error 2

I attach the doc/interpreter/octave.log file
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave.log
Type: application/octet-stream
Size: 3513 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091028/a304723c/attachment-0001.obj 

From octave at nomad.inbox5.com  Wed Oct 28 14:37:46 2009
From: octave at nomad.inbox5.com (Rik)
Date: Wed, 28 Oct 2009 12:37:46 -0700
Subject: gnulib and automake
In-Reply-To: <mailman.60.1256749435.23729.octave-maintainers@octave.org>
References: <mailman.60.1256749435.23729.octave-maintainers@octave.org>
Message-ID: <MTAwMDAwMC5ub21hZA.1256758674@quikprotect>

When running autogen.sh I get

calling libtoolize...
Remember to add `AC_PROG_LIBTOOL' to `configure.ac'.

and a little further down

calling automake...
libcruft/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
libcruft/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
libcruft/Makefile.am:26:   to `configure.ac' and run `aclocal' and
`autoconf' again.
libcruft/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac',
make sure
libcruft/Makefile.am:26:   its definition is in aclocal's search path.
liboctave/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
liboctave/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
liboctave/Makefile.am:26:   to `configure.ac' and run `aclocal' and
`autoconf' again.
liboctave/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac',
make sure
liboctave/Makefile.am:26:   its definition is in aclocal's search path.
src/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
src/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
src/Makefile.am:26:   to `configure.ac' and run `aclocal' and `autoconf'
again.
src/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
src/Makefile.am:26:   its definition is in aclocal's search path.

autogen.sh appears to succeed, but the next step of configure fails with

./configure: line 16887: syntax error near unexpected token `disable-static'
./configure: line 16887: `LT_INIT(disable-static)'

Adding AC_PROG_LIBTOOL to configure.ac silenced the warnings but did not
fix the issue with configure.

System is Linux Kubuntu 8.04.
automake-1.10
autoconf-2.61
libtool-1.5.26

--Rik


From jwe at octave.org  Wed Oct 28 14:49:09 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 15:49:09 -0400
Subject: gnulib and automake
In-Reply-To: <420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
Message-ID: <19176.41013.46982.260285@segfault.lan>

On 28-Oct-2009, Shai Ayal wrote:

| On Wed, Oct 28, 2009 at 7:07 PM, John W. Eaton <jwe at octave.org> wrote:
| > On 28-Oct-2009, Shai Ayal wrote:
| >
| > | > A preliminary changeset for the switch to automake is now available
| > | > here:
| > | >
| > | > ?http://jweaton.org/automake.gz
| > | >
| > | I get a 404 No found error for this URL
| >
| > Oops, it is http://jweaton.org/automake-diffs.gz
| It almost compiles for me except at the very end:
| ./octave.aux:4743: TeX capacity exceeded, sorry [save size=5000].
| @otherbackslash ->@let \=@realbackslash
| 
| @xrdef #1#2->{@indexnofonts @turnoffactive
|                                            @xdef @safexrefname {#1}}@expanda...
| l.4743 @xrdef{doc-getenv-pg}{567}

Does the following change fix the problem for you?

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091028/033aefbb/attachment.ksh 
-------------- next part --------------

jwe

From jwe at octave.org  Wed Oct 28 14:58:28 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 15:58:28 -0400
Subject: gnulib and automake
In-Reply-To: <MTAwMDAwMC5ub21hZA.1256758674@quikprotect>
References: <mailman.60.1256749435.23729.octave-maintainers@octave.org>
	<MTAwMDAwMC5ub21hZA.1256758674@quikprotect>
Message-ID: <19176.41572.922654.905436@segfault.lan>

On 28-Oct-2009, Rik wrote:

| When running autogen.sh I get
| 
| calling libtoolize...
| Remember to add `AC_PROG_LIBTOOL' to `configure.ac'.
| 
| and a little further down
| 
| calling automake...
| libcruft/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
| libcruft/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
| `AC_PROG_LIBTOOL'
| libcruft/Makefile.am:26:   to `configure.ac' and run `aclocal' and
| `autoconf' again.
| libcruft/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac',
| make sure
| libcruft/Makefile.am:26:   its definition is in aclocal's search path.
| liboctave/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
| liboctave/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
| `AC_PROG_LIBTOOL'
| liboctave/Makefile.am:26:   to `configure.ac' and run `aclocal' and
| `autoconf' again.
| liboctave/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac',
| make sure
| liboctave/Makefile.am:26:   its definition is in aclocal's search path.
| src/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
| src/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
| `AC_PROG_LIBTOOL'
| src/Makefile.am:26:   to `configure.ac' and run `aclocal' and `autoconf'
| again.
| src/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
| src/Makefile.am:26:   its definition is in aclocal's search path.
| 
| autogen.sh appears to succeed, but the next step of configure fails with
| 
| ./configure: line 16887: syntax error near unexpected token `disable-static'
| ./configure: line 16887: `LT_INIT(disable-static)'
| 
| Adding AC_PROG_LIBTOOL to configure.ac silenced the warnings but did not
| fix the issue with configure.
| 
| System is Linux Kubuntu 8.04.

It runs cleanly for me.

| automake-1.10

Given what S?ren Hauberg said earlier, this version is apparently too
old.  You need 1.11.  I already added a requirement for 1.11 in
configure.ac.

| libtool-1.5.26

I also have 

  $ libtool --version
  ltmain.sh (GNU libtool) 2.2.6
  Written by Gordon Matzigkeit <gord at gnu.ai.mit.edu>, 1996

so maybe 1.5.26 is also too old?  For now, I've added

  LT_PREREQ([2.2.6])

to configure.ac since that version is known to work, but could relax
that a bit if someone with an older version of libtool confirms that
it works without problems.

jwe


From shaiay at gmail.com  Wed Oct 28 15:14:36 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Wed, 28 Oct 2009 22:14:36 +0200
Subject: gnulib and automake
In-Reply-To: <19176.41013.46982.260285@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
Message-ID: <420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>

On Wed, Oct 28, 2009 at 9:49 PM, John W. Eaton <jwe at octave.org> wrote:
> On 28-Oct-2009, Shai Ayal wrote:
>
> | On Wed, Oct 28, 2009 at 7:07 PM, John W. Eaton <jwe at octave.org> wrote:
> | > On 28-Oct-2009, Shai Ayal wrote:
> | >
> | > | > A preliminary changeset for the switch to automake is now available
> | > | > here:
> | > | >
> | > | > ?http://jweaton.org/automake.gz
> | > | >
> | > | I get a 404 No found error for this URL
> | >
> | > Oops, it is http://jweaton.org/automake-diffs.gz
> | It almost compiles for me except at the very end:
> | ./octave.aux:4743: TeX capacity exceeded, sorry [save size=5000].
> | @otherbackslash ->@let \=@realbackslash
> |
> | @xrdef #1#2->{@indexnofonts @turnoffactive
> | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@xdef @safexrefname {#1}}@expanda...
> | l.4743 @xrdef{doc-getenv-pg}{567}
>
> Does the following change fix the problem for you?
>
>
> diff --git a/doc/interpreter/Makefile.am b/doc/interpreter/Makefile.am
> --- a/doc/interpreter/Makefile.am
> +++ b/doc/interpreter/Makefile.am
> @@ -31,6 +31,9 @@
> ?TEXINPUTS = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)"
> ?export TEXINPUTS
>
> +TEXMFCNF = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(TEXMFCNF)$(PATH_SEPARATOR)"
> +export TEXMFCNF
> +
> ?dist_man1_MANS = \
> ? mkoctfile.1 \
> ? octave-bug.1 \
>

Now the error is:
Making all in interpreter
make[1]: Entering directory `/home/shaia/hack/octave-amake/doc/interpreter'
../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'png');"
Makefile:582: *** Recursive variable `TEXMFCNF' references itself
(eventually).  Stop.
make[1]: Leaving directory `/home/shaia/hack/octave-amake/doc/interpreter'
make: *** [all-recursive] Error 1


From jwe at octave.org  Wed Oct 28 15:19:36 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 16:19:36 -0400
Subject: gnulib and automake
In-Reply-To: <420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
	<420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
Message-ID: <19176.42840.762102.66647@segfault.lan>

On 28-Oct-2009, Shai Ayal wrote:

| On Wed, Oct 28, 2009 at 9:49 PM, John W. Eaton <jwe at octave.org> wrote:
| > On 28-Oct-2009, Shai Ayal wrote:
| >
| > | On Wed, Oct 28, 2009 at 7:07 PM, John W. Eaton <jwe at octave.org> wrote:
| > | > On 28-Oct-2009, Shai Ayal wrote:
| > | >
| > | > | > A preliminary changeset for the switch to automake is now available
| > | > | > here:
| > | > | >
| > | > | > ?http://jweaton.org/automake.gz
| > | > | >
| > | > | I get a 404 No found error for this URL
| > | >
| > | > Oops, it is http://jweaton.org/automake-diffs.gz
| > | It almost compiles for me except at the very end:
| > | ./octave.aux:4743: TeX capacity exceeded, sorry [save size=5000].
| > | @otherbackslash ->@let \=@realbackslash
| > |
| > | @xrdef #1#2->{@indexnofonts @turnoffactive
| > | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@xdef @safexrefname {#1}}@expanda...
| > | l.4743 @xrdef{doc-getenv-pg}{567}
| >
| > Does the following change fix the problem for you?
| >
| >
| > diff --git a/doc/interpreter/Makefile.am b/doc/interpreter/Makefile.am
| > --- a/doc/interpreter/Makefile.am
| > +++ b/doc/interpreter/Makefile.am
| > @@ -31,6 +31,9 @@
| > ?TEXINPUTS = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)"
| > ?export TEXINPUTS
| >
| > +TEXMFCNF = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(TEXMFCNF)$(PATH_SEPARATOR)"
| > +export TEXMFCNF
| > +
| > ?dist_man1_MANS = \
| > ? mkoctfile.1 \
| > ? octave-bug.1 \
| >
| 
| Now the error is:
| Making all in interpreter
| make[1]: Entering directory `/home/shaia/hack/octave-amake/doc/interpreter'
| ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'png');"
| Makefile:582: *** Recursive variable `TEXMFCNF' references itself
| (eventually).  Stop.
| make[1]: Leaving directory `/home/shaia/hack/octave-amake/doc/interpreter'
| make: *** [all-recursive] Error 1

Try taking $(TEXMFCNF) out of the right hand side of that assignment,
or use := instead of = as the assignment operator.  I'm not sure what
the best solution is.  How often do people have TEXMFCNF set in the
environment?  OTOH, GNU Make accepts :=, but I don't think it is
portable (if we decide that matters).

jwe


From storrsjm at email.uc.edu  Wed Oct 28 15:27:17 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Wed, 28 Oct 2009 16:27:17 -0400
Subject: gnulib and automake
In-Reply-To: <420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
	<420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
Message-ID: <a0daad600910281327j1c0fcd5fpf2389c72618dd5c8@mail.gmail.com>

On Wed, Oct 28, 2009 at 3:49 PM, John W. Eaton <jwe at octave.org> wrote:
| Does the following change fix the problem for you?

On Wed, Oct 28, 2009 at 4:14 PM, Shai Ayal <shaiay at gmail.com> wrote:
> Now the error is:
> Making all in interpreter
> make[1]: Entering directory `/home/shaia/hack/octave-amake/doc/interpreter'
> ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'png');"
> Makefile:582: *** Recursive variable `TEXMFCNF' references itself
> (eventually).  Stop.
> make[1]: Leaving directory `/home/shaia/hack/octave-amake/doc/interpreter'
> make: *** [all-recursive] Error 1

I'm seeing the same (Ubuntu 9.10rc). I don't know if it's related to
the TeX memory error but prior to adding the TEXMFCNF change (but with
automake-diff applied), I noticed many errors flying by that look like
this:

	rm -rf $backupdir; exit $rc
../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'eps');"

../../run-octave -f -q -H -p . --eval "geometryimages ('triplot', 'eps');"

../../run-octave -f -q -H -p . --eval "geometryimages ('griddata', 'eps');"

../../run-octave -f -q -H -p . --eval "geometryimages ('convhull', 'eps');"

Output completed.  Verifying that all points are below 7.4e-15 of
all facets.  Will make 7381 distance computations.

multiplot> plot "-" binary format='%float64' record=62 using ($1):($2)
axes x1y1 title "" with lines linestyle 1 , "-" binary
format='%float64' record=121 using ($1):($2) axes x1y1 title "" with
linestyle 2 ;


                                                                ^
           line 0: expecting 'lines', 'points', 'linespoints', 'dots',
'impulses',
	'yerrorbars', 'xerrorbars', 'xyerrorbars', 'steps', 'fsteps',
	'histeps', 'filledcurves', 'boxes', 'boxerrorbars', 'boxxyerrorbars',
	'vectors', 'financebars', 'candlesticks', 'errorlines', 'xerrorlines',
	'yerrorlines', 'xyerrorlines', 'pm3d', 'labels', 'histograms',
	 'image', 'rgbimage'


multiplot> f??ffffff???]#rp??
            ^
           line 0: invalid character


multiplot> ?????????????????
           ^
           line 0: invalid character


From jwe at octave.org  Wed Oct 28 16:10:35 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 17:10:35 -0400
Subject: gnulib and automake
In-Reply-To: <a0daad600910281327j1c0fcd5fpf2389c72618dd5c8@mail.gmail.com>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
	<420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
	<a0daad600910281327j1c0fcd5fpf2389c72618dd5c8@mail.gmail.com>
Message-ID: <19176.45899.330498.302231@segfault.lan>

On 28-Oct-2009, Judd Storrs wrote:

| I'm seeing the same (Ubuntu 9.10rc). I don't know if it's related to
| the TeX memory error but prior to adding the TEXMFCNF change (but with
| automake-diff applied), I noticed many errors flying by that look like
| this:
| 
| 	rm -rf $backupdir; exit $rc
| ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'eps');"
| 
| ../../run-octave -f -q -H -p . --eval "geometryimages ('triplot', 'eps');"
| 
| ../../run-octave -f -q -H -p . --eval "geometryimages ('griddata', 'eps');"
| 
| ../../run-octave -f -q -H -p . --eval "geometryimages ('convhull', 'eps');"
| 
| Output completed.  Verifying that all points are below 7.4e-15 of
| all facets.  Will make 7381 distance computations.
| 
| multiplot> plot "-" binary format='%float64' record=62 using ($1):($2)
| axes x1y1 title "" with lines linestyle 1 , "-" binary
| format='%float64' record=121 using ($1):($2) axes x1y1 title "" with
| linestyle 2 ;
| 
| 
|                                                                 ^
|            line 0: expecting 'lines', 'points', 'linespoints', 'dots',
| 'impulses',
| 	'yerrorbars', 'xerrorbars', 'xyerrorbars', 'steps', 'fsteps',
| 	'histeps', 'filledcurves', 'boxes', 'boxerrorbars', 'boxxyerrorbars',
| 	'vectors', 'financebars', 'candlesticks', 'errorlines', 'xerrorlines',
| 	'yerrorlines', 'xyerrorlines', 'pm3d', 'labels', 'histograms',
| 	 'image', 'rgbimage'
| 
| 
| multiplot> f$,3u=(B?ffffff$,3u=u=u=(B]#rp$,3u=(B?
|             ^
|            line 0: invalid character
| 
| 
| multiplot> $,3u=(B?$,3u=u=u=u=u=u=u=u=u=u=u=”u=u=(B?
|            ^
|            line 0: invalid character

What version of gnuplot do you have?  I recently upgraded and gnuplot
4.2.6 appeared on my system and now I'm seeing a similar problem.
This problem seems to be independent of my automake changes though...
Can you confirm that?  If you have a build using the sources before my
patch, then cd to the doc/interpreter directory in your build tree and
try

  rm -f *.eps
  make

and see if you see similar problems.

jwe


From Thomas.Treichl at gmx.net  Wed Oct 28 16:45:34 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Wed, 28 Oct 2009 22:45:34 +0100
Subject: gnulib and automake
In-Reply-To: <19176.31314.572679.656960@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>
	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
Message-ID: <4AE8BB7E.6060103@gmx.net>

John W. Eaton schrieb:
> On 28-Oct-2009, Shai Ayal wrote:
> 
> | > A preliminary changeset for the switch to automake is now available
> | > here:
> | >
> | >  http://jweaton.org/automake.gz
> | >
> | I get a 404 No found error for this URL
> 
> Oops, it is http://jweaton.org/automake-diffs.gz
> 
> jwe

Hi John,

on my Mac OS X 10.4 system I currently have two problems (sources still 
compiling this night, don't know if there are further problems)... The first 
thing is that in all subdirectories of libcruft eg. libcruft/amos etc. there 
don't exist ".deps" directories and they also cannot be build on my system (I 
currently have no idea what causes this or which command is doing this). The 
error looks like this (without any further information about which command calls 
"cp" or such)

   Making all in libcruft
   cp: illegal option -- d
   usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
          cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN directory
   mv: rename amos/#inst.16473# to amos/.deps: No such file or directory
   /bin/sh: line 1: amos/.deps/.dirstamp: No such file or directory
   make[2]: *** [amos/.deps/.dirstamp] Error 1
   make[1]: *** [all-recursive] Error 1
   make: *** [all] Error 2

If I create all ".deps" directories by hand in all subdirectories of libcruft 
then I also can make libcruft.

At the moment the second problem already is in the liboctave directory and is

/bin/sh ../libtool --tag=CXX --silent  --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I..  -I../libcruft/misc -arch i386 -O2 -fforce-addr -mfpmath=sse,387 
-march=prescott -ggdb -isysroot /Developer/SDKs/MacOSX10.4u.sdk 
-I/Applications/Octave.app/Contents/Resources/include 
-I/Applications/Octave.app/Contents/Resources/include/GraphicsMagick 
-I/tmp/deps-i386/include -arch i386 -O2 -fforce-addr -mfpmath=sse,387 
-march=prescott -ggdb -isysroot /Developer/SDKs/MacOSX10.4u.sdk 
-I/Applications/Octave.app/Contents/Resources/include 
-I/Applications/Octave.app/Contents/Resources/include/GraphicsMagick 
-DHAVE_CONFIG_H -mieee-fp -I/tmp/deps-i386/include/freetype2 
-I/tmp/deps-i386/include -I/tmp/deps-i386/include   -Wall -W -Wshadow 
-Wold-style-cast -Wformat -arch i386 -O2 -fforce-addr -mfpmath=sse,387 
-march=prescott -ggdb -isysroot /Developer/SDKs/MacOSX10.4u.sdk 
-I/Applications/Octave.app/Contents/Resources/include 
-I/Applications/Octave.app/Contents/Resources/include/GraphicsMagick 
-D_THREAD_SAFE  -arch i386 -O2 -fforce-addr -mfpmath=sse,387 -march=prescott 
-ggdb -isysroot /Developer/SDKs/MacOSX10.4u.sdk 
-I/Applications/Octave.app/Contents/Resources/include 
-I/Applications/Octave.app/Contents/Resources/include/GraphicsMagick -MT 
PermMatrix.lo -MD -MP -MF $depbase.Tpo -c -o PermMatrix.lo PermMatrix.cc &&\
mv -f $depbase.Tpo $depbase.Plo
PermMatrix.cc:29:19: error: error.h: No such file or directory
make[3]: *** [PermMatrix.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I removed the line with "error.h" from PermMatrix.cc and continued compilation.

Best regards

   Thomas

From jwe at octave.org  Wed Oct 28 16:50:38 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 17:50:38 -0400
Subject: gnulib and automake
In-Reply-To: <4AE8BB7E.6060103@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan> <4AE8BB7E.6060103@gmx.net>
Message-ID: <19176.48302.817065.387989@segfault.lan>

On 28-Oct-2009, Thomas Treichl wrote:

| on my Mac OS X 10.4 system I currently have two problems (sources still 
| compiling this night, don't know if there are further problems)... The first 
| thing is that in all subdirectories of libcruft eg. libcruft/amos etc. there 
| don't exist ".deps" directories and they also cannot be build on my system (I 
| currently have no idea what causes this or which command is doing this). The 
| error looks like this (without any further information about which command calls 
| "cp" or such)
| 
|    Making all in libcruft
|    cp: illegal option -- d
|    usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
|           cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN directory
|    mv: rename amos/#inst.16473# to amos/.deps: No such file or directory
|    /bin/sh: line 1: amos/.deps/.dirstamp: No such file or directory
|    make[2]: *** [amos/.deps/.dirstamp] Error 1
|    make[1]: *** [all-recursive] Error 1
|    make: *** [all] Error 2
| 
| If I create all ".deps" directories by hand in all subdirectories of libcruft 
| then I also can make libcruft.

I suspect a libtool or automake problem.  What versions do you have?

jwe

From storrsjm at email.uc.edu  Wed Oct 28 16:55:34 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Wed, 28 Oct 2009 17:55:34 -0400
Subject: gnulib and automake
In-Reply-To: <19176.45899.330498.302231@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
	<420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
	<a0daad600910281327j1c0fcd5fpf2389c72618dd5c8@mail.gmail.com>
	<19176.45899.330498.302231@segfault.lan>
Message-ID: <a0daad600910281455s5152e2b2jeb8a9783a8cff066@mail.gmail.com>

On Wed, Oct 28, 2009 at 4:19 PM, John W. Eaton <jwe at octave.org> wrote:
>
> What version of gnuplot do you have? ?I recently upgraded and gnuplot
> 4.2.6 appeared on my system and now I'm seeing a similar problem.
> This problem seems to be independent of my automake changes though...
> Can you confirm that?

I have gnuplot 4.2.5 installed. I agree it does not seem related to
the automake changes. From otherwise identical sources (without the
automake patch applied) I have similar problems.

On Wed, Oct 28, 2009 at 4:19 PM, John W. Eaton <jwe at octave.org> wrote:
> Try taking $(TEXMFCNF) out of the right hand side

This seems to have worked for me.

I compared patched (automake-diff + TEXMFCNF) vs unmodified
9759:97de6c916498. Both produced the same 'make check' results.

Some files were installed by the unmodified 9759:97de6c916498 but were
not installed with the automake patch:

octave/include/octave-3.3.50+/octave/ArrayN.h
octave/share/octave/3.3.50+/m/optimization/PKG_ADD.t

The patched version installed these files that were not installed by
the unmodified version:

octave/share/info/liboctave.info
octave/share/info/OctaveFAQ.info

As expected there were some differences in installed libraries:

patched:

octave/lib/octave-3.3.50+/libcruft-3.3.50+.so
octave/lib/octave-3.3.50+/libcruft.la
octave/lib/octave-3.3.50+/liboctave-3.3.50+.so
octave/lib/octave-3.3.50+/liboctave.la
octave/lib/octave-3.3.50+/liboctinterp-3.3.50+.so
octave/lib/octave-3.3.50+/liboctinterp.la

unmodified:

octave/lib/octave-3.3.50+/libcruft.so.3.3.50+
octave/lib/octave-3.3.50+/liboctave.so.3.3.50+
octave/lib/octave-3.3.50+/liboctinterp.so.3.3.50+


From storrsjm at email.uc.edu  Wed Oct 28 17:01:42 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Wed, 28 Oct 2009 18:01:42 -0400
Subject: gnulib and automake
In-Reply-To: <a0daad600910281455s5152e2b2jeb8a9783a8cff066@mail.gmail.com>
References: <19121.21838.419944.184758@segfault.lan>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
	<420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
	<a0daad600910281327j1c0fcd5fpf2389c72618dd5c8@mail.gmail.com>
	<19176.45899.330498.302231@segfault.lan>
	<a0daad600910281455s5152e2b2jeb8a9783a8cff066@mail.gmail.com>
Message-ID: <a0daad600910281501l242eb8c1r90ea250a531bd0f1@mail.gmail.com>

On Wed, Oct 28, 2009 at 5:55 PM, Judd Storrs <storrsjm at email.uc.edu> wrote:
> The patched version installed these files that were not installed by
> the unmodified version:
>
> octave/share/info/liboctave.info
> octave/share/info/OctaveFAQ.info

I missed these ones that were also installed by the automake version
but not the original:

octave/include/octave-3.3.50+/octave/op-dms-template.cc
octave/include/octave-3.3.50+/octave/op-dm-template.cc
octave/include/octave-3.3.50+/octave/op-int.h
octave/include/octave-3.3.50+/octave/op-pm-template.cc
octave/include/octave-3.3.50+/octave/ov-bool-mat.cc

Sorry,

--judd

From jwe at octave.org  Wed Oct 28 18:49:33 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 19:49:33 -0400
Subject: gnulib and automake
In-Reply-To: <a0daad600910281501l242eb8c1r90ea250a531bd0f1@mail.gmail.com>
References: <19121.21838.419944.184758@segfault.lan>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
	<420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
	<a0daad600910281327j1c0fcd5fpf2389c72618dd5c8@mail.gmail.com>
	<19176.45899.330498.302231@segfault.lan>
	<a0daad600910281455s5152e2b2jeb8a9783a8cff066@mail.gmail.com>
	<a0daad600910281501l242eb8c1r90ea250a531bd0f1@mail.gmail.com>
Message-ID: <19176.55437.861067.288089@segfault.lan>

On 28-Oct-2009, Judd Storrs wrote:

| On Wed, Oct 28, 2009 at 5:55 PM, Judd Storrs <storrsjm at email.uc.edu> wrote:
| > The patched version installed these files that were not installed by
| > the unmodified version:
| >
| > octave/share/info/liboctave.info
| > octave/share/info/OctaveFAQ.info
| 
| I missed these ones that were also installed by the automake version
| but not the original:
| 
| octave/include/octave-3.3.50+/octave/op-dms-template.cc
| octave/include/octave-3.3.50+/octave/op-dm-template.cc
| octave/include/octave-3.3.50+/octave/op-int.h
| octave/include/octave-3.3.50+/octave/op-pm-template.cc
| octave/include/octave-3.3.50+/octave/ov-bool-mat.cc

I think these should be installed since they provide template
declarations and definitions.

jwe


From jwe at octave.org  Wed Oct 28 18:56:57 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 19:56:57 -0400
Subject: gnulib and automake
In-Reply-To: <a0daad600910281455s5152e2b2jeb8a9783a8cff066@mail.gmail.com>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
	<420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
	<a0daad600910281327j1c0fcd5fpf2389c72618dd5c8@mail.gmail.com>
	<19176.45899.330498.302231@segfault.lan>
	<a0daad600910281455s5152e2b2jeb8a9783a8cff066@mail.gmail.com>
Message-ID: <19176.55881.932971.950316@segfault.lan>

On 28-Oct-2009, Judd Storrs wrote:

| Some files were installed by the unmodified 9759:97de6c916498 but were
| not installed with the automake patch:
| 
| octave/include/octave-3.3.50+/octave/ArrayN.h

OK, I added ArrayN.h back in to the MATRIX_INC list in
liboctave/Makefile.am.

| octave/share/octave/3.3.50+/m/optimization/PKG_ADD.t

That is a temporary file created during the build and should not be
installed.

| The patched version installed these files that were not installed by
| the unmodified version:
| 
| octave/share/info/liboctave.info
| octave/share/info/OctaveFAQ.info

I don't really want these to be installed, but I couldn't figure out a
way to tell autoconf that the pdf, ps, dvi, and info versions of these
files should all be built and distributed, but not installed.  I don't
know whether that is just pilot error or a bug/misfeature in
automake.  It would be great if someone could figure out how to get
this to work.  Otherwise, I guess we'll just install these files.
Though maybe the formatted versions of the liboctave document
shouldn't be built at all...

| As expected there were some differences in installed libraries:
| 
| patched:
| 
| octave/lib/octave-3.3.50+/libcruft-3.3.50+.so
| octave/lib/octave-3.3.50+/libcruft.la
| octave/lib/octave-3.3.50+/liboctave-3.3.50+.so
| octave/lib/octave-3.3.50+/liboctave.la
| octave/lib/octave-3.3.50+/liboctinterp-3.3.50+.so
| octave/lib/octave-3.3.50+/liboctinterp.la
| 
| unmodified:
| 
| octave/lib/octave-3.3.50+/libcruft.so.3.3.50+
| octave/lib/octave-3.3.50+/liboctave.so.3.3.50+
| octave/lib/octave-3.3.50+/liboctinterp.so.3.3.50+

Yeah, libtool uses a different naming scheme.  I don't think it
matters much.

jwe

From jwe at octave.org  Wed Oct 28 19:01:15 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 28 Oct 2009 20:01:15 -0400
Subject: gnulib and automake
In-Reply-To: <4AE8BB7E.6060103@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan> <4AE8BB7E.6060103@gmx.net>
Message-ID: <19176.56139.673263.108980@segfault.lan>

On 28-Oct-2009, Thomas Treichl wrote:

| I removed the line with "error.h" from PermMatrix.cc and continued compilation.

I checked in the following change.

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

Thanks,

jwe

From shaiay at gmail.com  Wed Oct 28 23:37:08 2009
From: shaiay at gmail.com (Shai Ayal)
Date: Thu, 29 Oct 2009 06:37:08 +0200
Subject: gnulib and automake
In-Reply-To: <19176.42840.762102.66647@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
	<420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
	<19176.42840.762102.66647@segfault.lan>
Message-ID: <420fb9e60910282137i2a830b88m1b7d00ed30912c5a@mail.gmail.com>

On Wed, Oct 28, 2009 at 10:19 PM, John W. Eaton <jwe at octave.org> wrote:
> On 28-Oct-2009, Shai Ayal wrote:
>
> | On Wed, Oct 28, 2009 at 9:49 PM, John W. Eaton <jwe at octave.org> wrote:
> | > On 28-Oct-2009, Shai Ayal wrote:
> | >
> | > | On Wed, Oct 28, 2009 at 7:07 PM, John W. Eaton <jwe at octave.org> wrote:
> | > | > On 28-Oct-2009, Shai Ayal wrote:
> | > | >
> | > | > | > A preliminary changeset for the switch to automake is now available
> | > | > | > here:
> | > | > | >
> | > | > | > ?http://jweaton.org/automake.gz
> | > | > | >
> | > | > | I get a 404 No found error for this URL
> | > | >
> | > | > Oops, it is http://jweaton.org/automake-diffs.gz
> | > | It almost compiles for me except at the very end:
> | > | ./octave.aux:4743: TeX capacity exceeded, sorry [save size=5000].
> | > | @otherbackslash ->@let \=@realbackslash
> | > |
> | > | @xrdef #1#2->{@indexnofonts @turnoffactive
> | > | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@xdef @safexrefname {#1}}@expanda...
> | > | l.4743 @xrdef{doc-getenv-pg}{567}
> | >
> | > Does the following change fix the problem for you?
> | >
> | >
> | > diff --git a/doc/interpreter/Makefile.am b/doc/interpreter/Makefile.am
> | > --- a/doc/interpreter/Makefile.am
> | > +++ b/doc/interpreter/Makefile.am
> | > @@ -31,6 +31,9 @@
> | > ?TEXINPUTS = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)"
> | > ?export TEXINPUTS
> | >
> | > +TEXMFCNF = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(TEXMFCNF)$(PATH_SEPARATOR)"
> | > +export TEXMFCNF
> | > +
> | > ?dist_man1_MANS = \
> | > ? mkoctfile.1 \
> | > ? octave-bug.1 \
> | >
> |
> | Now the error is:
> | Making all in interpreter
> | make[1]: Entering directory `/home/shaia/hack/octave-amake/doc/interpreter'
> | ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'png');"
> | Makefile:582: *** Recursive variable `TEXMFCNF' references itself
> | (eventually). ?Stop.
> | make[1]: Leaving directory `/home/shaia/hack/octave-amake/doc/interpreter'
> | make: *** [all-recursive] Error 1
>
> Try taking $(TEXMFCNF) out of the right hand side of that assignment,
> or use := instead of = as the assignment operator. ?I'm not sure what
> the best solution is. ?How often do people have TEXMFCNF set in the
> environment? ?OTOH, GNU Make accepts :=, but I don't think it is
> portable (if we decide that matters).

Using := instead of = fixes the problem

Shai


From octave at nomad.inbox5.com  Thu Oct 29 00:31:13 2009
From: octave at nomad.inbox5.com (Rik)
Date: Wed, 28 Oct 2009 22:31:13 -0700
Subject: gnulib and automake
In-Reply-To: <19176.41572.922654.905436@segfault.lan>
References: <mailman.60.1256749435.23729.octave-maintainers@octave.org>	<MTAwMDAwMC5ub21hZA.1256758674@quikprotect>
	<19176.41572.922654.905436@segfault.lan>
Message-ID: <MTAwMDA0OC5ub21hZA.1256794280@quikprotect>

John W. Eaton wrote:
> It runs cleanly for me.
>
> | automake-1.10
>
> Given what S?ren Hauberg said earlier, this version is apparently too
> old.  You need 1.11.  I already added a requirement for 1.11 in
> configure.ac.
>
> | libtool-1.5.26
>
> I also have 
>
>   $ libtool --version
>   ltmain.sh (GNU libtool) 2.2.6
>   Written by Gordon Matzigkeit <gord at gnu.ai.mit.edu>, 1996
>
> so maybe 1.5.26 is also too old?  For now, I've added
>
>   LT_PREREQ([2.2.6])
>
> to configure.ac since that version is known to work, but could relax
> that a bit if someone with an older version of libtool confirms that
> it works without problems.
>
> jwe
>
>   
I succeeded in compiling except for the gnuplot image problem already
mentioned.

System Details
32-bit Intel Core Duo
Kubuntu Hardy Heron 8.04
automake-1.11
autoconf-2.62
libtool-2.2.6

I went backwards with libtool versions and confirmed that libtool-2.2.4
and libtool-2.2.2 work so the LT_PREREQ can be changed to 2.2.2.  It is
the 1.5.X series which doesn't work. 

--Rik

From jwe at octave.org  Thu Oct 29 00:33:10 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 29 Oct 2009 01:33:10 -0400
Subject: gnulib and automake
In-Reply-To: <MTAwMDA0OC5ub21hZA.1256794280@quikprotect>
References: <mailman.60.1256749435.23729.octave-maintainers@octave.org>
	<MTAwMDAwMC5ub21hZA.1256758674@quikprotect>
	<19176.41572.922654.905436@segfault.lan>
	<MTAwMDA0OC5ub21hZA.1256794280@quikprotect>
Message-ID: <19177.10518.118001.117576@segfault.lan>

On 28-Oct-2009, Rik wrote:

| I succeeded in compiling except for the gnuplot image problem already
| mentioned.
| 
| System Details
| 32-bit Intel Core Duo
| Kubuntu Hardy Heron 8.04
| automake-1.11
| autoconf-2.62
| libtool-2.2.6
| 
| I went backwards with libtool versions and confirmed that libtool-2.2.4
| and libtool-2.2.2 work so the LT_PREREQ can be changed to 2.2.2.  It is
| the 1.5.X series which doesn't work. 

OK, I changed the version requirement to 2.2.2 in my sources.

Thanks,

jwe

From marco.caliari at univr.it  Thu Oct 29 08:03:54 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Thu, 29 Oct 2009 14:03:54 +0100 (CET)
Subject: help directory_name
Message-ID: <alpine.DEB.1.00.0910291334380.9254@profs.sci.univr.it>

Dear maintainers,

if your current working directory is, e.g., /home/caliari/analysis and you 
type

help analysis

you should get the help text for Contents.m (if present). This does not 
work in Octave 3.2.3

octave:1> help analysis
error: help: `analysis' not found
octave:1> pwd
ans = /home/caliari/analysis
octave:2> ls
Contents.m

despite the function do_contents in help.m. It is not difficult to fix 
this problem. But, there is another problem: if you type

help name

in Matlab, and name is more than once in your path, then you get the 
help text for all the Contents.m therein. In Octave there is 
find_dir_in_path. First of all, it does not find name in the current 
working directory:

octave:1> pwd
ans = /home/caliari/analysis
octave:2> path

Octave's search path contains the following directories:

. 
/usr/local/share/octave/3.2.3/m/statistics/base
[CUT...]
octave:3> find_dir_in_path ('analysis')
ans =

and, if name is twice in your path, it finds only one

octave:1> find_dir_in_path('geometry')
ans = /usr/local/share/octave/3.2.3/m/geometry
octave:2> addpath('/home/caliari/geometry')
octave:3> find_dir_in_path('geometry')
ans = /home/caliari/geometry

I think that the right fix for help directory_name should be based on a 
fix for find_dir_in_path (which I'm not able to do).

Best regards,

Marco

From Thomas.Treichl at gmx.net  Thu Oct 29 14:26:29 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Thu, 29 Oct 2009 20:26:29 +0100
Subject: gnulib and automake
In-Reply-To: <19176.48302.817065.387989@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>	<19176.31314.572679.656960@segfault.lan>	<4AE8BB7E.6060103@gmx.net>
	<19176.48302.817065.387989@segfault.lan>
Message-ID: <4AE9EC65.9090009@gmx.net>

John W. Eaton schrieb:
> On 28-Oct-2009, Thomas Treichl wrote:
> 
> | on my Mac OS X 10.4 system I currently have two problems (sources still 
> | compiling this night, don't know if there are further problems)... The first 
> | thing is that in all subdirectories of libcruft eg. libcruft/amos etc. there 
> | don't exist ".deps" directories and they also cannot be build on my system (I 
> | currently have no idea what causes this or which command is doing this). The 
> | error looks like this (without any further information about which command calls 
> | "cp" or such)
> | 
> |    Making all in libcruft
> |    cp: illegal option -- d
> |    usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
> |           cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN directory
> |    mv: rename amos/#inst.16473# to amos/.deps: No such file or directory
> |    /bin/sh: line 1: amos/.deps/.dirstamp: No such file or directory
> |    make[2]: *** [amos/.deps/.dirstamp] Error 1
> |    make[1]: *** [all-recursive] Error 1
> |    make: *** [all] Error 2
> | 
> | If I create all ".deps" directories by hand in all subdirectories of libcruft 
> | then I also can make libcruft.
> 
> I suspect a libtool or automake problem.  What versions do you have?

Yesterday I installed the newest versions from both

   which libtool;  libtool  --version
   /usr/local/bin/libtool
   ltmain.sh (GNU libtool) 2.2.6
   Written by Gordon Matzigkeit <gord at gnu.ai.mit.edu>, 1996

   which automake; automake --version
   /usr/local/bin/automake
   automake (GNU automake) 1.11
   Copyright (C) 2009 Free Software Foundation, Inc.
   License GPLv2+: GNU GPL version 2 or later

My build.log told me that compilation was successful last night but the Octave 
binary is broken - so the process stopped in the doc directory when trying to 
create the graphics files. I think that my mach-o/dyld interface is broken now, 
cf. my short Octave session

   bash$ ./run-octave --quiet
   error: unique: got NSObjectFileImageReturnCode 2
   error: called from:
   error: /Users/Thomas/Development/octave.am/scripts/set/unique.m at line 108,
   column 9
   error: /Users/Thomas/Development/octave.am/scripts/optimization/__all_opts__.m
   at line 56, column 11
   error: /Users/Thomas/Development/octave.am/scripts/optimization/PKG_ADD at
   line 1, column 0
   octave:1> which reshape
   `reshape' is a built-in function
   octave:2> which repmat
   `repmat' is a function from the file
   /Users/Thomas/Development/octave.am/scripts/general/repmat.m
   octave:3> which cellfun
   error: __which__: got NSObjectFileImageReturnCode 2
   error: called from:
   error: /Users/Thomas/Development/octave.am/scripts/help/which.m at line 27,
   column 7
   octave:3>

I think the easiest thing for me now would be that I change the configure.ac 
file and that I try to compile against dlopen instead of dyld...

   Thomas


From jwe at octave.org  Thu Oct 29 14:38:51 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 29 Oct 2009 15:38:51 -0400
Subject: gnulib and automake
In-Reply-To: <4AE9EC65.9090009@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan> <4AE8BB7E.6060103@gmx.net>
	<19176.48302.817065.387989@segfault.lan> <4AE9EC65.9090009@gmx.net>
Message-ID: <19177.61259.8866.567112@segfault.lan>

On 29-Oct-2009, Thomas Treichl wrote:

| I think the easiest thing for me now would be that I change the configure.ac 
| file and that I try to compile against dlopen instead of dyld...

Does libtool try to use dyld by default?  How do you tell it to use
dlopen instead?

jwe

From Thomas.Treichl at gmx.net  Thu Oct 29 14:46:18 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Thu, 29 Oct 2009 20:46:18 +0100
Subject: gnulib and automake
In-Reply-To: <19177.61259.8866.567112@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>	<19176.31314.572679.656960@segfault.lan>	<4AE8BB7E.6060103@gmx.net>	<19176.48302.817065.387989@segfault.lan>	<4AE9EC65.9090009@gmx.net>
	<19177.61259.8866.567112@segfault.lan>
Message-ID: <4AE9F10A.4000803@gmx.net>

John W. Eaton schrieb:
> On 29-Oct-2009, Thomas Treichl wrote:
> 
> | I think the easiest thing for me now would be that I change the configure.ac 
> | file and that I try to compile against dlopen instead of dyld...
> 
> Does libtool try to use dyld by default?  How do you tell it to use
> dlopen instead?

I'm not familiar with the details now (this was before your changes to 
automake), but if I now change configure.ac like I already described here

http://www.nabble.com/Changeset-Mac:-Use-dlopen-instead-of-dyld-per-default-td25264111.html

then I finally get this result from ./configure:

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

Per default (_without_ any changes at all) I get:

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

So I expect that I'm doing everything correctly now, too?

   Thomas

From jwe at octave.org  Thu Oct 29 14:51:49 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 29 Oct 2009 15:51:49 -0400
Subject: gnulib and automake
In-Reply-To: <4AE9F10A.4000803@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan> <4AE8BB7E.6060103@gmx.net>
	<19176.48302.817065.387989@segfault.lan> <4AE9EC65.9090009@gmx.net>
	<19177.61259.8866.567112@segfault.lan> <4AE9F10A.4000803@gmx.net>
Message-ID: <19177.62037.229499.434039@segfault.lan>

On 29-Oct-2009, Thomas Treichl wrote:

| John W. Eaton schrieb:
| > On 29-Oct-2009, Thomas Treichl wrote:
| > 
| > | I think the easiest thing for me now would be that I change the configure.ac 
| > | file and that I try to compile against dlopen instead of dyld...
| > 
| > Does libtool try to use dyld by default?  How do you tell it to use
| > dlopen instead?
| 
| I'm not familiar with the details now (this was before your changes to 
| automake), but if I now change configure.ac like I already described here
| 
| http://www.nabble.com/Changeset-Mac:-Use-dlopen-instead-of-dyld-per-default-td25264111.html
| 
| then I finally get this result from ./configure:
| 
|    Do internal array bounds checking:  false
|    Build static libraries:             false
|    Build shared libraries:             true
|    Dynamic Linking:                    true (dlopen)
|    Include support for GNU readline:   true
|    64-bit array dims and indexing:     false
| 
| Per default (_without_ any changes at all) I get:
| 
|    Do internal array bounds checking:  false
|    Build static libraries:             false
|    Build shared libraries:             true
|    Dynamic Linking:                    true (dyld)
|    Include support for GNU readline:   true
|    64-bit array dims and indexing:     false
| 
| So I expect that I'm doing everything correctly now, too?

I would be surprised if this has any effect on the way .oct files are
created now, because they are constructed with libtool (as described
in the post that started this thread).  The configure script still has
the code that sets up Octave's old shared-library creation variables,
but they are no longer used to compile anything.  The plan is to
remove this code from the configure script once mkoctfile has also
been converted to use use libtool.

jwe

From jwe at octave.org  Thu Oct 29 15:49:10 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 29 Oct 2009 16:49:10 -0400
Subject: gnulib and automake
In-Reply-To: <19177.62037.229499.434039@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan> <4AE8BB7E.6060103@gmx.net>
	<19176.48302.817065.387989@segfault.lan> <4AE9EC65.9090009@gmx.net>
	<19177.61259.8866.567112@segfault.lan> <4AE9F10A.4000803@gmx.net>
	<19177.62037.229499.434039@segfault.lan>
Message-ID: <19177.65478.733895.188522@segfault.lan>

On 29-Oct-2009, John W. Eaton wrote:

| On 29-Oct-2009, Thomas Treichl wrote:
| 
| | John W. Eaton schrieb:
| | > On 29-Oct-2009, Thomas Treichl wrote:
| | > 
| | > | I think the easiest thing for me now would be that I change the configure.ac 
| | > | file and that I try to compile against dlopen instead of dyld...
| | > 
| | > Does libtool try to use dyld by default?  How do you tell it to use
| | > dlopen instead?
| | 
| | I'm not familiar with the details now (this was before your changes to 
| | automake), but if I now change configure.ac like I already described here
| | 
| | http://www.nabble.com/Changeset-Mac:-Use-dlopen-instead-of-dyld-per-default-td25264111.html
| | 
| | then I finally get this result from ./configure:
| | 
| |    Do internal array bounds checking:  false
| |    Build static libraries:             false
| |    Build shared libraries:             true
| |    Dynamic Linking:                    true (dlopen)
| |    Include support for GNU readline:   true
| |    64-bit array dims and indexing:     false
| | 
| | Per default (_without_ any changes at all) I get:
| | 
| |    Do internal array bounds checking:  false
| |    Build static libraries:             false
| |    Build shared libraries:             true
| |    Dynamic Linking:                    true (dyld)
| |    Include support for GNU readline:   true
| |    64-bit array dims and indexing:     false
| | 
| | So I expect that I'm doing everything correctly now, too?
| 
| I would be surprised if this has any effect on the way .oct files are
| created now, because they are constructed with libtool (as described
| in the post that started this thread).  The configure script still has
| the code that sets up Octave's old shared-library creation variables,
| but they are no longer used to compile anything.  The plan is to
| remove this code from the configure script once mkoctfile has also
| been converted to use use libtool.

Sorry, maybe I misunderstood what the problem was.  Looking at your
patch (duh, should have done that before I replied the first time) it
doesn't change the way .oct files are created, but does change the way
they are opened, correct?  If so, then yes, please try this and see if
it works to use the dlopen interface to open the .oct files that are
created with libtool.  If so, then yes, I think this change should be
applied.

Thanks, and sorry for the confusion...

jwe

From Thomas.Treichl at gmx.net  Thu Oct 29 16:31:30 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Thu, 29 Oct 2009 22:31:30 +0100
Subject: gnulib and automake
In-Reply-To: <19177.65478.733895.188522@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>	<19176.31314.572679.656960@segfault.lan>	<4AE8BB7E.6060103@gmx.net>	<19176.48302.817065.387989@segfault.lan>	<4AE9EC65.9090009@gmx.net>	<19177.61259.8866.567112@segfault.lan>	<4AE9F10A.4000803@gmx.net>	<19177.62037.229499.434039@segfault.lan>
	<19177.65478.733895.188522@segfault.lan>
Message-ID: <4AEA09B2.2090804@gmx.net>

John W. Eaton schrieb:
> | I would be surprised if this has any effect on the way .oct files are
> | created now, because they are constructed with libtool (as described
> | in the post that started this thread).  The configure script still has
> | the code that sets up Octave's old shared-library creation variables,
> | but they are no longer used to compile anything.  The plan is to
> | remove this code from the configure script once mkoctfile has also
> | been converted to use use libtool.
> 
> Sorry, maybe I misunderstood what the problem was.  Looking at your
> patch (duh, should have done that before I replied the first time) it
> doesn't change the way .oct files are created, but does change the way
> they are opened, correct?  If so, then yes, please try this and see if
> it works to use the dlopen interface to open the .oct files that are
> created with libtool.  If so, then yes, I think this change should be
> applied.
> 
> Thanks, and sorry for the confusion...

No problem, and yes, it was the idea to change the way *.oct files are loaded on 
MacOSX and not how *.oct files are created. And here are the good news: This 
change was one of the right things to do and it solved the problem for me. Here 
is the same short Octave session output:

   bash$ ./run-octave --quiet
   octave:1> which repmat
   `repmat' is a function from the file
   /Users/Thomas/Development/octave.am2/scripts/general/repmat.m
   octave:2> which reshape
   `reshape' is a built-in function
   octave:3> which cellfun
   `cellfun' is a function from the file
   /Users/Thomas/Development/octave.am2/src/DLD-FUNCTIONS/cellfun.oct
   octave:4> cellfun (@disp, {1,2,3}, 'UniformOutput', false)
   ans =
   {
     [1,1] =  1
     [1,2] =  2
     [1,3] =  3
   }

Attached I'm sending a simple "hg diff configure.ac >configure.ac.patch", I 
don't know if you prefer any other type of changeset in this stage, then let me 
know and I will send something else tomorrow.

Best regards

   Thomas

PS. I am very happy with the change to libtool because I still needed to add 
more "-llibs" flags to src/Makefile.in with the old way. Now libtool does all 
this work for me and these dependency problems all disappeared. This is great! 
Thanks.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configure.ac.patch
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091029/34b190ac/attachment.ksh 

From jwe at octave.org  Thu Oct 29 17:14:14 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 29 Oct 2009 18:14:14 -0400
Subject: gnulib and automake
In-Reply-To: <4AEA09B2.2090804@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan> <4AE8BB7E.6060103@gmx.net>
	<19176.48302.817065.387989@segfault.lan> <4AE9EC65.9090009@gmx.net>
	<19177.61259.8866.567112@segfault.lan> <4AE9F10A.4000803@gmx.net>
	<19177.62037.229499.434039@segfault.lan>
	<19177.65478.733895.188522@segfault.lan> <4AEA09B2.2090804@gmx.net>
Message-ID: <19178.5046.737136.856841@segfault.lan>

On 29-Oct-2009, Thomas Treichl wrote:

| Attached I'm sending a simple "hg diff configure.ac >configure.ac.patch", I 
| don't know if you prefer any other type of changeset in this stage, then let me 

I applied the patch with a few changes and credited it to you.

| PS. I am very happy with the change to libtool because I still needed to add 
| more "-llibs" flags to src/Makefile.in with the old way. Now libtool does all 
| this work for me and these dependency problems all disappeared. This is great! 

It's good to know someone else thinks it is an improvement.

Thanks,

jwe

From bpabbott at mac.com  Thu Oct 29 18:57:08 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Thu, 29 Oct 2009 19:57:08 -0400
Subject: gnulib and automake
In-Reply-To: <4AE9F10A.4000803@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan> <4AE8BB7E.6060103@gmx.net>
	<19176.48302.817065.387989@segfault.lan> <4AE9EC65.9090009@gmx.net>
	<19177.61259.8866.567112@segfault.lan> <4AE9F10A.4000803@gmx.net>
Message-ID: <A12F09D4-EC58-480E-BA0C-B976AA35DC4B@mac.com>


On Oct 29, 2009, at 3:46 PM, Thomas Treichl wrote:

> John W. Eaton schrieb:
>> On 29-Oct-2009, Thomas Treichl wrote:
>> | I think the easiest thing for me now would be that I change the  
>> configure.ac | file and that I try to compile against dlopen  
>> instead of dyld...
>> Does libtool try to use dyld by default?  How do you tell it to use
>> dlopen instead?
>
> I'm not familiar with the details now (this was before your changes  
> to automake), but if I now change configure.ac like I already  
> described here
>
> http://www.nabble.com/Changeset-Mac:-Use-dlopen-instead-of-dyld-per-default-td25264111.html
>
> then I finally get this result from ./configure:
>
>  Do internal array bounds checking:  false
>  Build static libraries:             false
>  Build shared libraries:             true
>  Dynamic Linking:                    true (dlopen)
>  Include support for GNU readline:   true
>  64-bit array dims and indexing:     false
>
> Per default (_without_ any changes at all) I get:
>
>  Do internal array bounds checking:  false
>  Build static libraries:             false
>  Build shared libraries:             true
>  Dynamic Linking:                    true (dyld)
>  Include support for GNU readline:   true
>  64-bit array dims and indexing:     false
>
> So I expect that I'm doing everything correctly now, too?
>
>  Thomas

My tip is

$ hg tip
changeset:   9763:63d554a54da6
tag:         tip
user:        John W. Eaton <jwe at octave.org>
date:        Thu Oct 29 18:39:34 2009 -0400
summary:     configure.ac: fix logic in previous change

I get the desired result of dlopen with my dependencies install via  
Fink on Mac OSX.

The build of the binary went without incident, and "make check"  
produced no failures!

Nicely done!

Ben


From bpabbott at mac.com  Fri Oct 30 10:09:12 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Fri, 30 Oct 2009 11:09:12 -0400
Subject: gnulib and automake (a fix?)
In-Reply-To: <19176.58906.848113.829594@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan>
	<420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com>
	<19176.41013.46982.260285@segfault.lan>
	<420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com>
	<a0daad600910281327j1c0fcd5fpf2389c72618dd5c8@mail.gmail.com>
	<19176.45899.330498.302231@segfault.lan>
	<19176.58906.848113.829594@segfault.lan>
Message-ID: <5AAD953D-523D-46FA-B7F9-509666A2E238@mac.com>


On Oct 28, 2009, at 8:47 PM, John W. Eaton wrote:

> On 28-Oct-2009, John W. Eaton wrote:
>
> | On 28-Oct-2009, Judd Storrs wrote:
> |
> | | I'm seeing the same (Ubuntu 9.10rc). I don't know if it's  
> related to
> | | the TeX memory error but prior to adding the TEXMFCNF change  
> (but with
> | | automake-diff applied), I noticed many errors flying by that  
> look like
> | | this:
> | |
> | | 	rm -rf $backupdir; exit $rc
> | | ../../run-octave -f -q -H -p . --eval "geometryimages  
> ('voronoi', 'eps');"
> | |
> | | ../../run-octave -f -q -H -p . --eval "geometryimages  
> ('triplot', 'eps');"
> | |
> | | ../../run-octave -f -q -H -p . --eval "geometryimages  
> ('griddata', 'eps');"
> | |
> | | ../../run-octave -f -q -H -p . --eval "geometryimages  
> ('convhull', 'eps');"
> | |
> | | Output completed.  Verifying that all points are below 7.4e-15 of
> | | all facets.  Will make 7381 distance computations.
> | |
> | | multiplot> plot "-" binary format='%float64' record=62 using  
> ($1):($2)
> | | axes x1y1 title "" with lines linestyle 1 , "-" binary
> | | format='%float64' record=121 using ($1):($2) axes x1y1 title ""  
> with
> | | linestyle 2 ;
> | |
> | |
> | |                                                                 ^
> | |            line 0: expecting 'lines', 'points', 'linespoints',  
> 'dots',
> | | 'impulses',
> | | 	'yerrorbars', 'xerrorbars', 'xyerrorbars', 'steps', 'fsteps',
> | | 	'histeps', 'filledcurves', 'boxes', 'boxerrorbars',  
> 'boxxyerrorbars',
> | | 	'vectors', 'financebars', 'candlesticks', 'errorlines',  
> 'xerrorlines',
> | | 	'yerrorlines', 'xyerrorlines', 'pm3d', 'labels', 'histograms',
> | | 	 'image', 'rgbimage'
> | |
> | |
> | | multiplot> f$,3u=?ffffff$,3u=u=u=]#rp$,3u=?
> | |             ^
> | |            line 0: invalid character
> | |
> | |
> | | multiplot> $,3u=?$,3u=u=u=u=u=u=u=u=u=u=u=?u=u=?
> | |            ^
> | |            line 0: invalid character
> |
> | What version of gnuplot do you have?  I recently upgraded and  
> gnuplot
> | 4.2.6 appeared on my system and now I'm seeing a similar problem.
> | This problem seems to be independent of my automake changes  
> though...
> | Can you confirm that?  If you have a build using the sources  
> before my
> | patch, then cd to the doc/interpreter directory in your build tree  
> and
> | try
> |
> |   rm -f *.eps
> |   make
> |
> | and see if you see similar problems.
>
> OK, this is not a gnuplot problem, but seems to be due to the  
> following
> changeset:
>
>  changeset:   9729:3b7e644bb46d
>  user:        David Bateman <dbateman at free.fr>
>  date:        Thu Oct 15 21:43:34 2009 +0200
>  summary:     Treat markerfacecolor and markeredgecolor properties  
> for lines and surfaces
>
> The problem is that we are sometimes generating things like
>
>  "with  linestyle 4"
>
> instead of
>
>  "with lines linestyle 4"
>
> at this point
>
> 	  style = do_linestyle_command (obj, obj.color, data_idx, mono,
> 					plot_stream, errbars);
>
> 	  withclause{data_idx} = sprintf ("with %s linestyle %d",
> 					  style{1}, data_idx);
>
> in scripts/plot/__go_draw_axes__.m (near line 525).  Here is a simple
> example that should demonstrate the problem:
>
>  figure (1, 'visible', 'off')
>  plot ([1, 2], [3, 4], 'r+');
>  print ("foo.eps", "-deps");
>
> When evaluating these commands, I see
>
>  octave:1>   figure (1, 'visible', 'off')
>  octave:2>   plot ([1, 2], [3, 4], 'r+');
>  octave:3>   print ("foo.eps", "-deps");
>
>  multiplot> plot "-" binary format='%float64' record=2 using ($1): 
> ($2) axes x1y1 title "" with  linestyle 1 ;
> 													   ^
> 	     line 0: expecting 'lines', 'points', 'linespoints', 'dots',  
> 'impulses',
> 	  'yerrorbars', 'xerrorbars', 'xyerrorbars', 'steps', 'fsteps',
> 	  'histeps', 'filledcurves', 'boxes', 'boxerrorbars',  
> 'boxxyerrorbars',
> 	  'vectors', 'financebars', 'candlesticks', 'errorlines',  
> 'xerrorlines',
> 	  'yerrorlines', 'xyerrorlines', 'pm3d', 'labels', 'histograms',
> 	   'image', 'rgbimage'
>
> It looks like obj.linestyle is "none" in the do_linestyle_command
> function in __go_draw_axes__.m and that results in setting style to
> "".
>
> I'm not sure what the proper fix is.
>
> jwe
>


The attached resolves the problem for John's example. The following  
also ran without incident.

	geometryimages ('voronoi', 'eps');
	geometryimages ('triplot', 'eps');
	geometryimages ('griddata', 'eps');
	geometryimages ('convhull', 'eps');

When tried "rundemos plot", I saw some errors. For example ...

	/Users/bpabbott/Development/mercurial/local_clone/scripts/plot/ 
colorbar.m example 16: failed
	addproperty: a `textlist' property already exists in the graphics  
objectPress <enter> to continue:

Anyone know what is happening here?

Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset.patch
Type: application/octet-stream
Size: 1293 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091030/e3f96150/attachment.obj 
-------------- next part --------------




-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset.patch
Type: application/octet-stream
Size: 1293 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091030/e3f96150/attachment-0001.obj 

From octave at nomad.inbox5.com  Fri Oct 30 13:01:25 2009
From: octave at nomad.inbox5.com (Rik)
Date: Fri, 30 Oct 2009 11:01:25 -0700
Subject: plot warnings
In-Reply-To: <mailman.36.1256922277.16497.octave-maintainers@octave.org>
References: <mailman.36.1256922277.16497.octave-maintainers@octave.org>
Message-ID: <MTAwMDAyMi5ub21hZA.1256925692@quikprotect>


> The attached resolves the problem for John's example. The following
> also ran without incident.
The patch does prevent any errors being generated, but it still doesn't
address the lost functionality.  Using "." for plot style should graph
just the datapoints with no interpolated line between them.  Octave
3.2.3 does this correctly.  The Mercurial sources, alas, are still
broken in this regard. 
>
>     geometryimages ('voronoi', 'eps');
>     geometryimages ('triplot', 'eps');
>     geometryimages ('griddata', 'eps');
>     geometryimages ('convhull', 'eps');
>
> When tried "rundemos plot", I saw some errors. For example ...
>
>     /Users/bpabbott/Development/mercurial/local_clone/scripts/plot/colorbar.m
> example 16: failed
>     addproperty: a `textlist' property already exists in the graphics
> objectPress <enter> to continue:
>
> Anyone know what is happening here?
It seems that directly setting properties on graphic handles leaves
cruft behind that is interfering with subsequent 'set' calls.  I've
recently encountered the same thing with the following code
demo('stem', 7)
demo('stem', 1)

stem example 1: failed
addproperty: a `basevalue' property already exists in the graphics object

The 7th demo for stem explicitly calls set(h, "basevalue", -1) and after
that the only way to reset things is to exit Octave.  I've tried 'clf',
'close all' and even 'backend("gnuplot") between the two calls to demo
and I am unable to clear the cruft out.

--Rik


From lindnerben at gmx.net  Fri Oct 30 13:56:57 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Fri, 30 Oct 2009 19:56:57 +0100
Subject: gnulib and automake
In-Reply-To: <19176.28026.31789.710006@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
Message-ID: <4AEB36F9.9070404@gmx.net>

John W. Eaton wrote:
> On 26-Oct-2009, Benjamin Lindner wrote:
> 
> | John W. Eaton wrote:
> | > Instead of the current ad-hoc way of including portability and
> | > replacement functions (things like mkdir, rmdir, strftime, etc.) in
> | > Octave, I would like to start using functions from gnulib
> | > (http://www.gnu.org/software/gnulib).  By using gnulib, we should get
> | > improved portability and in some cases better or newer versions of
> | > some of the replacement functions that we are currently using.
> | > 
> | > To see what would be required, I started trying to modify Octave's
> | > configure scripts to use gnulib, but quickly found that it is fairly
> | > complex to use gnulib without also using automake.
> | > 
> | > I've resisted using automake in the past because it seemed that it
> | > would be a fairly large job to convert Octave's existing build
> | > environment.  But at this point, I'm willing to give it a try just to
> | > get gnulib working.
> | > 
> | > Switching to automake and using gnulib may mean some additional
> | > disruption in building Octave during the transition.  Some changes to
> | > the way Octave is built from the Mercurial archive may be needed.  At
> | > the very least, you will need to have some way to get modules from
> | > gnulib if you don't already have them.  But the rules for this should
> | > all be in the configure (or bootstrap/autogen.sh) script, so you
> | > should really only need a network connection, and then only if you
> | > don't already have the necessary modules.
> | > 
> | > Are there any strong objections to making this change?
> | > 
> | > Is anyone on the list an expert automake user who would be willing to
> | > help with the transition?
> | 
> | The topic does not seem to have aroused much interest...
> | Well, I am not an expert on automake and neither on gnulib so I'm not in 
> | the position to state objections.
> | 
> | I'd like to see the build process still work for windows/mingw platform. 
> | Some of octave's dependecy libraries use automake, so this seems to work 
> | all right. I have no experience with gnulib and windows, so I can't 
> | really judge on that.
> 
> I have no intention of breaking the build on Windows systems.
> 
> A preliminary changeset for the switch to automake is now available
> here:
> 
>   http://jweaton.org/automake.gz
> 
> It would be helpful if you (and others) could try building Octave with
> this changeset and see what happens.  Here's what you need to do:
> 
>   * download the changeset
> 
>   * clone a copy of the current hg archive
> 
>   * cd to the top-level directory of the cloned archive and use "hg
>     import" to apply the changeset
> 
>   * run ./autogen.sh, configure, and make
> 
> To build from the mercurial archive, you will now need to have
> automake and libtool installed in addition to the other tools (bison,
> flex, gperf, etc.) that were required previously.
> 
> Building from a distribution tar file should not require any
> additional tools beyond what is currently required.
> 
> Some things that have changed:
> 
>   * Compilation is handled by libtool, so dependency information is
>     generated at compile time and the problem of bad or missing
>     dependencies causing make to mysteriously exit should be gone.
> 
>   * There are fewer Makefiles.  All of libcruft is built from one
>     Makefile now.  All of the scripts directory tree is handled by a
>     single Makefile now.
> 
>   * Lists of files in the subdirectories (for example, in the libcruft
>     and scripts directory trees) are listed in module.mk files 
>     in those directories.
> 
>   * Some of the lists of files (for example, the lists of mx- and vx-
>     files in the liboctave subdirectory) are now generated when
>     autogen.sh runs instead of being generated by a script when Make
>     runs.  This is done because automake needs to see a complete list
>     of explicit file names.
> 
>   * Many, but not all GNU Makeisms have been removed from the
>     Makefiles.  I may have gone too far, or maybe others would prefer
>     it if the Makefiles were more portable.  I like to be fairly
>     concise, but I would also be willing to work toward portability of
>     the Makefiles if others think that is useful.  There is certainly
>     more cleanup work that could be done.
> 
>   * The Octave version information is no longer extracted from
>     src/version.h, but instead stored in configure.ac and inserted
>     into src/version.h at build time.
> 
> Unresolved issues:
> 
>   * Building of .oct files is now done with libtool, which creates the
>     dynamically loadable file and a .la file.  The .la file contains
>     the name of the dynamically loadable library.  To generate the
>     .oct file, we now extract the name from the .la file and link (at
>     build time) or rename (at istall time) the dynamically loadable
>     file to the .oct file.  The mkoctfile script has not been updated
>     to use this method.  Once it is, I think we can delete all the
>     hand-crafted shared library stuff from configure.ac.  But before
>     we do that, we need to make sure that this all works properly on
>     Windows and OS X systems.
> 
>   * When linking the final Octave exectuable, libtool generates a
>     src/octave script which handles all the details of LD_LIBRARY_PATH
>     so that Octave can run in the build directory.  The run-octave
>     script no longer does that job.  Instead, it simply sets things
>     like the load path and the info ile directory and calls the
>     src/octave script.  However, since src/octave is a script, we
>     can't run gdb or valgrind on it as before, so debugging with
>     "run-octave -g" is currently broken.  I'd like to fix this, but I
>     don't know what the best solution is.  The generated src/octave
>     script doesn't seem to have a way to handle running a debugger on
>     the real executable file.  What do other libtool-based projects
>     do?
> 
> Comments or suggestions?
> 
> I would prefer to solve any problems before checking in this
> change, so please help me out by testing this changeset on Windows and
> OS X systems.  But I don't want to delay forever, so if I don't get
> any feedback in the next week or so, I'll assume that it is working
> and check it in.
> 

On msys-1.0.11, with

$ libtool --version
libtool (GNU libtool 1.3110 2009-07-01) 2.2.7a
$ autoconf --version
autoconf (GNU Autoconf) 2.63
$ automake --version
automake (GNU automake) 1.11

running ./autogen.sh completes without errors.

I then tried to build with the current tip and ran into the following 
issues:

gawk: /octmgw32/octave/octave-tip-automake/liboctave/mk-ops.awk:185: 
(FILENAME=/octmgw32/octave/octave-tip-automake/liboctave/mx-ops FNR=296) 
fatal: can't redirect to `mx-ui32nda-i8.cc' (Permission denied)
make[2]: *** [mx-dm-cdm.h] Error 2
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/liboctave'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2'
make: *** [all] Error 2

starting "make" once again, then continued beyond this point, but then 
fails at

rm -f DLD-FUNCTIONS/__contourc__.oct
ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < 
DLD-FUNCTIONS/lib__contourc__.la` DLD-FUNCTIONS/__contourc__.oct
ln: creating symbolic link `DLD-FUNCTIONS/__contourc__.oct' to `.libs': 
No such file or directory
make[3]: *** [DLD-FUNCTIONS/__contourc__.oct] Error 1
make[3]: *** Waiting for unfinished jobs....
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
shared libraries
make[3]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2'
make: *** [all] Error 2

This error persists when restarting "make".

The next issue is that no shared libraries are built, only static ones, 
although octave is configured with "--enable-shared".

Additionally, no .oct files are built, the directory DLD-FUNCTIONS/.libs 
only contains .o and .a files, no dlls.

looking into the file DLD-FUNCTIONS/lib__contourc__.la, it reads 
"dlname=''", which would explain ln's commandline which fails with the 
above error.

I don't really have a clue at hand as to what's wrong here.

benjamin



From Thomas.Treichl at gmx.net  Fri Oct 30 14:19:34 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Fri, 30 Oct 2009 20:19:34 +0100
Subject: gnulib and automake
In-Reply-To: <4AE8BB7E.6060103@gmx.net>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>	<19176.31314.572679.656960@segfault.lan>
	<4AE8BB7E.6060103@gmx.net>
Message-ID: <4AEB3C46.70203@gmx.net>

Thomas Treichl schrieb:
> Hi John,
> 
> on my Mac OS X 10.4 system I currently have two problems (sources still 
> compiling this night, don't know if there are further problems)... The 
> first thing is that in all subdirectories of libcruft eg. libcruft/amos 
> etc. there don't exist ".deps" directories and they also cannot be build 
> on my system (I currently have no idea what causes this or which command 
> is doing this). The error looks like this (without any further 
> information about which command calls "cp" or such)
> 
>   Making all in libcruft
>   cp: illegal option -- d
>   usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
>          cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN 
> directory
>   mv: rename amos/#inst.16473# to amos/.deps: No such file or directory
>   /bin/sh: line 1: amos/.deps/.dirstamp: No such file or directory
>   make[2]: *** [amos/.deps/.dirstamp] Error 1
>   make[1]: *** [all-recursive] Error 1
>   make: *** [all] Error 2
> 
> If I create all ".deps" directories by hand in all subdirectories of 
> libcruft then I also can make libcruft.

Ok, finally I also found out this problem and found a simple solution for it. 
With your patch there comes a file in the root directory that is called 
"install-sh". This file is a GNU/Linux file (at least I know that you are 
working on a GNU/Linux box ;) and doesn't work very well on Macs. I removed this 
file from my copy of the sources and autogen.sh'ed once again. Then install-sh 
is created automatically (actually a link is created) which works very well and 
also can handle the "-d" option correctly, see last line of this ./autogen.sh 
output snippet:

   calling aclocal...
   generating source lists for liboctave/Makefile...
   generating doc/interpreter/images.mk...
   generating src/DLD-FUNCTIONS/module.mk...
   calling autoheader...
   calling automake...
   configure.ac:44: installing `./install-sh'

The install-sh file that is generated on my system then is a link that looks like

   bash$ ls -l install-sh
   lrwxr-xr-x   1 Thomas  Thomas  41 Oct 30 20:13 install-sh ->
     /usr/local/share/automake-1.11/install-sh

I think the best thing to solve this problem is to remove the "install-sh" file 
from the sources because it is autogenerated.

Thanks and best regards

   Thomas

From jwe at octave.org  Fri Oct 30 14:22:25 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 30 Oct 2009 15:22:25 -0400
Subject: gnulib and automake
In-Reply-To: <4AEB36F9.9070404@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net>
Message-ID: <19179.15601.907503.686285@segfault.lan>

On 30-Oct-2009, Benjamin Lindner wrote:

| On msys-1.0.11, with
| 
| $ libtool --version
| libtool (GNU libtool 1.3110 2009-07-01) 2.2.7a
| $ autoconf --version
| autoconf (GNU Autoconf) 2.63
| $ automake --version
| automake (GNU automake) 1.11
| 
| running ./autogen.sh completes without errors.
| 
| I then tried to build with the current tip and ran into the following 
| issues:
| 
| gawk: /octmgw32/octave/octave-tip-automake/liboctave/mk-ops.awk:185: 
| (FILENAME=/octmgw32/octave/octave-tip-automake/liboctave/mx-ops FNR=296) 
| fatal: can't redirect to `mx-ui32nda-i8.cc' (Permission denied)

I have no idea why this would happen.

| starting "make" once again, then continued beyond this point, but then 
nn| fails at
| 
| rm -f DLD-FUNCTIONS/__contourc__.oct
| ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < 
| DLD-FUNCTIONS/lib__contourc__.la` DLD-FUNCTIONS/__contourc__.oct
| ln: creating symbolic link `DLD-FUNCTIONS/__contourc__.oct' to `.libs': 
| No such file or directory
| make[3]: *** [DLD-FUNCTIONS/__contourc__.oct] Error 1
| make[3]: *** Waiting for unfinished jobs....
| libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
| shared libraries
| make[3]: Leaving directory 
| `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory 
| `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory 
| `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2'
| make: *** [all] Error 2
| 
| This error persists when restarting "make".
| 
| The next issue is that no shared libraries are built, only static ones, 
| although octave is configured with "--enable-shared".
| 
| Additionally, no .oct files are built, the directory DLD-FUNCTIONS/.libs 
| only contains .o and .a files, no dlls.
| 
| looking into the file DLD-FUNCTIONS/lib__contourc__.la, it reads 
| "dlname=''", which would explain ln's commandline which fails with the 
| above error.

That all makes sense if libtool was somehow told not to build shared
libraries.  Maybe there is a problem with the way --enable-shared is
handled.  We currently have the old AC_ARG_ENABLE for --enable-shared
AND the libtool macros in configure.ac.  Maybe there is some conflict?
Since the default is to build shared libraries and not static
libraries, can you try running configure without any --enable-shared
--disable-static or --enable-dl options and see what happens?  What
does the output from configure tell you about the configuration of
libtool?  I would expect something like

  ...
  checking for ld used by gcc... /usr/bin/ld
  checking if the linker (/usr/bin/ld) is GNU ld... yes
  checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
  checking the name lister (/usr/bin/nm -B) interface... BSD nm
  checking whether ln -s works... yes
  checking the maximum length of command line arguments... 1572864
  checking whether the shell understands some XSI constructs... yes
  checking whether the shell understands "+="... yes
  checking for /usr/bin/ld option to reload object files... -r
  checking for objdump... objdump
  checking how to recognize dependent libraries... pass_all
  checking for ar... ar
  checking for strip... strip
  checking for ranlib... ranlib
  checking command to parse /usr/bin/nm -B output from gcc object... ok
  checking for dlfcn.h... yes
  checking whether we are using the GNU C++ compiler... (cached) yes
  checking whether g++ accepts -g... (cached) yes
  checking dependency style of g++... (cached) gcc3
  checking how to run the C++ preprocessor... g++ -E
  checking whether we are using the GNU Fortran 77 compiler... (cached) yes
  checking whether gfortran accepts -g... (cached) yes
  checking for objdir... .libs
  checking if gcc supports -fno-rtti -fno-exceptions... no
  checking for gcc option to produce PIC... -fPIC -DPIC
  checking if gcc PIC flag -fPIC -DPIC works... yes
  checking if gcc static flag -static works... yes
  checking if gcc supports -c -o file.o... yes
  checking if gcc supports -c -o file.o... (cached) yes
  checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
  checking whether -lc should be explicitly linked in... no
  checking dynamic linker characteristics... GNU/Linux ld.so
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
  checking whether to build shared libraries... yes
  checking whether to build static libraries... no
  checking for ld used by g++... /usr/bin/ld -m elf_x86_64
  checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
  checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
  checking for g++ option to produce PIC... -fPIC -DPIC
  checking if g++ PIC flag -fPIC -DPIC works... yes
  checking if g++ static flag -static works... yes
  checking if g++ supports -c -o file.o... yes
  checking if g++ supports -c -o file.o... (cached) yes
  checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
  checking dynamic linker characteristics... GNU/Linux ld.so
  checking how to hardcode library paths into programs... immediate
  checking if libtool supports shared libraries... yes
  checking whether to build shared libraries... yes
  checking whether to build static libraries... no
  checking for gfortran option to produce PIC... -fPIC
  checking if gfortran PIC flag -fPIC works... yes
  checking if gfortran static flag -static works... yes
  checking if gfortran supports -c -o file.o... yes
  checking whether the gfortran linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
  checking dynamic linker characteristics... GNU/Linux ld.so
  checking how to hardcode library paths into programs... immediate
  ...

What results do you see?  If configure is not finding that your system
can create shared libraries, can you try to find out why that happens?

jwe

From jwe at octave.org  Fri Oct 30 14:39:59 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 30 Oct 2009 15:39:59 -0400
Subject: gnulib and automake
In-Reply-To: <4AEB3C46.70203@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
	<420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com>
	<19176.31314.572679.656960@segfault.lan> <4AE8BB7E.6060103@gmx.net>
	<4AEB3C46.70203@gmx.net>
Message-ID: <19179.16655.674346.755582@segfault.lan>

On 30-Oct-2009, Thomas Treichl wrote:

| Ok, finally I also found out this problem and found a simple solution for it. 
| With your patch there comes a file in the root directory that is called 
| "install-sh". This file is a GNU/Linux file (at least I know that you are 
| working on a GNU/Linux box ;) and doesn't work very well on Macs. I removed this 
| file from my copy of the sources and autogen.sh'ed once again. Then install-sh 
| is created automatically (actually a link is created) which works very well and 
| also can handle the "-d" option correctly, see last line of this ./autogen.sh 
| output snippet:
| 
|    calling aclocal...
|    generating source lists for liboctave/Makefile...
|    generating doc/interpreter/images.mk...
|    generating src/DLD-FUNCTIONS/module.mk...
|    calling autoheader...
|    calling automake...
|    configure.ac:44: installing `./install-sh'
| 
| The install-sh file that is generated on my system then is a link that looks like
| 
|    bash$ ls -l install-sh
|    lrwxr-xr-x   1 Thomas  Thomas  41 Oct 30 20:13 install-sh ->
|      /usr/local/share/automake-1.11/install-sh
| 
| I think the best thing to solve this problem is to remove the "install-sh" file 
| from the sources because it is autogenerated.

I removed the old install-sh script.

Thanks,

jwe

From lindnerben at gmx.net  Fri Oct 30 15:05:02 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Fri, 30 Oct 2009 21:05:02 +0100
Subject: gnulib and automake
In-Reply-To: <19179.15601.907503.686285@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<4AEB36F9.9070404@gmx.net>
	<19179.15601.907503.686285@segfault.lan>
Message-ID: <4AEB46EE.8030400@gmx.net>

John W. Eaton wrote:
> On 30-Oct-2009, Benjamin Lindner wrote:
> 
> | On msys-1.0.11, with
> | 
> | $ libtool --version
> | libtool (GNU libtool 1.3110 2009-07-01) 2.2.7a
> | $ autoconf --version
> | autoconf (GNU Autoconf) 2.63
> | $ automake --version
> | automake (GNU automake) 1.11
> | 
> | running ./autogen.sh completes without errors.
> | 
> | I then tried to build with the current tip and ran into the following 
> | issues:
> | 
> | gawk: /octmgw32/octave/octave-tip-automake/liboctave/mk-ops.awk:185: 
> | (FILENAME=/octmgw32/octave/octave-tip-automake/liboctave/mx-ops FNR=296) 
> | fatal: can't redirect to `mx-ui32nda-i8.cc' (Permission denied)
> 
> I have no idea why this would happen.

Maybe a race condition from parallel make. Never mind.

> | starting "make" once again, then continued beyond this point, but then 
> nn| fails at
> | 
> | rm -f DLD-FUNCTIONS/__contourc__.oct
> | ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < 
> | DLD-FUNCTIONS/lib__contourc__.la` DLD-FUNCTIONS/__contourc__.oct
> | ln: creating symbolic link `DLD-FUNCTIONS/__contourc__.oct' to `.libs': 
> | No such file or directory
> | make[3]: *** [DLD-FUNCTIONS/__contourc__.oct] Error 1
> | make[3]: *** Waiting for unfinished jobs....
> | libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
> | shared libraries
> | make[3]: Leaving directory 
> | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
> | make[2]: *** [all] Error 2
> | make[2]: Leaving directory 
> | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
> | make[1]: *** [all-recursive] Error 1
> | make[1]: Leaving directory 
> | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2'
> | make: *** [all] Error 2
> | 
> | This error persists when restarting "make".
> | 
> | The next issue is that no shared libraries are built, only static ones, 
> | although octave is configured with "--enable-shared".
> | 
> | Additionally, no .oct files are built, the directory DLD-FUNCTIONS/.libs 
> | only contains .o and .a files, no dlls.
> | 
> | looking into the file DLD-FUNCTIONS/lib__contourc__.la, it reads 
> | "dlname=''", which would explain ln's commandline which fails with the 
> | above error.
> 
> That all makes sense if libtool was somehow told not to build shared
> libraries.  Maybe there is a problem with the way --enable-shared is
> handled.  We currently have the old AC_ARG_ENABLE for --enable-shared
> AND the libtool macros in configure.ac.  Maybe there is some conflict?
> Since the default is to build shared libraries and not static
> libraries, can you try running configure without any --enable-shared
> --disable-static or --enable-dl options and see what happens?  What
> does the output from configure tell you about the configuration of
> libtool?  I would expect something like
> 
>   ...
>   checking for ld used by gcc... /usr/bin/ld
>   checking if the linker (/usr/bin/ld) is GNU ld... yes
>   checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
>   checking the name lister (/usr/bin/nm -B) interface... BSD nm
>   checking whether ln -s works... yes
>   checking the maximum length of command line arguments... 1572864
>   checking whether the shell understands some XSI constructs... yes
>   checking whether the shell understands "+="... yes
>   checking for /usr/bin/ld option to reload object files... -r
>   checking for objdump... objdump
>   checking how to recognize dependent libraries... pass_all
>   checking for ar... ar
>   checking for strip... strip
>   checking for ranlib... ranlib
>   checking command to parse /usr/bin/nm -B output from gcc object... ok
>   checking for dlfcn.h... yes
>   checking whether we are using the GNU C++ compiler... (cached) yes
>   checking whether g++ accepts -g... (cached) yes
>   checking dependency style of g++... (cached) gcc3
>   checking how to run the C++ preprocessor... g++ -E
>   checking whether we are using the GNU Fortran 77 compiler... (cached) yes
>   checking whether gfortran accepts -g... (cached) yes
>   checking for objdir... .libs
>   checking if gcc supports -fno-rtti -fno-exceptions... no
>   checking for gcc option to produce PIC... -fPIC -DPIC
>   checking if gcc PIC flag -fPIC -DPIC works... yes
>   checking if gcc static flag -static works... yes
>   checking if gcc supports -c -o file.o... yes
>   checking if gcc supports -c -o file.o... (cached) yes
>   checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
>   checking whether -lc should be explicitly linked in... no
>   checking dynamic linker characteristics... GNU/Linux ld.so
>   checking how to hardcode library paths into programs... immediate
>   checking whether stripping libraries is possible... yes
>   checking if libtool supports shared libraries... yes
>   checking whether to build shared libraries... yes
>   checking whether to build static libraries... no
>   checking for ld used by g++... /usr/bin/ld -m elf_x86_64
>   checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
>   checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
>   checking for g++ option to produce PIC... -fPIC -DPIC
>   checking if g++ PIC flag -fPIC -DPIC works... yes
>   checking if g++ static flag -static works... yes
>   checking if g++ supports -c -o file.o... yes
>   checking if g++ supports -c -o file.o... (cached) yes
>   checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
>   checking dynamic linker characteristics... GNU/Linux ld.so
>   checking how to hardcode library paths into programs... immediate
>   checking if libtool supports shared libraries... yes
>   checking whether to build shared libraries... yes
>   checking whether to build static libraries... no
>   checking for gfortran option to produce PIC... -fPIC
>   checking if gfortran PIC flag -fPIC works... yes
>   checking if gfortran static flag -static works... yes
>   checking if gfortran supports -c -o file.o... yes
>   checking whether the gfortran linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
>   checking dynamic linker characteristics... GNU/Linux ld.so
>   checking how to hardcode library paths into programs... immediate
>   ...
> 
> What results do you see?  If configure is not finding that your system
> can create shared libraries, can you try to find out why that happens?

Ok, I ran configure without any "--enable" options, and this is what I get:

checking for ld used by mingw32-gcc-4.4.0-dw2 -shared-libgcc... ld
checking if the linker (ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /mingw/bin/nm
checking the name lister (/mingw/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i686-pc-mingw32 paths to i686-pc-mingw32 
format... func_msys_to_mingw_path_convert
checking for ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive 
import|^x86 DLL
checking for dlltool... dlltool
checking how to associate runtime and link libraries... 
func_cygming_dll_for_implib
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /mingw/bin/nm output from 
mingw32-gcc-4.4.0-dw2 -shared-libgcc object... ok
checking for dlfcn.h... no
checking for objdir... .libs
checking if mingw32-gcc-4.4.0-dw2 -shared-libgcc supports -fno-rtti 
-fno-exceptions... no
checking for mingw32-gcc-4.4.0-dw2 -shared-libgcc option to produce 
PIC... -DDLL_EXPORT -DPIC
checking if mingw32-gcc-4.4.0-dw2 -shared-libgcc PIC flag -DDLL_EXPORT 
-DPIC works... yes
checking if mingw32-gcc-4.4.0-dw2 -shared-libgcc static flag -static 
works... yes
checking if mingw32-gcc-4.4.0-dw2 -shared-libgcc supports -c -o 
file.o... yes
checking if mingw32-gcc-4.4.0-dw2 -shared-libgcc supports -c -o 
file.o... (cached) yes
checking whether the mingw32-gcc-4.4.0-dw2 -shared-libgcc linker (ld) 
supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... mingw32-g++-4.4.0-dw2 
-shared-libgcc -E
checking for ld used by mingw32-g++-4.4.0-dw2 -shared-libgcc... ld
checking if the linker (ld) is GNU ld... yes
checking whether the mingw32-g++-4.4.0-dw2 -shared-libgcc linker (ld) 
supports shared libraries... yes
checking for mingw32-g++-4.4.0-dw2 -shared-libgcc option to produce 
PIC... -DDLL_EXPORT -DPIC
checking if mingw32-g++-4.4.0-dw2 -shared-libgcc PIC flag -DDLL_EXPORT 
-DPIC works... yes
checking if mingw32-g++-4.4.0-dw2 -shared-libgcc static flag -static 
works... yes
checking if mingw32-g++-4.4.0-dw2 -shared-libgcc supports -c -o 
file.o... yes
checking if mingw32-g++-4.4.0-dw2 -shared-libgcc supports -c -o 
file.o... (cached) yes
checking whether the mingw32-g++-4.4.0-dw2 -shared-libgcc linker (ld) 
supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for mingw32-gfortran-4.4.0-dw2 -shared-libgcc option to produce 
PIC... -DDLL_EXPORT
checking if mingw32-gfortran-4.4.0-dw2 -shared-libgcc PIC flag 
-DDLL_EXPORT works... yes
checking if mingw32-gfortran-4.4.0-dw2 -shared-libgcc static flag 
-static works... yes
checking if mingw32-gfortran-4.4.0-dw2 -shared-libgcc supports -c -o 
file.o... yes
checking if mingw32-gfortran-4.4.0-dw2 -shared-libgcc supports -c -o 
file.o... (cached) yes
checking whether the mingw32-gfortran-4.4.0-dw2 -shared-libgcc linker 
(ld) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate

looks ok, doesn't it?

benjamin

From jwe at octave.org  Fri Oct 30 16:02:48 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 30 Oct 2009 17:02:48 -0400
Subject: gnulib and automake
In-Reply-To: <4AEB46EE.8030400@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net>
	<19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net>
Message-ID: <19179.21624.130899.537300@segfault.lan>

On 30-Oct-2009, Benjamin Lindner wrote:

| Ok, I ran configure without any "--enable" options, and this is what I get:

Is this different from what happens with --enable-shared?

| looks ok, doesn't it?

Yes.  Using this configuration, are shared libraries built?

jwe

From lindnerben at gmx.net  Fri Oct 30 16:21:30 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Fri, 30 Oct 2009 22:21:30 +0100
Subject: gnulib and automake
In-Reply-To: <19179.21624.130899.537300@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<4AEB36F9.9070404@gmx.net>	<19179.15601.907503.686285@segfault.lan>	<4AEB46EE.8030400@gmx.net>
	<19179.21624.130899.537300@segfault.lan>
Message-ID: <4AEB58DA.9070805@gmx.net>

John W. Eaton wrote:
> On 30-Oct-2009, Benjamin Lindner wrote:
> 
> | Ok, I ran configure without any "--enable" options, and this is what I get:
> 
> Is this different from what happens with --enable-shared?

No

> | looks ok, doesn't it?
> 
> Yes.  Using this configuration, are shared libraries built?
> 

No

I begin to suspect this will not be going to work OOTB. It smells like 
the many bad experiences I have had with libtool when building octave's 
dependency libraries.
Sigh, I'm not sure I am happy than now also octave uses libtool.

benjamin

From jwe at octave.org  Fri Oct 30 17:16:10 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 30 Oct 2009 18:16:10 -0400
Subject: gnulib and automake
In-Reply-To: <4AEB58DA.9070805@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net>
	<19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net>
	<19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net>
Message-ID: <19179.26026.448430.104714@segfault.lan>

On 30-Oct-2009, Benjamin Lindner wrote:

| > | looks ok, doesn't it?
| > 
| > Yes.  Using this configuration, are shared libraries built?
| > 
| 
| No
| 
| I begin to suspect this will not be going to work OOTB. It smells like 
| the many bad experiences I have had with libtool when building octave's 
| dependency libraries.

What were the problems?  How did you solve them (did you)?

In any case, I don't plan to reverse the decision to use libtool and
automake, because I want to be able to use functions from gnulib, and
as far as I can tell, that is just not practical without automake and
libtool.

I can try to help you debug the problems, but you will have to send
more information about exactly what is happening.  Or, I need to know
how to duplicate the build environment you have, then I can try to
find a Windows system that I can use to debug the configuration
problems.

jwe

From jwe at octave.org  Fri Oct 30 17:32:19 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 30 Oct 2009 18:32:19 -0400
Subject: gnulib and automake
In-Reply-To: <19176.28026.31789.710006@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan>
Message-ID: <19179.26995.431999.643818@segfault.lan>

On 28-Oct-2009, John W. Eaton wrote:

|   * When linking the final Octave exectuable, libtool generates a
|     src/octave script which handles all the details of LD_LIBRARY_PATH
|     so that Octave can run in the build directory.  The run-octave
|     script no longer does that job.  Instead, it simply sets things
|     like the load path and the info ile directory and calls the
|     src/octave script.  However, since src/octave is a script, we
|     can't run gdb or valgrind on it as before, so debugging with
|     "run-octave -g" is currently broken.  I'd like to fix this, but I
|     don't know what the best solution is.  The generated src/octave
|     script doesn't seem to have a way to handle running a debugger on
|     the real executable file.  What do other libtool-based projects
|     do?

I discovered the "--mode=exec" option for libtool and modified the
run-octave script to use that, so now "run-octave -g" works again.

jwe

From lindnerben at gmx.net  Sat Oct 31 06:08:06 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sat, 31 Oct 2009 12:08:06 +0100
Subject: gnulib and automake
In-Reply-To: <19179.26026.448430.104714@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<4AEB36F9.9070404@gmx.net>	<19179.15601.907503.686285@segfault.lan>	<4AEB46EE.8030400@gmx.net>	<19179.21624.130899.537300@segfault.lan>	<4AEB58DA.9070805@gmx.net>
	<19179.26026.448430.104714@segfault.lan>
Message-ID: <4AEC1A96.4020108@gmx.net>

John W. Eaton wrote:
> On 30-Oct-2009, Benjamin Lindner wrote:
> 
> | > | looks ok, doesn't it?
> | > 
> | > Yes.  Using this configuration, are shared libraries built?
> | > 
> | 
> | No
> | 
> | I begin to suspect this will not be going to work OOTB. It smells like 
> | the many bad experiences I have had with libtool when building octave's 
> | dependency libraries.
> 
> What were the problems?  How did you solve them (did you)?

Libtool does not honor the -shared-libgcc flag, which can be tricked by 
adding this flag to the name of CC, CXX and F77, that's not really a 
problem, but it's symptomatic to the way libtool places hurdles before 
the maintainer.

Libtool only scarcely builds shared libraries. And if it builds shared 
libraries, it sometimes screws up completely.
In all those cases I patch the corresponding makekefile.in and add the 
wanted dll as an explicit makefile target and add a a link command 
similar to

foo.dll : $(foo_DLL_objects)
	$(CXX) -shared -o $@ \
	$(LDFLAGS) \
	-Wl,--out-implib=libfoo.dll.a \
	$^ $(LIBS) $(OTHERDEPLIBS)

or (if there is a static lib available) something along the lines of

foo.dll : libfoo.a
	$(CXX) -shared -o $@ \
	$(LDFLAGS) \
	-Wl,--out-implib=libfoo.dll.a \
	-Wl,--whole-archive $< \
	-Wl,--no-whole-archive \
	$(LIBS) $(OTHERDEPLIBS)

for example 
https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/admin/Windows/mingw32/glpk/glpk-4.39-4.patch


This problem of not creating shared libs in windows is also found on the 
web, and the mantra-like solution is to specify "-no-undefined" as 
libtool link options.

So I did.

--- 
.build_mingw32_octave-tip-automake-ref-4_gcc-4.4.0-dw2/libcruft/Makefile 
    2009-10-31 11:07:52 +0100
+++ .build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft/Makefile 
        2009-10-31 11:43:35 +0100
@@ -807,7 +807,7 @@
  libcruft_la_OBJECTS = $(am_libcruft_la_OBJECTS)
  libcruft_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
         $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \
-       $(CXXFLAGS) $(libcruft_la_LDFLAGS) $(LDFLAGS) -o $@
+       $(CXXFLAGS) $(libcruft_la_LDFLAGS) -no-undefined $(LDFLAGS) -o $@
  DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)
  depcomp = $(SHELL) $(top_srcdir)/depcomp
  am__depfiles_maybe = depfiles


It did not work.

Then I tried to get some more information out of libtool
by replacing the --silent flag by --verbose as in

--- 
.build_mingw32_octave-tip-automake-ref-4_gcc-4.4.0-dw2/libcruft/Makefile 
    2009-10-31 11:07:52 +0100
+++ .build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft/Makefile 
        2009-10-31 11:43:35 +0100
@@ -1256,17 +1256,17 @@
  # What is the path separation character
  sepchar = ;
  sharedstatedir = ${prefix}/com
-srcdir = /octmgw32/octave/octave-tip-automake-ref/libcruft
+srcdir = /octmgw32/octave/octave-tip-automake/libcruft
  sysconfdir = ${prefix}/etc
  target_alias =
  to_host_path_cmd = func_msys_to_mingw_path_convert
  top_build_prefix = ../
  top_builddir = ..
-top_srcdir = /octmgw32/octave/octave-tip-automake-ref
+top_srcdir = /octmgw32/octave/octave-tip-automake
  TOPDIR = ..
  version = 3.3.50+
  api_version = api-v38+
-AM_LIBTOOLFLAGS = --silent
+AM_LIBTOOLFLAGS = --verbose
  AM_LFLAGS = -I
  AM_YFLAGS = -dv
  LIBEXT = a

It did not work.

But I read:

libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
shared libraries
libtool: link: rm -fr  .libs/libcruft.dll.a

*** Warning: linker path does not have real file for library -liberty.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libiberty and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libiberty.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

Sigh, more libtool nonsense.
Again symptomatic. If libtool would just do what it is told to do and 
not try to be more witted than the user!
Of course /mingw/lib/libiberty.a is a static library, so what?
ld.exe does not complain, so I don't see why libtool does.

If I then additionally patch libtool as

--- .build_mingw32_octave-tip-automake-ref-4_gcc-4.4.0-dw2/libtool 
2009-10-31 11:08:08 +0100
+++ 
.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libtool-mod1-works 
     2009-10-31 11:30:38 +0100
@@ -5943,7 +5943,7 @@
         ;;

        -no-undefined)
-       allow_undefined=no
+       allow_undefined=yes
         continue
         ;;

@@ -7744,7 +7744,7 @@
         if test "$allow_undefined" = yes; then
           if test "$allow_undefined_flag" = unsupported; then
             func_warning "undefined symbols not allowed in $host shared 
libraries"
-           build_libtool_libs=no
+           build_libtool_libs=yes
             build_old_libs=yes
           fi
         else


then I get libtool to build a shared library, which then fails with

make[2]: Entering directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'
/bin/sh ../libtool --tag=CXX --verbose  --mode=link 
mingw32-g++-4.4.0-dw2 -shared-libgcc -march=i686 -mtune=generic -O3 
-Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W -Wshadow -Wold-style-cast 
-Wformat -march=i686 -mtune=generic -O3 -Wall  -march=i686 
-mtune=generic -O3 -Wall -release 3.3.50+ -no-undefined -shared-libgcc 
-Wl,--allow-multiple-definition -o libcruft.la -rpath 
/usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
amos/cacai.lo amos/cacon.lo amos/cbesh.lo amos/cbesi.lo amos/cbesj.lo 
amos/cbesk.lo amos/cbesy.lo amos/cbinu.lo amos/cbuni.lo amos/cbunk.lo 
amos/cunk1.lo amos/cunk2.lo amos/crati.lo amos/cshch.lo amos/cuni1.lo 
amos/cuoik.lo amos/cairy.lo amos/cbiry.lo amos/ckscl.lo amos/cs1s2.lo 
amos/cuchk.lo amos/cuni2.lo amos/cwrsk.lo amos/casyi.lo amos/cbknu.lo 
amos/cmlri.lo amos/cseri.lo amos/cunhj.lo amos/cunik.lo amos/dgamln.lo 
amos/gamln.lo amos/xzabs.lo amos/xzexp.lo amos/xzlog.lo amos/xzsqrt.lo 
amos/zacai.lo amos/zacon.lo amos/zairy.lo amos/zasyi.lo amos/zbesh.lo 
amos/zbesi.lo amos/zbesj.lo amos/zbesk.lo amos/zbesy.lo amos/zbinu.lo 
amos/zbiry.lo amos/zbknu.lo amos/zbuni.lo amos/zbunk.lo amos/zdiv.lo 
amos/zkscl.lo amos/zmlri.lo amos/zmlt.lo amos/zrati.lo amos/zs1s2.lo 
amos/zseri.lo amos/zshch.lo amos/zuchk.lo amos/zunhj.lo amos/zuni1.lo 
amos/zuni2.lo amos/zunik.lo amos/zunk1.lo amos/zunk2.lo amos/zuoik.lo 
amos/zwrsk.lo  blas-xtra/xddot.lo blas-xtra/xdnrm2.lo 
blas-xtra/xdznrm2.lo blas-xtra/xzdotc.lo blas-xtra/xzdotu.lo 
blas-xtra/xsdot.lo blas-xtra/xsnrm2.lo blas-xtra/xscnrm2.lo 
blas-xtra/xcdotc.lo blas-xtra/xcdotu.lo blas-xtra/xerbla.lo 
daspk/datv.lo daspk/dcnst0.lo daspk/dcnstr.lo daspk/ddasic.lo 
daspk/ddasid.lo daspk/ddasik.lo daspk/ddaspk.lo daspk/ddstp.lo 
daspk/ddwnrm.lo daspk/dfnrmd.lo daspk/dfnrmk.lo daspk/dhels.lo 
daspk/dheqr.lo daspk/dinvwt.lo daspk/dlinsd.lo daspk/dlinsk.lo 
daspk/dmatd.lo daspk/dnedd.lo daspk/dnedk.lo daspk/dnsd.lo 
daspk/dnsid.lo daspk/dnsik.lo daspk/dnsk.lo daspk/dorth.lo 
daspk/dslvd.lo daspk/dslvk.lo daspk/dspigm.lo daspk/dyypnw.lo 
dasrt/ddasrt.lo dasrt/drchek.lo dasrt/droots.lo dassl/ddaini.lo 
dassl/ddajac.lo dassl/ddanrm.lo dassl/ddaslv.lo dassl/ddassl.lo 
dassl/ddastp.lo dassl/ddatrp.lo dassl/ddawts.lo   lapack-xtra/xclange.lo 
lapack-xtra/xdlamch.lo lapack-xtra/xdlange.lo lapack-xtra/xilaenv.lo 
lapack-xtra/xslamch.lo lapack-xtra/xslange.lo lapack-xtra/xzlange.lo 
misc/cquit.lo misc/d1mach.lo misc/f77-extern.lo misc/f77-fcn.lo 
misc/i1mach.lo misc/lo-error.lo misc/quit.lo misc/r1mach.lo 
odepack/cfode.lo odepack/dlsode.lo odepack/ewset.lo odepack/intdy.lo 
odepack/prepj.lo odepack/solsy.lo odepack/stode.lo odepack/vnorm.lo 
odepack/scfode.lo odepack/sewset.lo odepack/sintdy.lo odepack/slsode.lo 
odepack/sprepj.lo odepack/ssolsy.lo odepack/sstode.lo odepack/svnorm.lo 
ordered-qz/dsubsp.lo ordered-qz/exchqz.lo ordered-qz/ssubsp.lo 
ordered-qz/sexchqz.lo quadpack/dqagi.lo quadpack/dqagie.lo 
quadpack/dqagp.lo quadpack/dqagpe.lo quadpack/dqelg.lo 
quadpack/dqk15i.lo quadpack/dqk21.lo quadpack/dqpsrt.lo 
quadpack/qagie.lo quadpack/qagi.lo quadpack/qagpe.lo quadpack/qagp.lo 
quadpack/qelg.lo quadpack/qk15i.lo quadpack/qk21.lo quadpack/qpsrt.lo 
quadpack/xerror.lo ranlib/advnst.lo ranlib/genbet.lo ranlib/genchi.lo 
ranlib/genexp.lo ranlib/genf.lo ranlib/gengam.lo ranlib/genmn.lo 
ranlib/genmul.lo ranlib/gennch.lo ranlib/gennf.lo ranlib/gennor.lo 
ranlib/genprm.lo ranlib/genunf.lo ranlib/getcgn.lo ranlib/getsd.lo 
ranlib/ignbin.lo ranlib/ignlgi.lo ranlib/ignnbn.lo ranlib/ignpoi.lo 
ranlib/ignuin.lo ranlib/initgn.lo ranlib/inrgcm.lo ranlib/lennob.lo 
ranlib/mltmod.lo ranlib/phrtsd.lo ranlib/qrgnin.lo ranlib/ranf.lo 
ranlib/setall.lo ranlib/setant.lo ranlib/setgmn.lo ranlib/setsd.lo 
ranlib/sexpo.lo ranlib/sgamma.lo ranlib/snorm.lo ranlib/wrap.lo 
slatec-err/fdump.lo slatec-err/ixsav.lo slatec-err/j4save.lo 
slatec-err/xerclr.lo slatec-err/xercnt.lo slatec-err/xerhlt.lo 
slatec-err/xermsg.lo slatec-err/xerprn.lo slatec-err/xerrwd.lo 
slatec-err/xersve.lo slatec-err/xgetf.lo slatec-err/xgetua.lo 
slatec-err/xsetf.lo slatec-err/xsetua.lo slatec-fn/albeta.lo 
slatec-fn/alngam.lo slatec-fn/alnrel.lo slatec-fn/algams.lo 
slatec-fn/acosh.lo slatec-fn/asinh.lo slatec-fn/atanh.lo 
slatec-fn/betai.lo slatec-fn/csevl.lo slatec-fn/d9gmit.lo 
slatec-fn/d9lgic.lo slatec-fn/d9lgit.lo slatec-fn/d9lgmc.lo 
slatec-fn/dacosh.lo slatec-fn/dasinh.lo slatec-fn/datanh.lo 
slatec-fn/dbetai.lo slatec-fn/dcsevl.lo slatec-fn/derf.lo 
slatec-fn/derfc.lo slatec-fn/dgami.lo slatec-fn/dgamit.lo 
slatec-fn/dgamlm.lo slatec-fn/dgamma.lo slatec-fn/dgamr.lo 
slatec-fn/dlbeta.lo slatec-fn/dlgams.lo slatec-fn/dlngam.lo 
slatec-fn/dlnrel.lo slatec-fn/dpchim.lo slatec-fn/dpchst.lo 
slatec-fn/erf.lo slatec-fn/erfc.lo slatec-fn/gami.lo slatec-fn/gamit.lo 
slatec-fn/gamlim.lo slatec-fn/gamma.lo slatec-fn/gamr.lo 
slatec-fn/initds.lo slatec-fn/inits.lo slatec-fn/pchim.lo 
slatec-fn/pchst.lo slatec-fn/r9lgmc.lo slatec-fn/r9lgit.lo 
slatec-fn/r9gmit.lo slatec-fn/r9lgic.lo slatec-fn/xdacosh.lo 
slatec-fn/xdasinh.lo slatec-fn/xdatanh.lo slatec-fn/xdbetai.lo 
slatec-fn/xderf.lo slatec-fn/xderfc.lo slatec-fn/xdgami.lo 
slatec-fn/xdgamit.lo slatec-fn/xdgamma.lo slatec-fn/xgmainc.lo 
slatec-fn/xacosh.lo slatec-fn/xasinh.lo slatec-fn/xatanh.lo 
slatec-fn/xerf.lo slatec-fn/xerfc.lo slatec-fn/xsgmainc.lo 
slatec-fn/xgamma.lo slatec-fn/xbetai.lo villad/dfopr.lo villad/dif.lo 
villad/intrp.lo villad/jcobi.lo villad/radau.lo villad/vilerr.lo 
-liberty -lm  -lgdi32 -lws2_32 -luser32 -lkernel32
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
shared libraries
libtool: link: rm -fr  .libs/libcruft.dll.a

*** Warning: linker path does not have real file for library -liberty.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libiberty and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libiberty.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

libtool: link: mingw32-g++-4.4.0-dw2 -shared-libgcc -shared -nostdlib 
d:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/../../../dllcrt2.o 
d:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/crtbegin.o 
  amos/.libs/cacai.o amos/.libs/cacon.o amos/.libs/cbesh.o 
amos/.libs/cbesi.o amos/.libs/cbesj.o amos/.libs/cbesk.o 
amos/.libs/cbesy.o amos/.libs/cbinu.o amos/.libs/cbuni.o 
amos/.libs/cbunk.o amos/.libs/cunk1.o amos/.libs/cunk2.o 
amos/.libs/crati.o amos/.libs/cshch.o amos/.libs/cuni1.o 
amos/.libs/cuoik.o amos/.libs/cairy.o amos/.libs/cbiry.o 
amos/.libs/ckscl.o amos/.libs/cs1s2.o amos/.libs/cuchk.o 
amos/.libs/cuni2.o amos/.libs/cwrsk.o amos/.libs/casyi.o 
amos/.libs/cbknu.o amos/.libs/cmlri.o amos/.libs/cseri.o 
amos/.libs/cunhj.o amos/.libs/cunik.o amos/.libs/dgamln.o 
amos/.libs/gamln.o amos/.libs/xzabs.o amos/.libs/xzexp.o 
amos/.libs/xzlog.o amos/.libs/xzsqrt.o amos/.libs/zacai.o 
amos/.libs/zacon.o amos/.libs/zairy.o amos/.libs/zasyi.o 
amos/.libs/zbesh.o amos/.libs/zbesi.o amos/.libs/zbesj.o 
amos/.libs/zbesk.o amos/.libs/zbesy.o amos/.libs/zbinu.o 
amos/.libs/zbiry.o amos/.libs/zbknu.o amos/.libs/zbuni.o 
amos/.libs/zbunk.o amos/.libs/zdiv.o amos/.libs/zkscl.o 
amos/.libs/zmlri.o amos/.libs/zmlt.o amos/.libs/zrati.o 
amos/.libs/zs1s2.o amos/.libs/zseri.o amos/.libs/zshch.o 
amos/.libs/zuchk.o amos/.libs/zunhj.o amos/.libs/zuni1.o 
amos/.libs/zuni2.o amos/.libs/zunik.o amos/.libs/zunk1.o 
amos/.libs/zunk2.o amos/.libs/zuoik.o amos/.libs/zwrsk.o 
blas-xtra/.libs/xddot.o blas-xtra/.libs/xdnrm2.o 
blas-xtra/.libs/xdznrm2.o blas-xtra/.libs/xzdotc.o 
blas-xtra/.libs/xzdotu.o blas-xtra/.libs/xsdot.o 
blas-xtra/.libs/xsnrm2.o blas-xtra/.libs/xscnrm2.o 
blas-xtra/.libs/xcdotc.o blas-xtra/.libs/xcdotu.o 
blas-xtra/.libs/xerbla.o daspk/.libs/datv.o daspk/.libs/dcnst0.o 
daspk/.libs/dcnstr.o daspk/.libs/ddasic.o daspk/.libs/ddasid.o 
daspk/.libs/ddasik.o daspk/.libs/ddaspk.o daspk/.libs/ddstp.o 
daspk/.libs/ddwnrm.o daspk/.libs/dfnrmd.o daspk/.libs/dfnrmk.o 
daspk/.libs/dhels.o daspk/.libs/dheqr.o daspk/.libs/dinvwt.o 
daspk/.libs/dlinsd.o daspk/.libs/dlinsk.o daspk/.libs/dmatd.o 
daspk/.libs/dnedd.o daspk/.libs/dnedk.o daspk/.libs/dnsd.o 
daspk/.libs/dnsid.o daspk/.libs/dnsik.o daspk/.libs/dnsk.o 
daspk/.libs/dorth.o daspk/.libs/dslvd.o daspk/.libs/dslvk.o 
daspk/.libs/dspigm.o daspk/.libs/dyypnw.o dasrt/.libs/ddasrt.o 
dasrt/.libs/drchek.o dasrt/.libs/droots.o dassl/.libs/ddaini.o 
dassl/.libs/ddajac.o dassl/.libs/ddanrm.o dassl/.libs/ddaslv.o 
dassl/.libs/ddassl.o dassl/.libs/ddastp.o dassl/.libs/ddatrp.o 
dassl/.libs/ddawts.o lapack-xtra/.libs/xclange.o 
lapack-xtra/.libs/xdlamch.o lapack-xtra/.libs/xdlange.o 
lapack-xtra/.libs/xilaenv.o lapack-xtra/.libs/xslamch.o 
lapack-xtra/.libs/xslange.o lapack-xtra/.libs/xzlange.o 
misc/.libs/cquit.o misc/.libs/d1mach.o misc/.libs/f77-extern.o 
misc/.libs/f77-fcn.o misc/.libs/i1mach.o misc/.libs/lo-error.o 
misc/.libs/quit.o misc/.libs/r1mach.o odepack/.libs/cfode.o 
odepack/.libs/dlsode.o odepack/.libs/ewset.o odepack/.libs/intdy.o 
odepack/.libs/prepj.o odepack/.libs/solsy.o odepack/.libs/stode.o 
odepack/.libs/vnorm.o odepack/.libs/scfode.o odepack/.libs/sewset.o 
odepack/.libs/sintdy.o odepack/.libs/slsode.o odepack/.libs/sprepj.o 
odepack/.libs/ssolsy.o odepack/.libs/sstode.o odepack/.libs/svnorm.o 
ordered-qz/.libs/dsubsp.o ordered-qz/.libs/exchqz.o 
ordered-qz/.libs/ssubsp.o ordered-qz/.libs/sexchqz.o 
quadpack/.libs/dqagi.o quadpack/.libs/dqagie.o quadpack/.libs/dqagp.o 
quadpack/.libs/dqagpe.o quadpack/.libs/dqelg.o quadpack/.libs/dqk15i.o 
quadpack/.libs/dqk21.o quadpack/.libs/dqpsrt.o quadpack/.libs/qagie.o 
quadpack/.libs/qagi.o quadpack/.libs/qagpe.o quadpack/.libs/qagp.o 
quadpack/.libs/qelg.o quadpack/.libs/qk15i.o quadpack/.libs/qk21.o 
quadpack/.libs/qpsrt.o quadpack/.libs/xerror.o ranlib/.libs/advnst.o 
ranlib/.libs/genbet.o ranlib/.libs/genchi.o ranlib/.libs/genexp.o 
ranlib/.libs/genf.o ranlib/.libs/gengam.o ranlib/.libs/genmn.o 
ranlib/.libs/genmul.o ranlib/.libs/gennch.o ranlib/.libs/gennf.o 
ranlib/.libs/gennor.o ranlib/.libs/genprm.o ranlib/.libs/genunf.o 
ranlib/.libs/getcgn.o ranlib/.libs/getsd.o ranlib/.libs/ignbin.o 
ranlib/.libs/ignlgi.o ranlib/.libs/ignnbn.o ranlib/.libs/ignpoi.o 
ranlib/.libs/ignuin.o ranlib/.libs/initgn.o ranlib/.libs/inrgcm.o 
ranlib/.libs/lennob.o ranlib/.libs/mltmod.o ranlib/.libs/phrtsd.o 
ranlib/.libs/qrgnin.o ranlib/.libs/ranf.o ranlib/.libs/setall.o 
ranlib/.libs/setant.o ranlib/.libs/setgmn.o ranlib/.libs/setsd.o 
ranlib/.libs/sexpo.o ranlib/.libs/sgamma.o ranlib/.libs/snorm.o 
ranlib/.libs/wrap.o slatec-err/.libs/fdump.o slatec-err/.libs/ixsav.o 
slatec-err/.libs/j4save.o slatec-err/.libs/xerclr.o 
slatec-err/.libs/xercnt.o slatec-err/.libs/xerhlt.o 
slatec-err/.libs/xermsg.o slatec-err/.libs/xerprn.o 
slatec-err/.libs/xerrwd.o slatec-err/.libs/xersve.o 
slatec-err/.libs/xgetf.o slatec-err/.libs/xgetua.o 
slatec-err/.libs/xsetf.o slatec-err/.libs/xsetua.o 
slatec-fn/.libs/albeta.o slatec-fn/.libs/alngam.o 
slatec-fn/.libs/alnrel.o slatec-fn/.libs/algams.o 
slatec-fn/.libs/acosh.o slatec-fn/.libs/asinh.o slatec-fn/.libs/atanh.o 
slatec-fn/.libs/betai.o slatec-fn/.libs/csevl.o slatec-fn/.libs/d9gmit.o 
slatec-fn/.libs/d9lgic.o slatec-fn/.libs/d9lgit.o 
slatec-fn/.libs/d9lgmc.o slatec-fn/.libs/dacosh.o 
slatec-fn/.libs/dasinh.o slatec-fn/.libs/datanh.o 
slatec-fn/.libs/dbetai.o slatec-fn/.libs/dcsevl.o slatec-fn/.libs/derf.o 
slatec-fn/.libs/derfc.o slatec-fn/.libs/dgami.o slatec-fn/.libs/dgamit.o 
slatec-fn/.libs/dgamlm.o slatec-fn/.libs/dgamma.o 
slatec-fn/.libs/dgamr.o slatec-fn/.libs/dlbeta.o 
slatec-fn/.libs/dlgams.o slatec-fn/.libs/dlngam.o 
slatec-fn/.libs/dlnrel.o slatec-fn/.libs/dpchim.o 
slatec-fn/.libs/dpchst.o slatec-fn/.libs/erf.o slatec-fn/.libs/erfc.o 
slatec-fn/.libs/gami.o slatec-fn/.libs/gamit.o slatec-fn/.libs/gamlim.o 
slatec-fn/.libs/gamma.o slatec-fn/.libs/gamr.o slatec-fn/.libs/initds.o 
slatec-fn/.libs/inits.o slatec-fn/.libs/pchim.o slatec-fn/.libs/pchst.o 
slatec-fn/.libs/r9lgmc.o slatec-fn/.libs/r9lgit.o 
slatec-fn/.libs/r9gmit.o slatec-fn/.libs/r9lgic.o 
slatec-fn/.libs/xdacosh.o slatec-fn/.libs/xdasinh.o 
slatec-fn/.libs/xdatanh.o slatec-fn/.libs/xdbetai.o 
slatec-fn/.libs/xderf.o slatec-fn/.libs/xderfc.o 
slatec-fn/.libs/xdgami.o slatec-fn/.libs/xdgamit.o 
slatec-fn/.libs/xdgamma.o slatec-fn/.libs/xgmainc.o 
slatec-fn/.libs/xacosh.o slatec-fn/.libs/xasinh.o 
slatec-fn/.libs/xatanh.o slatec-fn/.libs/xerf.o slatec-fn/.libs/xerfc.o 
slatec-fn/.libs/xsgmainc.o slatec-fn/.libs/xgamma.o 
slatec-fn/.libs/xbetai.o villad/.libs/dfopr.o villad/.libs/dif.o 
villad/.libs/intrp.o villad/.libs/jcobi.o villad/.libs/radau.o 
villad/.libs/vilerr.o   -lgdi32 -lws2_32 -luser32 -lkernel32 
-Ld:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0 
-Ld:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc 
-LD:/build/octave32/tip_gcc-4.4.0/msys-1.0.11/local/octmgw32_gcc-4.4.0-dw2/lib 
-Ld:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/lib 
-Ld:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/../../.. 
-lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 
-lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt 
d:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/crtend.o 
  -march=i686 -mtune=generic -mieee-fp -march=i686 -mtune=generic 
-march=i686 -mtune=generic -Wl,--allow-multiple-definition   -o 
.libs/cruft.dll -Wl,--enable-auto-image-base -Xlinker --out-implib 
-Xlinker .libs/libcruft.dll.a
Creating library file: 
.libs/libcruft.dll.ablas-xtra/.libs/xddot.o:xddot.f:(.text+0x29): 
undefined reference to `ddot_'
blas-xtra/.libs/xdnrm2.o:xdnrm2.f:(.text+0x1b): undefined reference to 
`dnrm2_'
blas-xtra/.libs/xdznrm2.o:xdznrm2.f:(.text+0x1b): undefined reference to 
`dznrm2_'
blas-xtra/.libs/xzdotc.o:xzdotc.f:(.text+0x34): undefined reference to 
`zdotc_'
blas-xtra/.libs/xzdotu.o:xzdotu.f:(.text+0x34): undefined reference to 
`zdotu_'
blas-xtra/.libs/xsdot.o:xsdot.f:(.text+0x29): undefined reference to `sdot_'
blas-xtra/.libs/xsnrm2.o:xsnrm2.f:(.text+0x1b): undefined reference to 
`snrm2_'
blas-xtra/.libs/xscnrm2.o:xscnrm2.f:(.text+0x1b): undefined reference to 
`scnrm2_'
blas-xtra/.libs/xcdotc.o:xcdotc.f:(.text+0x2d): undefined reference to 
`cdotc_'
blas-xtra/.libs/xcdotu.o:xcdotu.f:(.text+0x2d): undefined reference to 
`cdotu_'
blas-xtra/.libs/xerbla.o:xerbla.f:(.text+0x50): undefined reference to 
`_gfortran_st_write'
blas-xtra/.libs/xerbla.o:xerbla.f:(.text+0x67): undefined reference to 
`_gfortran_transfer_character'
blas-xtra/.libs/xerbla.o:xerbla.f:(.text+0x7e): undefined reference to 
`_gfortran_transfer_integer'
blas-xtra/.libs/xerbla.o:xerbla.f:(.text+0x86): undefined reference to 
`_gfortran_st_write_done'
daspk/.libs/ddasic.o:ddasic.f:(.text+0x87): undefined reference to `dcopy_'

( the undefined reference list the continues rather long )


I get the same result if I do *not* specify "-no-undefined" in libtool's 
  link command in libcruft/makefile, and patch libtool as follows

$ diff -u .build_mingw32_octave-tip-automake-ref-4_gcc-4.4.0-dw2/libtool 
.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libtool-mod2-works
--- .build_mingw32_octave-tip-automake-ref-4_gcc-4.4.0-dw2/libtool 
2009-10-31 11:08:08 +0100
+++ 
.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libtool-mod2-works 
     2009-10-31 11:39:24 +0100
@@ -7744,7 +7744,7 @@
         if test "$allow_undefined" = yes; then
           if test "$allow_undefined_flag" = unsupported; then
             func_warning "undefined symbols not allowed in $host shared 
libraries"
-           build_libtool_libs=no
+           build_libtool_libs=yes
             build_old_libs=yes
           fi
         else


Now this undefined refernece link error I can understand, since 
libcruft's dependency libraries are all missing on the link command.

I need to add $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) as in

@@ -4325,7 +4325,7 @@
  villad/vilerr.lo: villad/$(am__dirstamp) \
         villad/$(DEPDIR)/$(am__dirstamp)
  libcruft.la: $(libcruft_la_OBJECTS) $(libcruft_la_DEPENDENCIES)
-       $(libcruft_la_LINK) -rpath $(octlibdir) $(libcruft_la_OBJECTS) 
$(libcruft_la_LIBADD) $(LIBS)
+       $(libcruft_la_LINK) -rpath $(octlibdir) $(libcruft_la_OBJECTS) 
$(libcruft_la_LIBADD) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(LIBS)

  mostlyclean-compile:
         -rm -f *.$(OBJEXT)


Then I finally get cruft.dll.

There was already a mail session dealing with all the undefined 
reference/dependency libraries issues, wasn't there?

> In any case, I don't plan to reverse the decision to use libtool and
> automake, because I want to be able to use functions from gnulib, and
> as far as I can tell, that is just not practical without automake and
> libtool.

Yes, I feared you'd say that. I see that I am on a lone post against 
libtool.
Well, it's your decision. I'll respect it.

> I can try to help you debug the problems, but you will have to send
> more information about exactly what is happening.  Or, I need to know
> how to duplicate the build environment you have, then I can try to
> find a Windows system that I can use to debug the configuration
> problems.

 From what I saw until now, if I patch libtool as above and we get the 
dependency libraries for libcruft (possibly also for liboctave and 
liboctinterp?) right, then it should work.
I'm curious how the .oct creation will behave.

benjamin

From lindnerben at gmx.net  Sat Oct 31 08:11:55 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sat, 31 Oct 2009 14:11:55 +0100
Subject: gnulib and automake
In-Reply-To: <4AEC1A96.4020108@gmx.net>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<4AEB36F9.9070404@gmx.net>	<19179.15601.907503.686285@segfault.lan>	<4AEB46EE.8030400@gmx.net>	<19179.21624.130899.537300@segfault.lan>	<4AEB58DA.9070805@gmx.net>	<19179.26026.448430.104714@segfault.lan>
	<4AEC1A96.4020108@gmx.net>
Message-ID: <4AEC379B.30501@gmx.net>

Benjamin Lindner wrote:
> 
>  From what I saw until now, if I patch libtool as above and we get the 
> dependency libraries for libcruft (possibly also for liboctave and 
> liboctinterp?) right, then it should work.
> I'm curious how the .oct creation will behave.
> 

An update:

Using the following patch for the generated libtool

--- .build_mingw32_octave-tip-automake-ref-4_gcc-4.4.0-dw2/libtool 
2009-10-31 11:08:08 +0100
+++ .build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libtool 
2009-10-31 11:39:24 +0100
@@ -7744,7 +7744,7 @@
  	if test "$allow_undefined" = yes; then
  	  if test "$allow_undefined_flag" = unsupported; then
  	    func_warning "undefined symbols not allowed in $host shared 
libraries"
-	    build_libtool_libs=no
+	    build_libtool_libs=yes
  	    build_old_libs=yes
  	  fi
  	else


and the following change on octave's makefile sources

diff -r 5382a2ab87e7 libcruft/Makefile.am
--- a/libcruft/Makefile.am	Fri Oct 30 11:10:14 2009 -0400
+++ b/libcruft/Makefile.am	Sat Oct 31 14:08:00 2009 +0100
@@ -31,6 +31,8 @@

  libcruft_la_LDFLAGS = -release $(version)

+libcruft_la_LIBADD = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
+
  octinclude_HEADERS =

  EXTRA_DIST = ChangeLog STOP.patch mkf77def.in
diff -r 5382a2ab87e7 liboctave/Makefile.am
--- a/liboctave/Makefile.am	Fri Oct 30 11:10:14 2009 -0400
+++ b/liboctave/Makefile.am	Sat Oct 31 14:08:00 2009 +0100
@@ -494,10 +494,10 @@
  LINK_DEPS = \
    $(RLD_FLAG) \
    ../libcruft/libcruft.la \
-  $(SPARSE_LDFLAGS) $(SPARSE_LIBS) \
+  $(SPARSE_LDFLAGS) $(SPARSE_XLIBS) \
    $(ARPACK_LIBS) \
    $(QRUPDATE_LIBS) \
-  $(FFTW_LDFLAGS) $(FFTW_LIBS) \
+  $(FFTW_LDFLAGS) $(FFTW_XLIBS) \
    $(LAPACK_LIBS) $(BLAS_LIBS) \
    $(READLINE_LIBS) $(TERM_LIBS) \
    $(LIBGLOB) $(REGEX_LIBS) $(DL_LIBS) \

I get both cruft.dll and octave.dll

However, building liboctinterp still fails. No shared library is created 
and building .oct file fails with a lot of "undefined reference" errors.
I need to debug further.

benjamin

From jwe at octave.org  Sat Oct 31 10:52:50 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 31 Oct 2009 11:52:50 -0400
Subject: gnulib and automake
In-Reply-To: <4AEC1A96.4020108@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net>
	<19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net>
	<19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net>
	<19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net>
Message-ID: <19180.23890.807202.518048@segfault.lan>

On 31-Oct-2009, Benjamin Lindner wrote:

| > In any case, I don't plan to reverse the decision to use libtool and
| > automake, because I want to be able to use functions from gnulib, and
| > as far as I can tell, that is just not practical without automake and
| > libtool.
| 
| Yes, I feared you'd say that. I see that I am on a lone post against 
| libtool.
| Well, it's your decision. I'll respect it.
| 
| > I can try to help you debug the problems, but you will have to send
| > more information about exactly what is happening.  Or, I need to know
| > how to duplicate the build environment you have, then I can try to
| > find a Windows system that I can use to debug the configuration
| > problems.
| 
|  From what I saw until now, if I patch libtool as above and we get the 
| dependency libraries for libcruft (possibly also for liboctave and 
| liboctinterp?) right, then it should work.
| I'm curious how the .oct creation will behave.

Instead of the changes you have made, can we back up and start by
changing the LT_INIT call in configue.ac to be

  LT_INIT([disable-static win32-dll])

?  I missed the win32-dll option earlier, but I would expect it to
help some.  Other changes may still be required.  If so, then I think
we should report our experience to the libtool maintainers.

jwe


From jwe at octave.org  Sat Oct 31 10:56:56 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 31 Oct 2009 11:56:56 -0400
Subject: gnulib and automake
In-Reply-To: <4AEC379B.30501@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net>
	<19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net>
	<19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net>
	<19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net>
	<4AEC379B.30501@gmx.net>
Message-ID: <19180.24136.284748.249375@segfault.lan>

On 31-Oct-2009, Benjamin Lindner wrote:

| Benjamin Lindner wrote:
| > 
| >  From what I saw until now, if I patch libtool as above and we get the 
| > dependency libraries for libcruft (possibly also for liboctave and 
| > liboctinterp?) right, then it should work.
| > I'm curious how the .oct creation will behave.
| > 
| 
| An update:
| 
| Using the following patch for the generated libtool
| 
| --- .build_mingw32_octave-tip-automake-ref-4_gcc-4.4.0-dw2/libtool 
| 2009-10-31 11:08:08 +0100
| +++ .build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libtool 
| 2009-10-31 11:39:24 +0100
| @@ -7744,7 +7744,7 @@
|   	if test "$allow_undefined" = yes; then
|   	  if test "$allow_undefined_flag" = unsupported; then
|   	    func_warning "undefined symbols not allowed in $host shared 
| libraries"
| -	    build_libtool_libs=no
| +	    build_libtool_libs=yes
|   	    build_old_libs=yes
|   	  fi
|   	else

Is this needed if you use the win32-dll option for LT_INIT in
configure.ac?

| and the following change on octave's makefile sources
| 
| diff -r 5382a2ab87e7 libcruft/Makefile.am
| --- a/libcruft/Makefile.am	Fri Oct 30 11:10:14 2009 -0400
| +++ b/libcruft/Makefile.am	Sat Oct 31 14:08:00 2009 +0100
| @@ -31,6 +31,8 @@
| 
|   libcruft_la_LDFLAGS = -release $(version)
| 
| +libcruft_la_LIBADD = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
| +
|   octinclude_HEADERS =
| 
|   EXTRA_DIST = ChangeLog STOP.patch mkf77def.in
| diff -r 5382a2ab87e7 liboctave/Makefile.am
| --- a/liboctave/Makefile.am	Fri Oct 30 11:10:14 2009 -0400
| +++ b/liboctave/Makefile.am	Sat Oct 31 14:08:00 2009 +0100
| @@ -494,10 +494,10 @@
|   LINK_DEPS = \
|     $(RLD_FLAG) \
|     ../libcruft/libcruft.la \
| -  $(SPARSE_LDFLAGS) $(SPARSE_LIBS) \
| +  $(SPARSE_LDFLAGS) $(SPARSE_XLIBS) \
|     $(ARPACK_LIBS) \
|     $(QRUPDATE_LIBS) \
| -  $(FFTW_LDFLAGS) $(FFTW_LIBS) \
| +  $(FFTW_LDFLAGS) $(FFTW_XLIBS) \
|     $(LAPACK_LIBS) $(BLAS_LIBS) \
|     $(READLINE_LIBS) $(TERM_LIBS) \
|     $(LIBGLOB) $(REGEX_LIBS) $(DL_LIBS) \
| 
| I get both cruft.dll and octave.dll
| 
| However, building liboctinterp still fails. No shared library is created 
| and building .oct file fails with a lot of "undefined reference" errors.
| I need to debug further.

I made these changes.

Thanks,

jwe

From lindnerben at gmx.net  Sat Oct 31 11:15:53 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sat, 31 Oct 2009 17:15:53 +0100
Subject: gnulib and automake
In-Reply-To: <4AEC379B.30501@gmx.net>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<4AEB36F9.9070404@gmx.net>	<19179.15601.907503.686285@segfault.lan>	<4AEB46EE.8030400@gmx.net>	<19179.21624.130899.537300@segfault.lan>	<4AEB58DA.9070805@gmx.net>	<19179.26026.448430.104714@segfault.lan>	<4AEC1A96.4020108@gmx.net>
	<4AEC379B.30501@gmx.net>
Message-ID: <4AEC62B9.4050008@gmx.net>

Benjamin Lindner wrote:
> Benjamin Lindner wrote:
>>
>>  From what I saw until now, if I patch libtool as above and we get the 
>> dependency libraries for libcruft (possibly also for liboctave and 
>> liboctinterp?) right, then it should work.
>> I'm curious how the .oct creation will behave.
>>
> 
> An update:
> 
> Using the following patch for the generated libtool
> 
> --- .build_mingw32_octave-tip-automake-ref-4_gcc-4.4.0-dw2/libtool 
> 2009-10-31 11:08:08 +0100
> +++ .build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libtool 
> 2009-10-31 11:39:24 +0100
> @@ -7744,7 +7744,7 @@
>      if test "$allow_undefined" = yes; then
>        if test "$allow_undefined_flag" = unsupported; then
>          func_warning "undefined symbols not allowed in $host shared 
> libraries"
> -        build_libtool_libs=no
> +        build_libtool_libs=yes
>          build_old_libs=yes
>        fi
>      else
> 
> 
> and the following change on octave's makefile sources
> 
> diff -r 5382a2ab87e7 libcruft/Makefile.am
> --- a/libcruft/Makefile.am    Fri Oct 30 11:10:14 2009 -0400
> +++ b/libcruft/Makefile.am    Sat Oct 31 14:08:00 2009 +0100
> @@ -31,6 +31,8 @@
> 
>  libcruft_la_LDFLAGS = -release $(version)
> 
> +libcruft_la_LIBADD = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
> +
>  octinclude_HEADERS =
> 
>  EXTRA_DIST = ChangeLog STOP.patch mkf77def.in
> diff -r 5382a2ab87e7 liboctave/Makefile.am
> --- a/liboctave/Makefile.am    Fri Oct 30 11:10:14 2009 -0400
> +++ b/liboctave/Makefile.am    Sat Oct 31 14:08:00 2009 +0100
> @@ -494,10 +494,10 @@
>  LINK_DEPS = \
>    $(RLD_FLAG) \
>    ../libcruft/libcruft.la \
> -  $(SPARSE_LDFLAGS) $(SPARSE_LIBS) \
> +  $(SPARSE_LDFLAGS) $(SPARSE_XLIBS) \
>    $(ARPACK_LIBS) \
>    $(QRUPDATE_LIBS) \
> -  $(FFTW_LDFLAGS) $(FFTW_LIBS) \
> +  $(FFTW_LDFLAGS) $(FFTW_XLIBS) \
>    $(LAPACK_LIBS) $(BLAS_LIBS) \
>    $(READLINE_LIBS) $(TERM_LIBS) \
>    $(LIBGLOB) $(REGEX_LIBS) $(DL_LIBS) \
> 
> I get both cruft.dll and octave.dll
> 
> However, building liboctinterp still fails. No shared library is created 
> and building .oct file fails with a lot of "undefined reference" errors.
> I need to debug further.
> 

If I additionally patch libtool as
--- .build_mingw32_octave-tip-automake-ref-4_gcc-4.4.0-dw2/libtool 
2009-10-31 11:08:08 +0100
+++ .build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libtool 
2009-10-31 16:44:30 +0100
@@ -345,7 +345,7 @@
  with_gnu_ld="yes"

  # Flag that allows shared libraries with undefined symbols to be built.
-allow_undefined_flag="unsupported"
+allow_undefined_flag="-Wl,--allow-shlib-undefined"

  # Flag that enforces no undefined symbols.
  no_undefined_flag=""


Then it at last gracefully tried to build a shared liboctinterp, however 
it fails with

/bin/sh ../libtool --tag=CXX --verbose  --mode=link 
mingw32-g++-4.4.0-dw2 -shared-libgcc -march=i686 -mtune=generic -O3 
-Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W -Wshadow -Wold-style-cast 
-Wformat -march=i686 -mtune=generic -O3 -Wall  -march=i686 
-mtune=generic -O3 -Wall -release 3.3.50+ -shared-libgcc 
-Wl,--allow-multiple-definition -o liboctinterp.la -rpath 
/usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
Cell.lo bitfcns.lo c-file-ptr-stream.lo comment-list.lo cutils.lo 
data.lo debug.lo defaults.lo defun.lo dirfns.lo display.lo dynamic-ld.lo 
error.lo file-io.lo gl-render.lo graphics.lo gripes.lo help.lo input.lo 
lex.lo load-path.lo load-save.lo ls-ascii-helper.lo ls-hdf5.lo 
ls-mat-ascii.lo ls-mat4.lo ls-mat5.lo ls-oct-ascii.lo ls-oct-binary.lo 
ls-utils.lo mappers.lo matherr.lo mex.lo oct-fstrm.lo oct-hist.lo 
oct-iostrm.lo oct-lvalue.lo oct-map.lo oct-obj.lo oct-parse.lo 
oct-prcstrm.lo oct-procbuf.lo oct-stream.lo oct-strstrm.lo octave.lo 
pager.lo pr-output.lo procstream.lo sighandlers.lo siglist.lo 
sparse-xdiv.lo sparse-xpow.lo strfns.lo symtab.lo syscalls.lo sysdep.lo 
token.lo toplev.lo txt-eng-ft.lo unwind-prot.lo utils.lo variables.lo 
xdiv.lo xnorm.lo xpow.lo zfstream.lo ov-base.lo ov-bool-mat.lo 
ov-bool.lo ov-builtin.lo ov-cell.lo ov-ch-mat.lo ov-class.lo ov-colon.lo 
ov-complex.lo ov-cs-list.lo ov-cx-diag.lo ov-cx-mat.lo ov-dld-fcn.lo 
ov-fcn-handle.lo ov-fcn-inline.lo ov-fcn.lo ov-float.lo 
ov-flt-complex.lo ov-flt-cx-diag.lo ov-flt-cx-mat.lo ov-flt-re-diag.lo 
ov-flt-re-mat.lo ov-list.lo ov-mex-fcn.lo ov-null-mat.lo ov-perm.lo 
ov-range.lo ov-re-diag.lo ov-re-mat.lo ov-scalar.lo ov-str-mat.lo 
ov-struct.lo ov-typeinfo.lo ov-usr-fcn.lo ov.lo ov-int16.lo ov-int32.lo 
ov-int64.lo ov-int8.lo ov-uint16.lo ov-uint32.lo ov-uint64.lo 
ov-uint8.lo ov-base-sparse.lo ov-bool-sparse.lo ov-cx-sparse.lo 
ov-re-sparse.lo pt-arg-list.lo pt-assign.lo pt-binop.lo pt-bp.lo 
pt-cbinop.lo pt-cell.lo pt-check.lo pt-cmd.lo pt-colon.lo pt-const.lo 
pt-decl.lo pt-eval.lo pt-except.lo pt-exp.lo pt-fcn-handle.lo pt-id.lo 
pt-idx.lo pt-jump.lo pt-loop.lo pt-mat.lo pt-misc.lo pt-pr-code.lo 
pt-select.lo pt-stmt.lo pt-unop.lo pt.lo  OPERATORS/op-b-b.lo 
OPERATORS/op-b-bm.lo OPERATORS/op-b-sbm.lo OPERATORS/op-bm-b.lo 
OPERATORS/op-bm-bm.lo OPERATORS/op-bm-sbm.lo OPERATORS/op-cdm-cdm.lo 
OPERATORS/op-cdm-cm.lo OPERATORS/op-cdm-cs.lo OPERATORS/op-cdm-dm.lo 
OPERATORS/op-cdm-m.lo OPERATORS/op-cdm-s.lo OPERATORS/op-cell.lo 
OPERATORS/op-chm.lo OPERATORS/op-class.lo OPERATORS/op-cm-cdm.lo 
OPERATORS/op-cm-cm.lo OPERATORS/op-cm-cs.lo OPERATORS/op-cm-dm.lo 
OPERATORS/op-cm-m.lo OPERATORS/op-cm-pm.lo OPERATORS/op-cm-s.lo 
OPERATORS/op-cm-scm.lo OPERATORS/op-cm-sm.lo OPERATORS/op-cs-cm.lo 
OPERATORS/op-cs-cs.lo OPERATORS/op-cs-m.lo OPERATORS/op-cs-s.lo 
OPERATORS/op-cs-scm.lo OPERATORS/op-cs-sm.lo OPERATORS/op-dm-cdm.lo 
OPERATORS/op-dm-cm.lo OPERATORS/op-dm-cs.lo OPERATORS/op-dm-dm.lo 
OPERATORS/op-dm-m.lo OPERATORS/op-dm-s.lo OPERATORS/op-dm-scm.lo 
OPERATORS/op-dm-sm.lo OPERATORS/op-double-conv.lo 
OPERATORS/op-fcdm-fcdm.lo OPERATORS/op-fcdm-fcm.lo 
OPERATORS/op-fcdm-fcs.lo OPERATORS/op-fcdm-fdm.lo 
OPERATORS/op-fcdm-fm.lo OPERATORS/op-fcdm-fs.lo OPERATORS/op-fcm-fcdm.lo 
OPERATORS/op-fcm-fcm.lo OPERATORS/op-fcm-fcs.lo OPERATORS/op-fcm-fdm.lo 
OPERATORS/op-fcm-fm.lo OPERATORS/op-fcm-fs.lo OPERATORS/op-fcm-pm.lo 
OPERATORS/op-fcs-fcm.lo OPERATORS/op-fcs-fcs.lo OPERATORS/op-fcs-fm.lo 
OPERATORS/op-fcs-fs.lo OPERATORS/op-fdm-fcdm.lo OPERATORS/op-fdm-fcm.lo 
OPERATORS/op-fdm-fcs.lo OPERATORS/op-fdm-fdm.lo OPERATORS/op-fdm-fm.lo 
OPERATORS/op-fdm-fs.lo OPERATORS/op-float-conv.lo 
OPERATORS/op-fm-fcdm.lo OPERATORS/op-fm-fcm.lo OPERATORS/op-fm-fcs.lo 
OPERATORS/op-fm-fdm.lo OPERATORS/op-fm-fm.lo OPERATORS/op-fm-fs.lo 
OPERATORS/op-fm-pm.lo OPERATORS/op-fs-fcm.lo OPERATORS/op-fs-fcs.lo 
OPERATORS/op-fs-fm.lo OPERATORS/op-fs-fs.lo OPERATORS/op-i16-i16.lo 
OPERATORS/op-i32-i32.lo OPERATORS/op-i64-i64.lo OPERATORS/op-i8-i8.lo 
OPERATORS/op-int-concat.lo OPERATORS/op-int-conv.lo OPERATORS/op-list.lo 
OPERATORS/op-m-cdm.lo OPERATORS/op-m-cm.lo OPERATORS/op-m-cs.lo 
OPERATORS/op-m-dm.lo OPERATORS/op-m-m.lo OPERATORS/op-m-pm.lo 
OPERATORS/op-m-s.lo OPERATORS/op-m-scm.lo OPERATORS/op-m-sm.lo 
OPERATORS/op-pm-cm.lo OPERATORS/op-pm-fcm.lo OPERATORS/op-pm-fm.lo 
OPERATORS/op-pm-m.lo OPERATORS/op-pm-pm.lo OPERATORS/op-pm-scm.lo 
OPERATORS/op-pm-sm.lo OPERATORS/op-range.lo OPERATORS/op-s-cm.lo 
OPERATORS/op-s-cs.lo OPERATORS/op-s-m.lo OPERATORS/op-s-s.lo 
OPERATORS/op-s-scm.lo OPERATORS/op-s-sm.lo OPERATORS/op-sbm-b.lo 
OPERATORS/op-sbm-bm.lo OPERATORS/op-sbm-sbm.lo OPERATORS/op-scm-cm.lo 
OPERATORS/op-scm-cs.lo OPERATORS/op-scm-m.lo OPERATORS/op-scm-s.lo 
OPERATORS/op-scm-scm.lo OPERATORS/op-scm-sm.lo OPERATORS/op-sm-cm.lo 
OPERATORS/op-sm-cs.lo OPERATORS/op-sm-m.lo OPERATORS/op-sm-s.lo 
OPERATORS/op-sm-scm.lo OPERATORS/op-sm-sm.lo OPERATORS/op-str-m.lo 
OPERATORS/op-str-s.lo OPERATORS/op-str-str.lo OPERATORS/op-struct.lo 
OPERATORS/op-ui16-ui16.lo OPERATORS/op-ui32-ui32.lo 
OPERATORS/op-ui64-ui64.lo OPERATORS/op-ui8-ui8.lo 
TEMPLATE-INST/Array-os.lo TEMPLATE-INST/Array-tc.lo builtins.lo 
oct-errno.lo ops.lo DASPK-opts.lo DASRT-opts.lo DASSL-opts.lo 
LSODE-opts.lo Quad-opts.lo   ../liboctave/liboctave.la 
../libcruft/libcruft.la   -lfftw3 -lfftw3f  -lhdf5  -lz -lfontconfig 
-lftgl -lfreetype -lz -lopengl32 -lglu32   -lreadline -lncurses -lglob 
-llapack -lblas -liberty -lm  -lgdi32 -lws2_32 -luser32 -lkernel32 
-lgfortran -liberty -lm  -lgdi32 -lws2_32 -luser32 -lkernel32
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
shared libraries
libtool: link: rm -fr  .libs/liboctinterp.dll.a

*** Warning: linker path does not have real file for library -liberty.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libiberty and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libiberty.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
libtool: link: mingw32-g++-4.4.0-dw2 -shared-libgcc -shared -nostdlib 
d:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/../../../dllcrt2.o 
d:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/crtbegin.o 
  .libs/Cell.o .libs/bitfcns.o .libs/c-file-ptr-stream.o 
.libs/comment-list.o .libs/cutils.o .libs/data.o .libs/debug.o 
.libs/defaults.o .libs/defun.o .libs/dirfns.o .libs/display.o 
.libs/dynamic-ld.o .libs/error.o .libs/file-io.o .libs/gl-render.o 
.libs/graphics.o .libs/gripes.o .libs/help.o .libs/input.o .libs/lex.o 
.libs/load-path.o .libs/load-save.o .libs/ls-ascii-helper.o 
.libs/ls-hdf5.o .libs/ls-mat-ascii.o .libs/ls-mat4.o .libs/ls-mat5.o 
.libs/ls-oct-ascii.o .libs/ls-oct-binary.o .libs/ls-utils.o 
.libs/mappers.o .libs/matherr.o .libs/mex.o .libs/oct-fstrm.o 
.libs/oct-hist.o .libs/oct-iostrm.o .libs/oct-lvalue.o .libs/oct-map.o 
.libs/oct-obj.o .libs/oct-parse.o .libs/oct-prcstrm.o 
.libs/oct-procbuf.o .libs/oct-stream.o .libs/oct-strstrm.o 
.libs/octave.o .libs/pager.o .libs/pr-output.o .libs/procstream.o 
.libs/sighandlers.o .libs/siglist.o .libs/sparse-xdiv.o 
.libs/sparse-xpow.o .libs/strfns.o .libs/symtab.o .libs/syscalls.o 
.libs/sysdep.o .libs/token.o .libs/toplev.o .libs/txt-eng-ft.o 
.libs/unwind-prot.o .libs/utils.o .libs/variables.o .libs/xdiv.o 
.libs/xnorm.o .libs/xpow.o .libs/zfstream.o .libs/ov-base.o 
.libs/ov-bool-mat.o .libs/ov-bool.o .libs/ov-builtin.o .libs/ov-cell.o 
.libs/ov-ch-mat.o .libs/ov-class.o .libs/ov-colon.o .libs/ov-complex.o 
.libs/ov-cs-list.o .libs/ov-cx-diag.o .libs/ov-cx-mat.o 
.libs/ov-dld-fcn.o .libs/ov-fcn-handle.o .libs/ov-fcn-inline.o 
.libs/ov-fcn.o .libs/ov-float.o .libs/ov-flt-complex.o 
.libs/ov-flt-cx-diag.o .libs/ov-flt-cx-mat.o .libs/ov-flt-re-diag.o 
.libs/ov-flt-re-mat.o .libs/ov-list.o .libs/ov-mex-fcn.o 
.libs/ov-null-mat.o .libs/ov-perm.o .libs/ov-range.o .libs/ov-re-diag.o 
.libs/ov-re-mat.o .libs/ov-scalar.o .libs/ov-str-mat.o .libs/ov-struct.o 
.libs/ov-typeinfo.o .libs/ov-usr-fcn.o .libs/ov.o .libs/ov-int16.o 
.libs/ov-int32.o .libs/ov-int64.o .libs/ov-int8.o .libs/ov-uint16.o 
.libs/ov-uint32.o .libs/ov-uint64.o .libs/ov-uint8.o 
.libs/ov-base-sparse.o .libs/ov-bool-sparse.o .libs/ov-cx-sparse.o 
.libs/ov-re-sparse.o .libs/pt-arg-list.o .libs/pt-assign.o 
.libs/pt-binop.o .libs/pt-bp.o .libs/pt-cbinop.o .libs/pt-cell.o 
.libs/pt-check.o .libs/pt-cmd.o .libs/pt-colon.o .libs/pt-const.o 
.libs/pt-decl.o .libs/pt-eval.o .libs/pt-except.o .libs/pt-exp.o 
.libs/pt-fcn-handle.o .libs/pt-id.o .libs/pt-idx.o .libs/pt-jump.o 
.libs/pt-loop.o .libs/pt-mat.o .libs/pt-misc.o .libs/pt-pr-code.o 
.libs/pt-select.o .libs/pt-stmt.o .libs/pt-unop.o .libs/pt.o 
OPERATORS/.libs/op-b-b.o OPERATORS/.libs/op-b-bm.o 
OPERATORS/.libs/op-b-sbm.o OPERATORS/.libs/op-bm-b.o 
OPERATORS/.libs/op-bm-bm.o OPERATORS/.libs/op-bm-sbm.o 
OPERATORS/.libs/op-cdm-cdm.o OPERATORS/.libs/op-cdm-cm.o 
OPERATORS/.libs/op-cdm-cs.o OPERATORS/.libs/op-cdm-dm.o 
OPERATORS/.libs/op-cdm-m.o OPERATORS/.libs/op-cdm-s.o 
OPERATORS/.libs/op-cell.o OPERATORS/.libs/op-chm.o 
OPERATORS/.libs/op-class.o OPERATORS/.libs/op-cm-cdm.o 
OPERATORS/.libs/op-cm-cm.o OPERATORS/.libs/op-cm-cs.o 
OPERATORS/.libs/op-cm-dm.o OPERATORS/.libs/op-cm-m.o 
OPERATORS/.libs/op-cm-pm.o OPERATORS/.libs/op-cm-s.o 
OPERATORS/.libs/op-cm-scm.o OPERATORS/.libs/op-cm-sm.o 
OPERATORS/.libs/op-cs-cm.o OPERATORS/.libs/op-cs-cs.o 
OPERATORS/.libs/op-cs-m.o OPERATORS/.libs/op-cs-s.o 
OPERATORS/.libs/op-cs-scm.o OPERATORS/.libs/op-cs-sm.o 
OPERATORS/.libs/op-dm-cdm.o OPERATORS/.libs/op-dm-cm.o 
OPERATORS/.libs/op-dm-cs.o OPERATORS/.libs/op-dm-dm.o 
OPERATORS/.libs/op-dm-m.o OPERATORS/.libs/op-dm-s.o 
OPERATORS/.libs/op-dm-scm.o OPERATORS/.libs/op-dm-sm.o 
OPERATORS/.libs/op-double-conv.o OPERATORS/.libs/op-fcdm-fcdm.o 
OPERATORS/.libs/op-fcdm-fcm.o OPERATORS/.libs/op-fcdm-fcs.o 
OPERATORS/.libs/op-fcdm-fdm.o OPERATORS/.libs/op-fcdm-fm.o 
OPERATORS/.libs/op-fcdm-fs.o OPERATORS/.libs/op-fcm-fcdm.o 
OPERATORS/.libs/op-fcm-fcm.o OPERATORS/.libs/op-fcm-fcs.o 
OPERATORS/.libs/op-fcm-fdm.o OPERATORS/.libs/op-fcm-fm.o 
OPERATORS/.libs/op-fcm-fs.o OPERATORS/.libs/op-fcm-pm.o 
OPERATORS/.libs/op-fcs-fcm.o OPERATORS/.libs/op-fcs-fcs.o 
OPERATORS/.libs/op-fcs-fm.o OPERATORS/.libs/op-fcs-fs.o 
OPERATORS/.libs/op-fdm-fcdm.o OPERATORS/.libs/op-fdm-fcm.o 
OPERATORS/.libs/op-fdm-fcs.o OPERATORS/.libs/op-fdm-fdm.o 
OPERATORS/.libs/op-fdm-fm.o OPERATORS/.libs/op-fdm-fs.o 
OPERATORS/.libs/op-float-conv.o OPERATORS/.libs/op-fm-fcdm.o 
OPERATORS/.libs/op-fm-fcm.o OPERATORS/.libs/op-fm-fcs.o 
OPERATORS/.libs/op-fm-fdm.o OPERATORS/.libs/op-fm-fm.o 
OPERATORS/.libs/op-fm-fs.o OPERATORS/.libs/op-fm-pm.o 
OPERATORS/.libs/op-fs-fcm.o OPERATORS/.libs/op-fs-fcs.o 
OPERATORS/.libs/op-fs-fm.o OPERATORS/.libs/op-fs-fs.o 
OPERATORS/.libs/op-i16-i16.o OPERATORS/.libs/op-i32-i32.o 
OPERATORS/.libs/op-i64-i64.o OPERATORS/.libs/op-i8-i8.o 
OPERATORS/.libs/op-int-concat.o OPERATORS/.libs/op-int-conv.o 
OPERATORS/.libs/op-list.o OPERATORS/.libs/op-m-cdm.o 
OPERATORS/.libs/op-m-cm.o OPERATORS/.libs/op-m-cs.o 
OPERATORS/.libs/op-m-dm.o OPERATORS/.libs/op-m-m.o 
OPERATORS/.libs/op-m-pm.o OPERATORS/.libs/op-m-s.o 
OPERATORS/.libs/op-m-scm.o OPERATORS/.libs/op-m-sm.o 
OPERATORS/.libs/op-pm-cm.o OPERATORS/.libs/op-pm-fcm.o 
OPERATORS/.libs/op-pm-fm.o OPERATORS/.libs/op-pm-m.o 
OPERATORS/.libs/op-pm-pm.o OPERATORS/.libs/op-pm-scm.o 
OPERATORS/.libs/op-pm-sm.o OPERATORS/.libs/op-range.o 
OPERATORS/.libs/op-s-cm.o OPERATORS/.libs/op-s-cs.o 
OPERATORS/.libs/op-s-m.o OPERATORS/.libs/op-s-s.o 
OPERATORS/.libs/op-s-scm.o OPERATORS/.libs/op-s-sm.o 
OPERATORS/.libs/op-sbm-b.o OPERATORS/.libs/op-sbm-bm.o 
OPERATORS/.libs/op-sbm-sbm.o OPERATORS/.libs/op-scm-cm.o 
OPERATORS/.libs/op-scm-cs.o OPERATORS/.libs/op-scm-m.o 
OPERATORS/.libs/op-scm-s.o OPERATORS/.libs/op-scm-scm.o 
OPERATORS/.libs/op-scm-sm.o OPERATORS/.libs/op-sm-cm.o 
OPERATORS/.libs/op-sm-cs.o OPERATORS/.libs/op-sm-m.o 
OPERATORS/.libs/op-sm-s.o OPERATORS/.libs/op-sm-scm.o 
OPERATORS/.libs/op-sm-sm.o OPERATORS/.libs/op-str-m.o 
OPERATORS/.libs/op-str-s.o OPERATORS/.libs/op-str-str.o 
OPERATORS/.libs/op-struct.o OPERATORS/.libs/op-ui16-ui16.o 
OPERATORS/.libs/op-ui32-ui32.o OPERATORS/.libs/op-ui64-ui64.o 
OPERATORS/.libs/op-ui8-ui8.o TEMPLATE-INST/.libs/Array-os.o 
TEMPLATE-INST/.libs/Array-tc.o .libs/builtins.o .libs/oct-errno.o 
.libs/ops.o .libs/DASPK-opts.o .libs/DASRT-opts.o .libs/DASSL-opts.o 
.libs/LSODE-opts.o .libs/Quad-opts.o 
-L/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft/.libs 
../liboctave/.libs/liboctave.dll.a 
-L/usr/local/octmgw32_gcc-4.4.0-dw2/lib 
/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft/.libs/libcruft.dll.a 
-lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -larpack 
-lqrupdate -lregex -lpcre -lpthread ../libcruft/.libs/libcruft.dll.a 
-lfftw3 -lfftw3f -lhdf5 -lfontconfig -lftgl -lfreetype -lz -lopengl32 
-lglu32 -lreadline -lncurses -lglob -llapack -lblas -luser32 -lkernel32 
-lgfortran -lgdi32 -lws2_32 -luser32 -lkernel32 
-Ld:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0 
-Ld:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc 
-LD:/build/octave32/tip_gcc-4.4.0/msys-1.0.11/local/octmgw32_gcc-4.4.0-dw2/lib 
-Ld:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/lib 
-Ld:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/../../.. 
-lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 
-lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt 
d:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/crtend.o 
  -march=i686 -mtune=generic -mieee-fp -march=i686 -mtune=generic 
-march=i686 -mtune=generic -Wl,--allow-multiple-definition   -o 
.libs/octinterp.dll -Wl,--enable-auto-image-base -Xlinker --out-implib 
-Xlinker .libs/liboctinterp.dll.a
Info: resolving vtable for idx_vector::idx_vector_rep by linking to 
__imp___ZTVN10idx_vector14idx_vector_repE (auto-import)
Info: resolving idx_vector::idx_range_rep::allocator       by linking to 
__imp___ZN10idx_vector13idx_range_rep9allocatorE (auto-import)
Info: resolving idx_vector::idx_colon_rep::allocator       by linking to 
__imp___ZN10idx_vector13idx_colon_rep9allocatorE (auto-import)
Info: resolving _octave_signal_caught by linking to 
__imp__octave_signal_caught (auto-import)
Info: resolving _octave_Inf by linking to __imp__octave_Inf (auto-import)
Info: resolving dir_path::static_members::instance      by linking to 
__imp___ZN8dir_path14static_members8instanceE (auto-import)
Info: resolving file_ops::static_members::instance      by linking to 
__imp___ZN8file_ops14static_members8instanceE (auto-import)
Info: resolving _octave_NaN by linking to __imp__octave_NaN (auto-import)
Info: resolving _current_liboctave_error_handler by linking to 
__imp__current_liboctave_error_handler (auto-import)
Info: resolving _octave_interrupt_immediately by linking to 
__imp__octave_interrupt_immediately (auto-import)
Info: resolving _octave_exception_state by linking to 
__imp__octave_exception_state (auto-import)
Info: resolving _H5T_NATIVE_UCHAR_g by linking to 
__imp__H5T_NATIVE_UCHAR_g (auto-import)
Info: resolving _H5T_NATIVE_INT_g by linking to __imp__H5T_NATIVE_INT_g 
(auto-import)
Info: resolving _H5T_C_S1_g by linking to __imp__H5T_C_S1_g (auto-import)
Info: resolving _H5T_NATIVE_DOUBLE_g by linking to 
__imp__H5T_NATIVE_DOUBLE_g (auto-import)
Info: resolving _octave_NA by linking to __imp__octave_NA (auto-import)
Info: resolving _octave_signal_hook by linking to 
__imp__octave_signal_hook (auto-import)
Info: resolving _octave_interrupt_hook by linking to 
__imp__octave_interrupt_hook (auto-import)
Info: resolving _octave_bad_alloc_hook by linking to 
__imp__octave_bad_alloc_hook (auto-import)
Info: resolving idx_vector::idx_scalar_rep::allocator       by linking 
to __imp___ZN10idx_vector14idx_scalar_rep9allocatorE (auto-import)
Info: resolving _octave_interrupt_state by linking to 
__imp__octave_interrupt_state (auto-import)
Info: resolving _current_context by linking to __imp__current_context 
(auto-import)
Info: resolving idx_vector::idx_vector_rep::allocator       by linking 
to __imp___ZN10idx_vector14idx_vector_rep9allocatorE (auto-import)
Info: resolving _H5T_NATIVE_HBOOL_g by linking to 
__imp__H5T_NATIVE_HBOOL_g (auto-import)
Info: resolving _H5T_NATIVE_FLOAT_g by linking to 
__imp__H5T_NATIVE_FLOAT_g (auto-import)
Info: resolving _H5T_NATIVE_SCHAR_g by linking to 
__imp__H5T_NATIVE_SCHAR_g (auto-import)
Info: resolving _octave_Float_Inf by linking to __imp__octave_Float_Inf 
(auto-import)
Info: resolving _H5T_NATIVE_INT16_g by linking to 
__imp__H5T_NATIVE_INT16_g (auto-import)
Info: resolving _H5T_NATIVE_INT32_g by linking to 
__imp__H5T_NATIVE_INT32_g (auto-import)
Info: resolving _H5T_NATIVE_INT64_g by linking to 
__imp__H5T_NATIVE_INT64_g (auto-import)
Info: resolving _H5T_NATIVE_INT8_g by linking to 
__imp__H5T_NATIVE_INT8_g (auto-import)
Info: resolving _H5T_NATIVE_UINT16_g by linking to 
__imp__H5T_NATIVE_UINT16_g (auto-import)
Info: resolving _H5T_NATIVE_UINT32_g by linking to 
__imp__H5T_NATIVE_UINT32_g (auto-import)
Info: resolving _H5T_NATIVE_UINT64_g by linking to 
__imp__H5T_NATIVE_UINT64_g (auto-import)
Info: resolving _H5T_NATIVE_UINT8_g by linking to 
__imp__H5T_NATIVE_UINT8_g (auto-import)
Info: resolving idx_vector::colon       by linking to 
__imp___ZN10idx_vector5colonE (auto-import)
Creating library file: 
.libs/liboctinterp.dll.ad:/build/octave32/tip_gcc-4.4.0/gcc-mingw-4.4.0/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: 
warning: auto-importing has been activated without --enable-auto-import 
specified on the command line.
This should work unless it involves constant data structures referencing 
symbols from auto-imported DLLs.
.libs/file-io.o:file-io.cc:(.text+0x7eb0): undefined reference to `mkstemps
'
collect2: ld returned 1 exit status
make[3]: *** [liboctinterp.la] Error 1
make[3]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2'
make: *** [all] Error 2


And this is the point libtool is getting me really annoyed, because it 
simply totally screws up.
Compare the libtool command executed from the makefile with the 
--verbose output of the actual link command libtool executes.
You'll notice that -liberty is correctly listed among the libraries in 
the first command, since the makefile reads

LIBS = -liberty -lm  -lgdi32 -lws2_32 -luser32 -lkernel32

however, the actual link command libtool spawns does not contain 
-liberty and - hello! - the link command fails with an undefined 
reference to a function defined in -liberty. What the?

That's exactly what libtool is all about. Thinking to know better than 
the user and by that messing it up.

Are you really sure that octave must use libtool? It simply doesn't work 
for windows.

It'll end up that one patches the makefiles and adds explicit link 
commands to create the shared libraries - like for all dependency libs 
where libtool messes around. Great.

benjamin

From lindnerben at gmx.net  Sat Oct 31 11:40:41 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sat, 31 Oct 2009 17:40:41 +0100
Subject: gnulib and automake
In-Reply-To: <19180.23890.807202.518048@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<4AEB36F9.9070404@gmx.net>	<19179.15601.907503.686285@segfault.lan>	<4AEB46EE.8030400@gmx.net>	<19179.21624.130899.537300@segfault.lan>	<4AEB58DA.9070805@gmx.net>	<19179.26026.448430.104714@segfault.lan>	<4AEC1A96.4020108@gmx.net>
	<19180.23890.807202.518048@segfault.lan>
Message-ID: <4AEC6889.3010906@gmx.net>

John W. Eaton wrote:
> On 31-Oct-2009, Benjamin Lindner wrote:
> 
> | > In any case, I don't plan to reverse the decision to use libtool and
> | > automake, because I want to be able to use functions from gnulib, and
> | > as far as I can tell, that is just not practical without automake and
> | > libtool.
> | 
> | Yes, I feared you'd say that. I see that I am on a lone post against 
> | libtool.
> | Well, it's your decision. I'll respect it.
> | 
> | > I can try to help you debug the problems, but you will have to send
> | > more information about exactly what is happening.  Or, I need to know
> | > how to duplicate the build environment you have, then I can try to
> | > find a Windows system that I can use to debug the configuration
> | > problems.
> | 
> |  From what I saw until now, if I patch libtool as above and we get the 
> | dependency libraries for libcruft (possibly also for liboctave and 
> | liboctinterp?) right, then it should work.
> | I'm curious how the .oct creation will behave.
> 
> Instead of the changes you have made, can we back up and start by
> changing the LT_INIT call in configue.ac to be
> 
>   LT_INIT([disable-static win32-dll])
> 

certainly,

I cloned a fresh repository from current tip,
applied your automake patch, and applied the following diff:

diff -r 5382a2ab87e7 configure.ac
--- a/configure.ac	Fri Oct 30 11:10:14 2009 -0400
+++ b/configure.ac	Sat Oct 31 17:28:52 2009 +0100
@@ -886,7 +886,7 @@
  OCTAVE_PROG_AR

  LT_PREREQ([2.2.2])
-LT_INIT([disable-static])
+LT_INIT([disable-static win32-dll])

  XTRA_CRUFT_SH_LDFLAGS=
  case "$canonical_host_type" in
diff -r 5382a2ab87e7 libcruft/Makefile.am
--- a/libcruft/Makefile.am	Fri Oct 30 11:10:14 2009 -0400
+++ b/libcruft/Makefile.am	Sat Oct 31 17:28:52 2009 +0100
@@ -31,6 +31,8 @@

  libcruft_la_LDFLAGS = -release $(version)

+libcruft_la_LIBADD = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
+
  octinclude_HEADERS =

  EXTRA_DIST = ChangeLog STOP.patch mkf77def.in
diff -r 5382a2ab87e7 liboctave/Makefile.am
--- a/liboctave/Makefile.am	Fri Oct 30 11:10:14 2009 -0400
+++ b/liboctave/Makefile.am	Sat Oct 31 17:28:52 2009 +0100
@@ -494,10 +494,10 @@
  LINK_DEPS = \
    $(RLD_FLAG) \
    ../libcruft/libcruft.la \
-  $(SPARSE_LDFLAGS) $(SPARSE_LIBS) \
+  $(SPARSE_LDFLAGS) $(SPARSE_XLIBS) \
    $(ARPACK_LIBS) \
    $(QRUPDATE_LIBS) \
-  $(FFTW_LDFLAGS) $(FFTW_LIBS) \
+  $(FFTW_LDFLAGS) $(FFTW_XLIBS) \
    $(LAPACK_LIBS) $(BLAS_LIBS) \
    $(READLINE_LIBS) $(TERM_LIBS) \
    $(LIBGLOB) $(REGEX_LIBS) $(DL_LIBS) \

then did a ./autoconf.sh followed by a call to configure, without any 
"--enable" options.
I then replaced all libtool flags "--silent" by "--verbose".
Then "make" runs until libcruft is built, and again, no shared library 
is created.
The output is:

/bin/sh ../libtool --tag=CXX --verbose  --mode=link 
mingw32-g++-4.4.0-dw2 -shared-libgcc -march=i686 -mtune=generic -O3 
-Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W -Wshadow -Wold-style-cast 
-Wformat -march=i686 -mtune=generic -O3 -Wall  -march=i686 
-mtune=generic -O3 -Wall -release 3.3.50+ -shared-libgcc 
-Wl,--allow-multiple-definition -o libcruft.la -rpath 
/usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
amos/cacai.lo amos/cacon.lo amos/cbesh.lo amos/cbesi.lo amos/cbesj.lo 
amos/cbesk.lo amos/cbesy.lo amos/cbinu.lo amos/cbuni.lo amos/cbunk.lo 
amos/cunk1.lo amos/cunk2.lo amos/crati.lo amos/cshch.lo amos/cuni1.lo 
amos/cuoik.lo amos/cairy.lo amos/cbiry.lo amos/ckscl.lo amos/cs1s2.lo 
amos/cuchk.lo amos/cuni2.lo amos/cwrsk.lo amos/casyi.lo amos/cbknu.lo 
amos/cmlri.lo amos/cseri.lo amos/cunhj.lo amos/cunik.lo amos/dgamln.lo 
amos/gamln.lo amos/xzabs.lo amos/xzexp.lo amos/xzlog.lo amos/xzsqrt.lo 
amos/zacai.lo amos/zacon.lo amos/zairy.lo amos/zasyi.lo amos/zbesh.lo 
amos/zbesi.lo amos/zbesj.lo amos/zbesk.lo amos/zbesy.lo amos/zbinu.lo 
amos/zbiry.lo amos/zbknu.lo amos/zbuni.lo amos/zbunk.lo amos/zdiv.lo 
amos/zkscl.lo amos/zmlri.lo amos/zmlt.lo amos/zrati.lo amos/zs1s2.lo 
amos/zseri.lo amos/zshch.lo amos/zuchk.lo amos/zunhj.lo amos/zuni1.lo 
amos/zuni2.lo amos/zunik.lo amos/zunk1.lo amos/zunk2.lo amos/zuoik.lo 
amos/zwrsk.lo  blas-xtra/xddot.lo blas-xtra/xdnrm2.lo 
blas-xtra/xdznrm2.lo blas-xtra/xzdotc.lo blas-xtra/xzdotu.lo 
blas-xtra/xsdot.lo blas-xtra/xsnrm2.lo blas-xtra/xscnrm2.lo 
blas-xtra/xcdotc.lo blas-xtra/xcdotu.lo blas-xtra/xerbla.lo 
daspk/datv.lo daspk/dcnst0.lo daspk/dcnstr.lo daspk/ddasic.lo 
daspk/ddasid.lo daspk/ddasik.lo daspk/ddaspk.lo daspk/ddstp.lo 
daspk/ddwnrm.lo daspk/dfnrmd.lo daspk/dfnrmk.lo daspk/dhels.lo 
daspk/dheqr.lo daspk/dinvwt.lo daspk/dlinsd.lo daspk/dlinsk.lo 
daspk/dmatd.lo daspk/dnedd.lo daspk/dnedk.lo daspk/dnsd.lo 
daspk/dnsid.lo daspk/dnsik.lo daspk/dnsk.lo daspk/dorth.lo 
daspk/dslvd.lo daspk/dslvk.lo daspk/dspigm.lo daspk/dyypnw.lo 
dasrt/ddasrt.lo dasrt/drchek.lo dasrt/droots.lo dassl/ddaini.lo 
dassl/ddajac.lo dassl/ddanrm.lo dassl/ddaslv.lo dassl/ddassl.lo 
dassl/ddastp.lo dassl/ddatrp.lo dassl/ddawts.lo   lapack-xtra/xclange.lo 
lapack-xtra/xdlamch.lo lapack-xtra/xdlange.lo lapack-xtra/xilaenv.lo 
lapack-xtra/xslamch.lo lapack-xtra/xslange.lo lapack-xtra/xzlange.lo 
misc/cquit.lo misc/d1mach.lo misc/f77-extern.lo misc/f77-fcn.lo 
misc/i1mach.lo misc/lo-error.lo misc/quit.lo misc/r1mach.lo 
odepack/cfode.lo odepack/dlsode.lo odepack/ewset.lo odepack/intdy.lo 
odepack/prepj.lo odepack/solsy.lo odepack/stode.lo odepack/vnorm.lo 
odepack/scfode.lo odepack/sewset.lo odepack/sintdy.lo odepack/slsode.lo 
odepack/sprepj.lo odepack/ssolsy.lo odepack/sstode.lo odepack/svnorm.lo 
ordered-qz/dsubsp.lo ordered-qz/exchqz.lo ordered-qz/ssubsp.lo 
ordered-qz/sexchqz.lo quadpack/dqagi.lo quadpack/dqagie.lo 
quadpack/dqagp.lo quadpack/dqagpe.lo quadpack/dqelg.lo 
quadpack/dqk15i.lo quadpack/dqk21.lo quadpack/dqpsrt.lo 
quadpack/qagie.lo quadpack/qagi.lo quadpack/qagpe.lo quadpack/qagp.lo 
quadpack/qelg.lo quadpack/qk15i.lo quadpack/qk21.lo quadpack/qpsrt.lo 
quadpack/xerror.lo ranlib/advnst.lo ranlib/genbet.lo ranlib/genchi.lo 
ranlib/genexp.lo ranlib/genf.lo ranlib/gengam.lo ranlib/genmn.lo 
ranlib/genmul.lo ranlib/gennch.lo ranlib/gennf.lo ranlib/gennor.lo 
ranlib/genprm.lo ranlib/genunf.lo ranlib/getcgn.lo ranlib/getsd.lo 
ranlib/ignbin.lo ranlib/ignlgi.lo ranlib/ignnbn.lo ranlib/ignpoi.lo 
ranlib/ignuin.lo ranlib/initgn.lo ranlib/inrgcm.lo ranlib/lennob.lo 
ranlib/mltmod.lo ranlib/phrtsd.lo ranlib/qrgnin.lo ranlib/ranf.lo 
ranlib/setall.lo ranlib/setant.lo ranlib/setgmn.lo ranlib/setsd.lo 
ranlib/sexpo.lo ranlib/sgamma.lo ranlib/snorm.lo ranlib/wrap.lo 
slatec-err/fdump.lo slatec-err/ixsav.lo slatec-err/j4save.lo 
slatec-err/xerclr.lo slatec-err/xercnt.lo slatec-err/xerhlt.lo 
slatec-err/xermsg.lo slatec-err/xerprn.lo slatec-err/xerrwd.lo 
slatec-err/xersve.lo slatec-err/xgetf.lo slatec-err/xgetua.lo 
slatec-err/xsetf.lo slatec-err/xsetua.lo slatec-fn/albeta.lo 
slatec-fn/alngam.lo slatec-fn/alnrel.lo slatec-fn/algams.lo 
slatec-fn/acosh.lo slatec-fn/asinh.lo slatec-fn/atanh.lo 
slatec-fn/betai.lo slatec-fn/csevl.lo slatec-fn/d9gmit.lo 
slatec-fn/d9lgic.lo slatec-fn/d9lgit.lo slatec-fn/d9lgmc.lo 
slatec-fn/dacosh.lo slatec-fn/dasinh.lo slatec-fn/datanh.lo 
slatec-fn/dbetai.lo slatec-fn/dcsevl.lo slatec-fn/derf.lo 
slatec-fn/derfc.lo slatec-fn/dgami.lo slatec-fn/dgamit.lo 
slatec-fn/dgamlm.lo slatec-fn/dgamma.lo slatec-fn/dgamr.lo 
slatec-fn/dlbeta.lo slatec-fn/dlgams.lo slatec-fn/dlngam.lo 
slatec-fn/dlnrel.lo slatec-fn/dpchim.lo slatec-fn/dpchst.lo 
slatec-fn/erf.lo slatec-fn/erfc.lo slatec-fn/gami.lo slatec-fn/gamit.lo 
slatec-fn/gamlim.lo slatec-fn/gamma.lo slatec-fn/gamr.lo 
slatec-fn/initds.lo slatec-fn/inits.lo slatec-fn/pchim.lo 
slatec-fn/pchst.lo slatec-fn/r9lgmc.lo slatec-fn/r9lgit.lo 
slatec-fn/r9gmit.lo slatec-fn/r9lgic.lo slatec-fn/xdacosh.lo 
slatec-fn/xdasinh.lo slatec-fn/xdatanh.lo slatec-fn/xdbetai.lo 
slatec-fn/xderf.lo slatec-fn/xderfc.lo slatec-fn/xdgami.lo 
slatec-fn/xdgamit.lo slatec-fn/xdgamma.lo slatec-fn/xgmainc.lo 
slatec-fn/xacosh.lo slatec-fn/xasinh.lo slatec-fn/xatanh.lo 
slatec-fn/xerf.lo slatec-fn/xerfc.lo slatec-fn/xsgmainc.lo 
slatec-fn/xgamma.lo slatec-fn/xbetai.lo villad/dfopr.lo villad/dif.lo 
villad/intrp.lo villad/jcobi.lo villad/radau.lo villad/vilerr.lo 
-llapack -lblas -lgfortran -liberty -lm  -lgdi32 -lws2_32 -luser32 
-lkernel32
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
shared libraries
libtool: link: ar cru .libs/libcruft.a  amos/.libs/cacai.o 
amos/.libs/cacon.o amos/.libs/cbesh.o amos/.libs/cbesi.o 
amos/.libs/cbesj.o amos/.libs/cbesk.o amos/.libs/cbesy.o 
amos/.libs/cbinu.o amos/.libs/cbuni.o amos/.libs/cbunk.o 
amos/.libs/cunk1.o amos/.libs/cunk2.o amos/.libs/crati.o 
amos/.libs/cshch.o amos/.libs/cuni1.o amos/.libs/cuoik.o 
amos/.libs/cairy.o amos/.libs/cbiry.o amos/.libs/ckscl.o 
amos/.libs/cs1s2.o amos/.libs/cuchk.o amos/.libs/cuni2.o 
amos/.libs/cwrsk.o amos/.libs/casyi.o amos/.libs/cbknu.o 
amos/.libs/cmlri.o amos/.libs/cseri.o amos/.libs/cunhj.o 
amos/.libs/cunik.o amos/.libs/dgamln.o amos/.libs/gamln.o 
amos/.libs/xzabs.o amos/.libs/xzexp.o amos/.libs/xzlog.o 
amos/.libs/xzsqrt.o amos/.libs/zacai.o amos/.libs/zacon.o 
amos/.libs/zairy.o amos/.libs/zasyi.o amos/.libs/zbesh.o 
amos/.libs/zbesi.o amos/.libs/zbesj.o amos/.libs/zbesk.o 
amos/.libs/zbesy.o amos/.libs/zbinu.o amos/.libs/zbiry.o 
amos/.libs/zbknu.o amos/.libs/zbuni.o amos/.libs/zbunk.o 
amos/.libs/zdiv.o amos/.libs/zkscl.o amos/.libs/zmlri.o 
amos/.libs/zmlt.o amos/.libs/zrati.o amos/.libs/zs1s2.o 
amos/.libs/zseri.o amos/.libs/zshch.o amos/.libs/zuchk.o 
amos/.libs/zunhj.o amos/.libs/zuni1.o amos/.libs/zuni2.o 
amos/.libs/zunik.o amos/.libs/zunk1.o amos/.libs/zunk2.o 
amos/.libs/zuoik.o amos/.libs/zwrsk.o blas-xtra/.libs/xddot.o 
blas-xtra/.libs/xdnrm2.o blas-xtra/.libs/xdznrm2.o 
blas-xtra/.libs/xzdotc.o blas-xtra/.libs/xzdotu.o 
blas-xtra/.libs/xsdot.o blas-xtra/.libs/xsnrm2.o 
blas-xtra/.libs/xscnrm2.o blas-xtra/.libs/xcdotc.o 
blas-xtra/.libs/xcdotu.o blas-xtra/.libs/xerbla.o daspk/.libs/datv.o 
daspk/.libs/dcnst0.o daspk/.libs/dcnstr.o daspk/.libs/ddasic.o 
daspk/.libs/ddasid.o daspk/.libs/ddasik.o daspk/.libs/ddaspk.o 
daspk/.libs/ddstp.o daspk/.libs/ddwnrm.o daspk/.libs/dfnrmd.o 
daspk/.libs/dfnrmk.o daspk/.libs/dhels.o daspk/.libs/dheqr.o 
daspk/.libs/dinvwt.o daspk/.libs/dlinsd.o daspk/.libs/dlinsk.o 
daspk/.libs/dmatd.o daspk/.libs/dnedd.o daspk/.libs/dnedk.o 
daspk/.libs/dnsd.o daspk/.libs/dnsid.o daspk/.libs/dnsik.o 
daspk/.libs/dnsk.o daspk/.libs/dorth.o daspk/.libs/dslvd.o 
daspk/.libs/dslvk.o daspk/.libs/dspigm.o daspk/.libs/dyypnw.o 
dasrt/.libs/ddasrt.o dasrt/.libs/drchek.o dasrt/.libs/droots.o 
dassl/.libs/ddaini.o dassl/.libs/ddajac.o dassl/.libs/ddanrm.o 
dassl/.libs/ddaslv.o dassl/.libs/ddassl.o dassl/.libs/ddastp.o 
dassl/.libs/ddatrp.o dassl/.libs/ddawts.o lapack-xtra/.libs/xclange.o 
lapack-xtra/.libs/xdlamch.o lapack-xtra/.libs/xdlange.o 
lapack-xtra/.libs/xilaenv.o lapack-xtra/.libs/xslamch.o 
lapack-xtra/.libs/xslange.o lapack-xtra/.libs/xzlange.o 
misc/.libs/cquit.o misc/.libs/d1mach.o misc/.libs/f77-extern.o 
misc/.libs/f77-fcn.o misc/.libs/i1mach.o misc/.libs/lo-error.o 
misc/.libs/quit.o misc/.libs/r1mach.o odepack/.libs/cfode.o 
odepack/.libs/dlsode.o odepack/.libs/ewset.o odepack/.libs/intdy.o 
odepack/.libs/prepj.o odepack/.libs/solsy.o odepack/.libs/stode.o 
odepack/.libs/vnorm.o odepack/.libs/scfode.o odepack/.libs/sewset.o 
odepack/.libs/sintdy.o odepack/.libs/slsode.o odepack/.libs/sprepj.o 
odepack/.libs/ssolsy.o odepack/.libs/sstode.o odepack/.libs/svnorm.o 
ordered-qz/.libs/dsubsp.o ordered-qz/.libs/exchqz.o 
ordered-qz/.libs/ssubsp.o ordered-qz/.libs/sexchqz.o 
quadpack/.libs/dqagi.o quadpack/.libs/dqagie.o quadpack/.libs/dqagp.o 
quadpack/.libs/dqagpe.o quadpack/.libs/dqelg.o quadpack/.libs/dqk15i.o 
quadpack/.libs/dqk21.o quadpack/.libs/dqpsrt.o quadpack/.libs/qagie.o 
quadpack/.libs/qagi.o quadpack/.libs/qagpe.o quadpack/.libs/qagp.o 
quadpack/.libs/qelg.o quadpack/.libs/qk15i.o quadpack/.libs/qk21.o 
quadpack/.libs/qpsrt.o quadpack/.libs/xerror.o ranlib/.libs/advnst.o 
ranlib/.libs/genbet.o ranlib/.libs/genchi.o ranlib/.libs/genexp.o 
ranlib/.libs/genf.o ranlib/.libs/gengam.o ranlib/.libs/genmn.o 
ranlib/.libs/genmul.o ranlib/.libs/gennch.o ranlib/.libs/gennf.o 
ranlib/.libs/gennor.o ranlib/.libs/genprm.o ranlib/.libs/genunf.o 
ranlib/.libs/getcgn.o ranlib/.libs/getsd.o ranlib/.libs/ignbin.o 
ranlib/.libs/ignlgi.o ranlib/.libs/ignnbn.o ranlib/.libs/ignpoi.o 
ranlib/.libs/ignuin.o ranlib/.libs/initgn.o ranlib/.libs/inrgcm.o 
ranlib/.libs/lennob.o ranlib/.libs/mltmod.o ranlib/.libs/phrtsd.o 
ranlib/.libs/qrgnin.o ranlib/.libs/ranf.o ranlib/.libs/setall.o 
ranlib/.libs/setant.o ranlib/.libs/setgmn.o ranlib/.libs/setsd.o 
ranlib/.libs/sexpo.o ranlib/.libs/sgamma.o ranlib/.libs/snorm.o 
ranlib/.libs/wrap.o slatec-err/.libs/fdump.o slatec-err/.libs/ixsav.o 
slatec-err/.libs/j4save.o slatec-err/.libs/xerclr.o 
slatec-err/.libs/xercnt.o slatec-err/.libs/xerhlt.o 
slatec-err/.libs/xermsg.o slatec-err/.libs/xerprn.o 
slatec-err/.libs/xerrwd.o slatec-err/.libs/xersve.o 
slatec-err/.libs/xgetf.o slatec-err/.libs/xgetua.o 
slatec-err/.libs/xsetf.o slatec-err/.libs/xsetua.o 
slatec-fn/.libs/albeta.o slatec-fn/.libs/alngam.o 
slatec-fn/.libs/alnrel.o slatec-fn/.libs/algams.o 
slatec-fn/.libs/acosh.o slatec-fn/.libs/asinh.o slatec-fn/.libs/atanh.o 
slatec-fn/.libs/betai.o slatec-fn/.libs/csevl.o slatec-fn/.libs/d9gmit.o 
slatec-fn/.libs/d9lgic.o slatec-fn/.libs/d9lgit.o 
slatec-fn/.libs/d9lgmc.o slatec-fn/.libs/dacosh.o 
slatec-fn/.libs/dasinh.o slatec-fn/.libs/datanh.o 
slatec-fn/.libs/dbetai.o slatec-fn/.libs/dcsevl.o slatec-fn/.libs/derf.o 
slatec-fn/.libs/derfc.o slatec-fn/.libs/dgami.o slatec-fn/.libs/dgamit.o 
slatec-fn/.libs/dgamlm.o slatec-fn/.libs/dgamma.o 
slatec-fn/.libs/dgamr.o slatec-fn/.libs/dlbeta.o 
slatec-fn/.libs/dlgams.o slatec-fn/.libs/dlngam.o 
slatec-fn/.libs/dlnrel.o slatec-fn/.libs/dpchim.o 
slatec-fn/.libs/dpchst.o slatec-fn/.libs/erf.o slatec-fn/.libs/erfc.o 
slatec-fn/.libs/gami.o slatec-fn/.libs/gamit.o slatec-fn/.libs/gamlim.o 
slatec-fn/.libs/gamma.o slatec-fn/.libs/gamr.o slatec-fn/.libs/initds.o 
slatec-fn/.libs/inits.o slatec-fn/.libs/pchim.o slatec-fn/.libs/pchst.o 
slatec-fn/.libs/r9lgmc.o slatec-fn/.libs/r9lgit.o 
slatec-fn/.libs/r9gmit.o slatec-fn/.libs/r9lgic.o 
slatec-fn/.libs/xdacosh.o slatec-fn/.libs/xdasinh.o 
slatec-fn/.libs/xdatanh.o slatec-fn/.libs/xdbetai.o 
slatec-fn/.libs/xderf.o slatec-fn/.libs/xderfc.o 
slatec-fn/.libs/xdgami.o slatec-fn/.libs/xdgamit.o 
slatec-fn/.libs/xdgamma.o slatec-fn/.libs/xgmainc.o 
slatec-fn/.libs/xacosh.o slatec-fn/.libs/xasinh.o 
slatec-fn/.libs/xatanh.o slatec-fn/.libs/xerf.o slatec-fn/.libs/xerfc.o 
slatec-fn/.libs/xsgmainc.o slatec-fn/.libs/xgamma.o 
slatec-fn/.libs/xbetai.o villad/.libs/dfopr.o villad/.libs/dif.o 
villad/.libs/intrp.o villad/.libs/jcobi.o villad/.libs/radau.o 
villad/.libs/vilerr.o
libtool: link: ranlib .libs/libcruft.a
libtool: link: creating libcruft.la
libtool: link: ( cd ".libs" && rm -f "libcruft.la" && ln -s 
"../libcruft.la" "libcruft.la" )
make[2]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'


I tried again and added "-no-undefined" to libtool link command.
Doesn't help.

Making all in libcruft
make[2]: Entering directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'
/bin/sh ../libtool --tag=CXX --verbose  --mode=link 
mingw32-g++-4.4.0-dw2 -shared-libgcc -no-undefined -march=i686 
-mtune=generic -O3 -Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W 
-Wshadow -Wold-style-cast -Wformat -march=i686 -mtune=generic -O3 -Wall 
  -march=i686 -mtune=generic -O3 -Wall -release 3.3.50+ -shared-libgcc 
-Wl,--allow-multiple-definition -o libcruft.la -rpath 
/usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
amos/cacai.lo amos/cacon.lo amos/cbesh.lo amos/cbesi.lo amos/cbesj.lo 
amos/cbesk.lo amos/cbesy.lo amos/cbinu.lo amos/cbuni.lo amos/cbunk.lo 
amos/cunk1.lo amos/cunk2.lo amos/crati.lo amos/cshch.lo amos/cuni1.lo 
amos/cuoik.lo amos/cairy.lo amos/cbiry.lo amos/ckscl.lo amos/cs1s2.lo 
amos/cuchk.lo amos/cuni2.lo amos/cwrsk.lo amos/casyi.lo amos/cbknu.lo 
amos/cmlri.lo amos/cseri.lo amos/cunhj.lo amos/cunik.lo amos/dgamln.lo 
amos/gamln.lo amos/xzabs.lo amos/xzexp.lo amos/xzlog.lo amos/xzsqrt.lo 
amos/zacai.lo amos/zacon.lo amos/zairy.lo amos/zasyi.lo amos/zbesh.lo 
amos/zbesi.lo amos/zbesj.lo amos/zbesk.lo amos/zbesy.lo amos/zbinu.lo 
amos/zbiry.lo amos/zbknu.lo amos/zbuni.lo amos/zbunk.lo amos/zdiv.lo 
amos/zkscl.lo amos/zmlri.lo amos/zmlt.lo amos/zrati.lo amos/zs1s2.lo 
amos/zseri.lo amos/zshch.lo amos/zuchk.lo amos/zunhj.lo amos/zuni1.lo 
amos/zuni2.lo amos/zunik.lo amos/zunk1.lo amos/zunk2.lo amos/zuoik.lo 
amos/zwrsk.lo  blas-xtra/xddot.lo blas-xtra/xdnrm2.lo 
blas-xtra/xdznrm2.lo blas-xtra/xzdotc.lo blas-xtra/xzdotu.lo 
blas-xtra/xsdot.lo blas-xtra/xsnrm2.lo blas-xtra/xscnrm2.lo 
blas-xtra/xcdotc.lo blas-xtra/xcdotu.lo blas-xtra/xerbla.lo 
daspk/datv.lo daspk/dcnst0.lo daspk/dcnstr.lo daspk/ddasic.lo 
daspk/ddasid.lo daspk/ddasik.lo daspk/ddaspk.lo daspk/ddstp.lo 
daspk/ddwnrm.lo daspk/dfnrmd.lo daspk/dfnrmk.lo daspk/dhels.lo 
daspk/dheqr.lo daspk/dinvwt.lo daspk/dlinsd.lo daspk/dlinsk.lo 
daspk/dmatd.lo daspk/dnedd.lo daspk/dnedk.lo daspk/dnsd.lo 
daspk/dnsid.lo daspk/dnsik.lo daspk/dnsk.lo daspk/dorth.lo 
daspk/dslvd.lo daspk/dslvk.lo daspk/dspigm.lo daspk/dyypnw.lo 
dasrt/ddasrt.lo dasrt/drchek.lo dasrt/droots.lo dassl/ddaini.lo 
dassl/ddajac.lo dassl/ddanrm.lo dassl/ddaslv.lo dassl/ddassl.lo 
dassl/ddastp.lo dassl/ddatrp.lo dassl/ddawts.lo   lapack-xtra/xclange.lo 
lapack-xtra/xdlamch.lo lapack-xtra/xdlange.lo lapack-xtra/xilaenv.lo 
lapack-xtra/xslamch.lo lapack-xtra/xslange.lo lapack-xtra/xzlange.lo 
misc/cquit.lo misc/d1mach.lo misc/f77-extern.lo misc/f77-fcn.lo 
misc/i1mach.lo misc/lo-error.lo misc/quit.lo misc/r1mach.lo 
odepack/cfode.lo odepack/dlsode.lo odepack/ewset.lo odepack/intdy.lo 
odepack/prepj.lo odepack/solsy.lo odepack/stode.lo odepack/vnorm.lo 
odepack/scfode.lo odepack/sewset.lo odepack/sintdy.lo odepack/slsode.lo 
odepack/sprepj.lo odepack/ssolsy.lo odepack/sstode.lo odepack/svnorm.lo 
ordered-qz/dsubsp.lo ordered-qz/exchqz.lo ordered-qz/ssubsp.lo 
ordered-qz/sexchqz.lo quadpack/dqagi.lo quadpack/dqagie.lo 
quadpack/dqagp.lo quadpack/dqagpe.lo quadpack/dqelg.lo 
quadpack/dqk15i.lo quadpack/dqk21.lo quadpack/dqpsrt.lo 
quadpack/qagie.lo quadpack/qagi.lo quadpack/qagpe.lo quadpack/qagp.lo 
quadpack/qelg.lo quadpack/qk15i.lo quadpack/qk21.lo quadpack/qpsrt.lo 
quadpack/xerror.lo ranlib/advnst.lo ranlib/genbet.lo ranlib/genchi.lo 
ranlib/genexp.lo ranlib/genf.lo ranlib/gengam.lo ranlib/genmn.lo 
ranlib/genmul.lo ranlib/gennch.lo ranlib/gennf.lo ranlib/gennor.lo 
ranlib/genprm.lo ranlib/genunf.lo ranlib/getcgn.lo ranlib/getsd.lo 
ranlib/ignbin.lo ranlib/ignlgi.lo ranlib/ignnbn.lo ranlib/ignpoi.lo 
ranlib/ignuin.lo ranlib/initgn.lo ranlib/inrgcm.lo ranlib/lennob.lo 
ranlib/mltmod.lo ranlib/phrtsd.lo ranlib/qrgnin.lo ranlib/ranf.lo 
ranlib/setall.lo ranlib/setant.lo ranlib/setgmn.lo ranlib/setsd.lo 
ranlib/sexpo.lo ranlib/sgamma.lo ranlib/snorm.lo ranlib/wrap.lo 
slatec-err/fdump.lo slatec-err/ixsav.lo slatec-err/j4save.lo 
slatec-err/xerclr.lo slatec-err/xercnt.lo slatec-err/xerhlt.lo 
slatec-err/xermsg.lo slatec-err/xerprn.lo slatec-err/xerrwd.lo 
slatec-err/xersve.lo slatec-err/xgetf.lo slatec-err/xgetua.lo 
slatec-err/xsetf.lo slatec-err/xsetua.lo slatec-fn/albeta.lo 
slatec-fn/alngam.lo slatec-fn/alnrel.lo slatec-fn/algams.lo 
slatec-fn/acosh.lo slatec-fn/asinh.lo slatec-fn/atanh.lo 
slatec-fn/betai.lo slatec-fn/csevl.lo slatec-fn/d9gmit.lo 
slatec-fn/d9lgic.lo slatec-fn/d9lgit.lo slatec-fn/d9lgmc.lo 
slatec-fn/dacosh.lo slatec-fn/dasinh.lo slatec-fn/datanh.lo 
slatec-fn/dbetai.lo slatec-fn/dcsevl.lo slatec-fn/derf.lo 
slatec-fn/derfc.lo slatec-fn/dgami.lo slatec-fn/dgamit.lo 
slatec-fn/dgamlm.lo slatec-fn/dgamma.lo slatec-fn/dgamr.lo 
slatec-fn/dlbeta.lo slatec-fn/dlgams.lo slatec-fn/dlngam.lo 
slatec-fn/dlnrel.lo slatec-fn/dpchim.lo slatec-fn/dpchst.lo 
slatec-fn/erf.lo slatec-fn/erfc.lo slatec-fn/gami.lo slatec-fn/gamit.lo 
slatec-fn/gamlim.lo slatec-fn/gamma.lo slatec-fn/gamr.lo 
slatec-fn/initds.lo slatec-fn/inits.lo slatec-fn/pchim.lo 
slatec-fn/pchst.lo slatec-fn/r9lgmc.lo slatec-fn/r9lgit.lo 
slatec-fn/r9gmit.lo slatec-fn/r9lgic.lo slatec-fn/xdacosh.lo 
slatec-fn/xdasinh.lo slatec-fn/xdatanh.lo slatec-fn/xdbetai.lo 
slatec-fn/xderf.lo slatec-fn/xderfc.lo slatec-fn/xdgami.lo 
slatec-fn/xdgamit.lo slatec-fn/xdgamma.lo slatec-fn/xgmainc.lo 
slatec-fn/xacosh.lo slatec-fn/xasinh.lo slatec-fn/xatanh.lo 
slatec-fn/xerf.lo slatec-fn/xerfc.lo slatec-fn/xsgmainc.lo 
slatec-fn/xgamma.lo slatec-fn/xbetai.lo villad/dfopr.lo villad/dif.lo 
villad/intrp.lo villad/jcobi.lo villad/radau.lo villad/vilerr.lo 
-llapack -lblas -lgfortran -liberty -lm  -lgdi32 -lws2_32 -luser32 
-lkernel32
libtool: link: rm -fr  .libs/libcruft.a .libs/libcruft.lai

*** Warning: linker path does not have real file for library -liberty.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libiberty and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libiberty.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: ar cru .libs/libcruft.a amos/.libs/cacai.o 
amos/.libs/cacon.o amos/.libs/cbesh.o amos/.libs/cbesi.o 
amos/.libs/cbesj.o amos/.libs/cbesk.o amos/.libs/cbesy.o 
amos/.libs/cbinu.o amos/.libs/cbuni.o amos/.libs/cbunk.o 
amos/.libs/cunk1.o amos/.libs/cunk2.o amos/.libs/crati.o 
amos/.libs/cshch.o amos/.libs/cuni1.o amos/.libs/cuoik.o 
amos/.libs/cairy.o amos/.libs/cbiry.o amos/.libs/ckscl.o 
amos/.libs/cs1s2.o amos/.libs/cuchk.o amos/.libs/cuni2.o 
amos/.libs/cwrsk.o amos/.libs/casyi.o amos/.libs/cbknu.o 
amos/.libs/cmlri.o amos/.libs/cseri.o amos/.libs/cunhj.o 
amos/.libs/cunik.o amos/.libs/dgamln.o amos/.libs/gamln.o 
amos/.libs/xzabs.o amos/.libs/xzexp.o amos/.libs/xzlog.o 
amos/.libs/xzsqrt.o amos/.libs/zacai.o amos/.libs/zacon.o 
amos/.libs/zairy.o amos/.libs/zasyi.o amos/.libs/zbesh.o 
amos/.libs/zbesi.o amos/.libs/zbesj.o amos/.libs/zbesk.o 
amos/.libs/zbesy.o amos/.libs/zbinu.o amos/.libs/zbiry.o 
amos/.libs/zbknu.o amos/.libs/zbuni.o amos/.libs/zbunk.o 
amos/.libs/zdiv.o amos/.libs/zkscl.o amos/.libs/zmlri.o 
amos/.libs/zmlt.o amos/.libs/zrati.o amos/.libs/zs1s2.o 
amos/.libs/zseri.o amos/.libs/zshch.o amos/.libs/zuchk.o 
amos/.libs/zunhj.o amos/.libs/zuni1.o amos/.libs/zuni2.o 
amos/.libs/zunik.o amos/.libs/zunk1.o amos/.libs/zunk2.o 
amos/.libs/zuoik.o amos/.libs/zwrsk.o blas-xtra/.libs/xddot.o 
blas-xtra/.libs/xdnrm2.o blas-xtra/.libs/xdznrm2.o 
blas-xtra/.libs/xzdotc.o blas-xtra/.libs/xzdotu.o 
blas-xtra/.libs/xsdot.o blas-xtra/.libs/xsnrm2.o 
blas-xtra/.libs/xscnrm2.o blas-xtra/.libs/xcdotc.o 
blas-xtra/.libs/xcdotu.o blas-xtra/.libs/xerbla.o daspk/.libs/datv.o 
daspk/.libs/dcnst0.o daspk/.libs/dcnstr.o daspk/.libs/ddasic.o 
daspk/.libs/ddasid.o daspk/.libs/ddasik.o daspk/.libs/ddaspk.o 
daspk/.libs/ddstp.o daspk/.libs/ddwnrm.o daspk/.libs/dfnrmd.o 
daspk/.libs/dfnrmk.o daspk/.libs/dhels.o daspk/.libs/dheqr.o 
daspk/.libs/dinvwt.o daspk/.libs/dlinsd.o daspk/.libs/dlinsk.o 
daspk/.libs/dmatd.o daspk/.libs/dnedd.o daspk/.libs/dnedk.o 
daspk/.libs/dnsd.o daspk/.libs/dnsid.o daspk/.libs/dnsik.o 
daspk/.libs/dnsk.o daspk/.libs/dorth.o daspk/.libs/dslvd.o 
daspk/.libs/dslvk.o daspk/.libs/dspigm.o daspk/.libs/dyypnw.o 
dasrt/.libs/ddasrt.o dasrt/.libs/drchek.o dasrt/.libs/droots.o 
dassl/.libs/ddaini.o dassl/.libs/ddajac.o dassl/.libs/ddanrm.o 
dassl/.libs/ddaslv.o dassl/.libs/ddassl.o dassl/.libs/ddastp.o 
dassl/.libs/ddatrp.o dassl/.libs/ddawts.o lapack-xtra/.libs/xclange.o 
lapack-xtra/.libs/xdlamch.o lapack-xtra/.libs/xdlange.o 
lapack-xtra/.libs/xilaenv.o lapack-xtra/.libs/xslamch.o 
lapack-xtra/.libs/xslange.o lapack-xtra/.libs/xzlange.o 
misc/.libs/cquit.o misc/.libs/d1mach.o misc/.libs/f77-extern.o 
misc/.libs/f77-fcn.o misc/.libs/i1mach.o misc/.libs/lo-error.o 
misc/.libs/quit.o misc/.libs/r1mach.o odepack/.libs/cfode.o 
odepack/.libs/dlsode.o odepack/.libs/ewset.o odepack/.libs/intdy.o 
odepack/.libs/prepj.o odepack/.libs/solsy.o odepack/.libs/stode.o 
odepack/.libs/vnorm.o odepack/.libs/scfode.o odepack/.libs/sewset.o 
odepack/.libs/sintdy.o odepack/.libs/slsode.o odepack/.libs/sprepj.o 
odepack/.libs/ssolsy.o odepack/.libs/sstode.o odepack/.libs/svnorm.o 
ordered-qz/.libs/dsubsp.o ordered-qz/.libs/exchqz.o 
ordered-qz/.libs/ssubsp.o ordered-qz/.libs/sexchqz.o 
quadpack/.libs/dqagi.o quadpack/.libs/dqagie.o quadpack/.libs/dqagp.o 
quadpack/.libs/dqagpe.o quadpack/.libs/dqelg.o quadpack/.libs/dqk15i.o 
quadpack/.libs/dqk21.o quadpack/.libs/dqpsrt.o quadpack/.libs/qagie.o 
quadpack/.libs/qagi.o quadpack/.libs/qagpe.o quadpack/.libs/qagp.o 
quadpack/.libs/qelg.o quadpack/.libs/qk15i.o quadpack/.libs/qk21.o 
quadpack/.libs/qpsrt.o quadpack/.libs/xerror.o ranlib/.libs/advnst.o 
ranlib/.libs/genbet.o ranlib/.libs/genchi.o ranlib/.libs/genexp.o 
ranlib/.libs/genf.o ranlib/.libs/gengam.o ranlib/.libs/genmn.o 
ranlib/.libs/genmul.o ranlib/.libs/gennch.o ranlib/.libs/gennf.o 
ranlib/.libs/gennor.o ranlib/.libs/genprm.o ranlib/.libs/genunf.o 
ranlib/.libs/getcgn.o ranlib/.libs/getsd.o ranlib/.libs/ignbin.o 
ranlib/.libs/ignlgi.o ranlib/.libs/ignnbn.o ranlib/.libs/ignpoi.o 
ranlib/.libs/ignuin.o ranlib/.libs/initgn.o ranlib/.libs/inrgcm.o 
ranlib/.libs/lennob.o ranlib/.libs/mltmod.o ranlib/.libs/phrtsd.o 
ranlib/.libs/qrgnin.o ranlib/.libs/ranf.o ranlib/.libs/setall.o 
ranlib/.libs/setant.o ranlib/.libs/setgmn.o ranlib/.libs/setsd.o 
ranlib/.libs/sexpo.o ranlib/.libs/sgamma.o ranlib/.libs/snorm.o 
ranlib/.libs/wrap.o slatec-err/.libs/fdump.o slatec-err/.libs/ixsav.o 
slatec-err/.libs/j4save.o slatec-err/.libs/xerclr.o 
slatec-err/.libs/xercnt.o slatec-err/.libs/xerhlt.o 
slatec-err/.libs/xermsg.o slatec-err/.libs/xerprn.o 
slatec-err/.libs/xerrwd.o slatec-err/.libs/xersve.o 
slatec-err/.libs/xgetf.o slatec-err/.libs/xgetua.o 
slatec-err/.libs/xsetf.o slatec-err/.libs/xsetua.o 
slatec-fn/.libs/albeta.o slatec-fn/.libs/alngam.o 
slatec-fn/.libs/alnrel.o slatec-fn/.libs/algams.o 
slatec-fn/.libs/acosh.o slatec-fn/.libs/asinh.o slatec-fn/.libs/atanh.o 
slatec-fn/.libs/betai.o slatec-fn/.libs/csevl.o slatec-fn/.libs/d9gmit.o 
slatec-fn/.libs/d9lgic.o slatec-fn/.libs/d9lgit.o 
slatec-fn/.libs/d9lgmc.o slatec-fn/.libs/dacosh.o 
slatec-fn/.libs/dasinh.o slatec-fn/.libs/datanh.o 
slatec-fn/.libs/dbetai.o slatec-fn/.libs/dcsevl.o slatec-fn/.libs/derf.o 
slatec-fn/.libs/derfc.o slatec-fn/.libs/dgami.o slatec-fn/.libs/dgamit.o 
slatec-fn/.libs/dgamlm.o slatec-fn/.libs/dgamma.o 
slatec-fn/.libs/dgamr.o slatec-fn/.libs/dlbeta.o 
slatec-fn/.libs/dlgams.o slatec-fn/.libs/dlngam.o 
slatec-fn/.libs/dlnrel.o slatec-fn/.libs/dpchim.o 
slatec-fn/.libs/dpchst.o slatec-fn/.libs/erf.o slatec-fn/.libs/erfc.o 
slatec-fn/.libs/gami.o slatec-fn/.libs/gamit.o slatec-fn/.libs/gamlim.o 
slatec-fn/.libs/gamma.o slatec-fn/.libs/gamr.o slatec-fn/.libs/initds.o 
slatec-fn/.libs/inits.o slatec-fn/.libs/pchim.o slatec-fn/.libs/pchst.o 
slatec-fn/.libs/r9lgmc.o slatec-fn/.libs/r9lgit.o 
slatec-fn/.libs/r9gmit.o slatec-fn/.libs/r9lgic.o 
slatec-fn/.libs/xdacosh.o slatec-fn/.libs/xdasinh.o 
slatec-fn/.libs/xdatanh.o slatec-fn/.libs/xdbetai.o 
slatec-fn/.libs/xderf.o slatec-fn/.libs/xderfc.o 
slatec-fn/.libs/xdgami.o slatec-fn/.libs/xdgamit.o 
slatec-fn/.libs/xdgamma.o slatec-fn/.libs/xgmainc.o 
slatec-fn/.libs/xacosh.o slatec-fn/.libs/xasinh.o 
slatec-fn/.libs/xatanh.o slatec-fn/.libs/xerf.o slatec-fn/.libs/xerfc.o 
slatec-fn/.libs/xsgmainc.o slatec-fn/.libs/xgamma.o 
slatec-fn/.libs/xbetai.o villad/.libs/dfopr.o villad/.libs/dif.o 
villad/.libs/intrp.o villad/.libs/jcobi.o villad/.libs/radau.o 
villad/.libs/vilerr.o
libtool: link: ranlib .libs/libcruft.a
libtool: link: creating libcruft.la
libtool: link: ( cd ".libs" && rm -f "libcruft.la" && ln -s 
"../libcruft.la" "libcruft.la" )
make[2]: Leaving directory 
`/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'

benjamin

From jwe at octave.org  Sat Oct 31 12:09:41 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 31 Oct 2009 13:09:41 -0400
Subject: gnulib and automake
In-Reply-To: <4AEC6889.3010906@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net>
	<19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net>
	<19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net>
	<19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net>
	<19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net>
Message-ID: <19180.28501.319692.552649@segfault.lan>

On 31-Oct-2009, Benjamin Lindner wrote:

| then did a ./autoconf.sh followed by a call to configure, without any 
| "--enable" options.
| I then replaced all libtool flags "--silent" by "--verbose".

You can achieve the same by setting AM_LIBTOOLFLAGS in the
configure.ac file.  I set it to --silent because it was producing so
much output that it was hard to see when there were compiler warnings
or errors.  But for now, maybe it is best to not use the --silent
option by default, so I've commented out the line in configure.ac.

| Then "make" runs until libcruft is built, and again, no shared library 
| is created.
| The output is:
| 
| /bin/sh ../libtool --tag=CXX --verbose  --mode=link 
| mingw32-g++-4.4.0-dw2 -shared-libgcc -march=i686 -mtune=generic -O3 
| -Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W -Wshadow -Wold-style-cast 
| -Wformat -march=i686 -mtune=generic -O3 -Wall  -march=i686 
| -mtune=generic -O3 -Wall -release 3.3.50+ -shared-libgcc 
| -Wl,--allow-multiple-definition -o libcruft.la -rpath 
| /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
| [...]
| libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
| shared libraries

So this is preventing libtool from running any commands to generate
the shared library?

| libtool: link: ar cru .libs/libcruft.a  amos/.libs/cacai.o 
| [...]
| libtool: link: ranlib .libs/libcruft.a
| libtool: link: creating libcruft.la
| libtool: link: ( cd ".libs" && rm -f "libcruft.la" && ln -s 
| "../libcruft.la" "libcruft.la" )
| make[2]: Leaving directory 
| `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'

So it is creating static libraries even though the disable-static
option is supplied ott LT_INIT?  Do you see why that is happening?

| I tried again and added "-no-undefined" to libtool link command.
| Doesn't help.

| Making all in libcruft
| make[2]: Entering directory 
| `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'
| /bin/sh ../libtool --tag=CXX --verbose  --mode=link 
| mingw32-g++-4.4.0-dw2 -shared-libgcc -no-undefined -march=i686 
| -mtune=generic -O3 -Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W 
| -Wshadow -Wold-style-cast -Wformat -march=i686 -mtune=generic -O3 -Wall 
|   -march=i686 -mtune=generic -O3 -Wall -release 3.3.50+ -shared-libgcc 
| -Wl,--allow-multiple-definition -o libcruft.la -rpath 
| /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
| [...]
| villad/intrp.lo villad/jcobi.lo villad/radau.lo villad/vilerr.lo 
| -llapack -lblas -lgfortran -liberty -lm  -lgdi32 -lws2_32 -luser32 
| -lkernel32
| libtool: link: rm -fr  .libs/libcruft.a .libs/libcruft.lai
| 
| *** Warning: linker path does not have real file for library -liberty.
| *** I have the capability to make that library automatically link in when
| *** you link to this library.  But I can only do this if you have a
| *** shared version of the library, which you do not appear to have
| *** because I did check the linker path looking for a file starting
| *** with libiberty and none of the candidates passed a file format test
| *** using a file magic. Last file checked: /mingw/lib/libiberty.a
| *** The inter-library dependencies that have been dropped here will be
| *** automatically added whenever a program is linked with this library
| *** or is declared to -dlopen it.
| 
| *** Since this library must not contain undefined symbols,
| *** because either the platform does not support them or
| *** it was explicitly requested with -no-undefined,
| *** libtool will only create a static version of it.
| libtool: link: ar cru .libs/libcruft.a amos/.libs/cacai.o 

If you remove -liberty from this call to libtool, what link command
does libtool eventually execute?  Does it work?  What happens if you
add the -liberty option to this command?

I'm willing to do some work to find solutions to these problems.  It
might go faster if you or someone else could tell me what I need to
install so that I can try to build Octave on a Windows system.

jwe

From jwe at octave.org  Sat Oct 31 12:12:40 2009
From: jwe at octave.org (John W. Eaton)
Date: Sat, 31 Oct 2009 13:12:40 -0400
Subject: gnulib and automake
In-Reply-To: <4AEC6889.3010906@gmx.net>
References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net>
	<19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net>
	<19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net>
	<19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net>
	<19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net>
	<19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net>
Message-ID: <19180.28680.836723.376270@segfault.lan>

I updated the patch here:

  http://jweaton.org/automake-diffs.gz

Please start with this newer version of the patch if you decide to try
any further debugging.

Thanks,

jwe

From lindnerben at gmx.net  Sat Oct 31 14:31:20 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sat, 31 Oct 2009 20:31:20 +0100
Subject: gnulib and automake
In-Reply-To: <19180.28501.319692.552649@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<4AEB36F9.9070404@gmx.net>	<19179.15601.907503.686285@segfault.lan>	<4AEB46EE.8030400@gmx.net>	<19179.21624.130899.537300@segfault.lan>	<4AEB58DA.9070805@gmx.net>	<19179.26026.448430.104714@segfault.lan>	<4AEC1A96.4020108@gmx.net>	<19180.23890.807202.518048@segfault.lan>	<4AEC6889.3010906@gmx.net>
	<19180.28501.319692.552649@segfault.lan>
Message-ID: <4AEC9088.7020404@gmx.net>

John W. Eaton wrote:
> On 31-Oct-2009, Benjamin Lindner wrote:
> 
> | then did a ./autoconf.sh followed by a call to configure, without any 
> | "--enable" options.
> | I then replaced all libtool flags "--silent" by "--verbose".
> 
> You can achieve the same by setting AM_LIBTOOLFLAGS in the
> configure.ac file.  I set it to --silent because it was producing so
> much output that it was hard to see when there were compiler warnings
> or errors.  But for now, maybe it is best to not use the --silent
> option by default, so I've commented out the line in configure.ac.

Oh, I understand why you set it to --silent, and I agree.
I just changed it for debugging purposes, because I hoped to get some 
additional informatiln from libtool.

> | Then "make" runs until libcruft is built, and again, no shared library 
> | is created.
> | The output is:
> | 
> | /bin/sh ../libtool --tag=CXX --verbose  --mode=link 
> | mingw32-g++-4.4.0-dw2 -shared-libgcc -march=i686 -mtune=generic -O3 
> | -Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W -Wshadow -Wold-style-cast 
> | -Wformat -march=i686 -mtune=generic -O3 -Wall  -march=i686 
> | -mtune=generic -O3 -Wall -release 3.3.50+ -shared-libgcc 
> | -Wl,--allow-multiple-definition -o libcruft.la -rpath 
> | /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
> | [...]
> | libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 
> | shared libraries
> 
> So this is preventing libtool from running any commands to generate
> the shared library?
> 
> | libtool: link: ar cru .libs/libcruft.a  amos/.libs/cacai.o 
> | [...]
> | libtool: link: ranlib .libs/libcruft.a
> | libtool: link: creating libcruft.la
> | libtool: link: ( cd ".libs" && rm -f "libcruft.la" && ln -s 
> | "../libcruft.la" "libcruft.la" )
> | make[2]: Leaving directory 
> | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'
> 
> So it is creating static libraries even though the disable-static
> option is supplied ott LT_INIT?  Do you see why that is happening?

It appears to be so.

> | I tried again and added "-no-undefined" to libtool link command.
> | Doesn't help.
> 
> | Making all in libcruft
> | make[2]: Entering directory 
> | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft'
> | /bin/sh ../libtool --tag=CXX --verbose  --mode=link 
> | mingw32-g++-4.4.0-dw2 -shared-libgcc -no-undefined -march=i686 
> | -mtune=generic -O3 -Wall   -DHAVE_CONFIG_H -mieee-fp    -Wall -W 
> | -Wshadow -Wold-style-cast -Wformat -march=i686 -mtune=generic -O3 -Wall 
> |   -march=i686 -mtune=generic -O3 -Wall -release 3.3.50+ -shared-libgcc 
> | -Wl,--allow-multiple-definition -o libcruft.la -rpath 
> | /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ 
> | [...]
> | villad/intrp.lo villad/jcobi.lo villad/radau.lo villad/vilerr.lo 
> | -llapack -lblas -lgfortran -liberty -lm  -lgdi32 -lws2_32 -luser32 
> | -lkernel32
> | libtool: link: rm -fr  .libs/libcruft.a .libs/libcruft.lai
> | 
> | *** Warning: linker path does not have real file for library -liberty.
> | *** I have the capability to make that library automatically link in when
> | *** you link to this library.  But I can only do this if you have a
> | *** shared version of the library, which you do not appear to have
> | *** because I did check the linker path looking for a file starting
> | *** with libiberty and none of the candidates passed a file format test
> | *** using a file magic. Last file checked: /mingw/lib/libiberty.a
> | *** The inter-library dependencies that have been dropped here will be
> | *** automatically added whenever a program is linked with this library
> | *** or is declared to -dlopen it.
> | 
> | *** Since this library must not contain undefined symbols,
> | *** because either the platform does not support them or
> | *** it was explicitly requested with -no-undefined,
> | *** libtool will only create a static version of it.
> | libtool: link: ar cru .libs/libcruft.a amos/.libs/cacai.o 
> 
> If you remove -liberty from this call to libtool, what link command
> does libtool eventually execute?  Does it work?  What happens if you
> add the -liberty option to this command?
> 
> I'm willing to do some work to find solutions to these problems.  It
> might go faster if you or someone else could tell me what I need to
> install so that I can try to build Octave on a Windows system.

I did some googleing (how do spell this anyway? :) and found:

http://lists.cairographics.org/archives/cairo/2009-July/017683.html

and the answer at

http://lists.cairographics.org/archives/cairo/2009-July/017684.html

Now this is getting me somewhere.

If I patch msys' libtool as

--- /share/aclocal/libtool.m4	2009-10-31 17:24:28 +0100
+++ octave-tip-automake/m4/libtool.m4	2009-10-31 17:57:23 +0100
@@ -2954,13 +2954,7 @@
    # Base MSYS/MinGW do not provide the 'file' command needed by
    # func_win32_libid shell function, so use a weaker test based on 
'objdump',
    # unless we find 'file', for example because we are cross-compiling.
-  if ( file / ) >/dev/null 2>&1; then
-    lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
-    lt_cv_file_magic_cmd='func_win32_libid'
-  else
-    lt_cv_deplibs_check_method='file_magic file format 
pei*-i386(.*architecture: i386)?'
-    lt_cv_file_magic_cmd='$OBJDUMP -f'
-  fi
+  lt_cv_deplibs_check_method=pass_all
    ;;

  cegcc*)

and add "-no-undefined" to libtool link command in makefile.in of 
libcruft, liboctave and liboctinterp as


libcruft_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
	$(LIBTOOLFLAGS) --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) \
	$(CXXFLAGS) $(libcruft_la_LDFLAGS) $(LDFLAGS) -o $@


liboctave_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
	$(LIBTOOLFLAGS) --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) \
	$(CXXFLAGS) $(liboctave_la_LDFLAGS) $(LDFLAGS) -o $@


liboctinterp_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
	$(LIBTOOLFLAGS) --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) \
	$(CXXFLAGS) $(liboctinterp_la_LDFLAGS) $(LDFLAGS) -o $@
CXXLINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
	--mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) $(CXXFLAGS) 
$(AM_LDFLAGS) \
	$(LDFLAGS) -o $@


Then I get a shared libcruft, shared liboctave and shared liboctinterp. 
Ha! Victory at last.

Building .oct files not fails with undefined reference errors.
I think I can guess what is missing here.

I'll start with your new patch and put the bits and pieces together.

benjamin



From lindnerben at gmx.net  Sat Oct 31 14:31:46 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sat, 31 Oct 2009 20:31:46 +0100
Subject: gnulib and automake
In-Reply-To: <19180.28680.836723.376270@segfault.lan>
References: <19121.21838.419944.184758@segfault.lan>	<4AE5824C.5040106@gmx.net>	<19176.28026.31789.710006@segfault.lan>	<4AEB36F9.9070404@gmx.net>	<19179.15601.907503.686285@segfault.lan>	<4AEB46EE.8030400@gmx.net>	<19179.21624.130899.537300@segfault.lan>	<4AEB58DA.9070805@gmx.net>	<19179.26026.448430.104714@segfault.lan>	<4AEC1A96.4020108@gmx.net>	<19180.23890.807202.518048@segfault.lan>	<4AEC6889.3010906@gmx.net>
	<19180.28680.836723.376270@segfault.lan>
Message-ID: <4AEC90A2.5000909@gmx.net>

John W. Eaton wrote:
> I updated the patch here:
> 
>   http://jweaton.org/automake-diffs.gz
> 
> Please start with this newer version of the patch if you decide to try
> any further debugging.
> 

sure,
I'll start a new clean trial and report back.

benjamin