Re: Octave3.6.0_gcc4.6.2 mingw binaries for testing

Hello

--- On Wed, 2012/2/1, fork wrote:

> 
> 4.  Can't we keep the binaries on sourceforge, or a site with a little less
> cheese?  I am afraid my IT department is going to think I am downloading pirated
> movies every time I follow that link ;)
> 

http://octave.1599824.n4.nabble.com/Release-3-6-0-still-not-quot-official-quot-td4345497.html

Since JWE told that Release 3.6.0 still not "official" and he will make octave 3.6.1 soon.
It is better to wait to copy binary to the sourceforge.

I have also a success for the more stable ATLAS than before.  This change hopefully will be included.

Regards

Tatsuro

RE: problem after updating gui

________________________________________
From: Ben Abbott [bpabbott <at> mac.com]
Sent: Tuesday, January 31, 2012 5:39 PM
To: Robinson, Melvin D
Cc: Jacob Dawid; octave maintainers mailing list
Subject: Re: problem after updating gui

On Jan 31, 2012, at 6:31 PM, Robinson, Melvin D wrote:

> On 1/31/12 4:40 PM, "Ben Abbott" <bpabbott <at> mac.com> wrote:
>
>> On Jan 31, 2012, at 5:36 PM, Ben Abbott wrote:
>>
>>> On Jan 31, 2012, at 5:30 PM, Ben Abbott wrote:
>>>
>>>> After you moved the hgrc, I see ...
>>>>
>>>> $ hg pull ; hg update -C gui
>>>> pulling from /Users/bpabbott/Development/mercurial/octave
>>>> searching for changes
>>>> adding changesets
>>>> adding manifests
>>>> adding file changes
>>>> added 1 changesets with 2 changes to 2 files
>>>> (run 'hg update' to get a working copy)
>>>> fatal: Not a git repository (or any of the parent directories): .git
>>>> abort: git rev-parse error 128 in gui/qirc
>>>>
>>>> Ben

Re: problem after updating gui

On Jan 31, 2012, at 7:25 PM, Robinson, Melvin D wrote:

> From: Ben Abbott [bpabbott <at> mac.com]
> 
> On Jan 31, 2012, at 6:31 PM, Robinson, Melvin D wrote:
> 
>> On 1/31/12 4:40 PM, "Ben Abbott" <bpabbott <at> mac.com> wrote:
>> 
>>> On Jan 31, 2012, at 5:36 PM, Ben Abbott wrote:
>>> 
>>>> On Jan 31, 2012, at 5:30 PM, Ben Abbott wrote:
>>>> 
>>>>> After you moved the hgrc, I see ...
>>>>> 
>>>>> $ hg pull ; hg update -C gui
>>>>> pulling from /Users/bpabbott/Development/mercurial/octave
>>>>> searching for changes
>>>>> adding changesets
>>>>> adding manifests
>>>>> adding file changes
>>>>> added 1 changesets with 2 changes to 2 files
>>>>> (run 'hg update' to get a working copy)
>>>>> fatal: Not a git repository (or any of the parent directories): .git
>>>>> abort: git rev-parse error 128 in gui/qirc
>>>>> 
>>>>> Ben
>>>> 
>>>> From the gui directory ...
>>>> 
>>>> $ ls -l

Re: Release 3.6.0 still not "official"

Hello

--- On Wed, 2012/2/1, John W. Eaton wrote:

> On 25-Jan-2012, Rik wrote:
> 
> | 1/25/11
> | 
> | jwe,
> | 
> | Is 3.6.0 official?  Should the download page be updated
> | (http://www.gnu.org/software/octave/download.html)?
> 
> Given the pkg build/install bug that causes a crash, I decided to stay
> under the radar with 3.6.0.
> 
> I plan to make 3.6.1 within the next day or so, then make a proper
> announcement about that.

How do you want you treat qhull?
Very recently the change in qhull-2012 is included in the default branch.
Will this change be included in the octave-3.6.1.

Regards

Tatsuro

octave-qui: MinGW build was in failure

Hello

I have tried new octave-gui on the MinGW platform.

***********************************************
g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG
-DQT_GUI_LIB -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT
-DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -I'c:/Programs/Qt/4.8.0/include/QtCore'
-I'c:/Programs/Qt/4.8.0/include/QtGui' -I'c:/Programs/Qt/4.8.0/include'
-I'c:/Programs/Qt/4.8.0/include/ActiveQt' -I'release'
-I'c:/Programs/Qt/4.8.0/mkspecs/default' -o release/QTerminalColors.o win32/QTerminalColors.cpp
win32/QTerminalColors.cpp:25:35: fatal error: win32/QTerminalColors.h: No such file or directory
compilation terminated.
make[3]: *** [release/QTerminalColors.o] Error 1
make[3]: Leaving directory `/home/octaves/hg/octave-gui/gui/qterminal/libqterminal'
make[2]: *** [release] Error 2
make[2]: Leaving directory `/home/octaves/hg/octave-gui/gui/qterminal/libqterminal'
make[1]: *** [sub-libqterminal-make_default] Error 2
make[1]: Leaving directory `/home/octaves/hg/octave-gui/gui/qterminal'
make: *** [sub-qterminal-make_default] Error 2
******************************************************
win32/QTerminalColors.cpp:25:35: fatal error: win32/QTerminalColors.h: No such file or directory

It seems that incude flag (-I./win32) is not defined.
How can I add include flag?

I have seen the libqterminal.pro but I did not find the way.

Regards

Re: Qhull include files

RE: problem after updating gui

________________________________________
From: Ben Abbott [bpabbott <at> mac.com]
Sent: Tuesday, January 31, 2012 6:37 PM
To: Robinson, Melvin D
Cc: Jacob Dawid; octave maintainers mailing list
Subject: Re: problem after updating gui

On Jan 31, 2012, at 7:25 PM, Robinson, Melvin D wrote:

> From: Ben Abbott [bpabbott <at> mac.com]
>
> On Jan 31, 2012, at 6:31 PM, Robinson, Melvin D wrote:
>
>> On 1/31/12 4:40 PM, "Ben Abbott" <bpabbott <at> mac.com> wrote:
>>
>>> On Jan 31, 2012, at 5:36 PM, Ben Abbott wrote:
>>>
>>>> On Jan 31, 2012, at 5:30 PM, Ben Abbott wrote:
>>>>
>>>>> After you moved the hgrc, I see ...
>>>>>
>>>>> $ hg pull ; hg update -C gui
>>>>> pulling from /Users/bpabbott/Development/mercurial/octave
>>>>> searching for changes
>>>>> adding changesets
>>>>> adding manifests
>>>>> adding file changes
>>>>> added 1 changesets with 2 changes to 2 files
>>>>> (run 'hg update' to get a working copy)
>>>>> fatal: Not a git repository (or any of the parent directories): .git
>>>>> abort: git rev-parse error 128 in gui/qirc
>>>>>
>>>>> Ben
>>>>
>>>> From the gui directory ...
>>>>
>>>> $ ls -l
>>>> total 16
>>>> drwxr-xr-x   3 bpabbott  staff  102 Jan 31 10:32 bin
>>>> drwxr-xr-x   5 bpabbott  staff  170 Jan 31 10:05 kb-layouts
>>>> drwxr-xr-x  14 bpabbott  staff  476 Jan 31 10:05 languages
>>>> drwxr-xr-x   8 bpabbott  staff  272 Jan 31 10:05 media
>>>> -rw-r--r--   1 bpabbott  staff  957 Jan 31 10:05 msvc-debug.pri
>>>> drwxr-xr-x   6 bpabbott  staff  204 Jan 31 17:29 qirc
>>>> drwxr-xr-x   5 bpabbott  staff  170 Jan 31 10:32 qterminal
>>>> drwxr-xr-x  27 bpabbott  staff  918 Jan 31 10:05 src
>>>> -rw-r--r--   1 bpabbott  staff  435 Jan 31 10:05 translators
>>>> drwxr-xr-x   2 bpabbott  staff   68 Jan 31 10:32 ui-files
>>>>
>>>> Am I catching you in a transition ?
>>>>
>>>> Ben
>>>
>>> I took your earlier advice and deleted qirc and qterminal. Now I'm able
>>> to update.
>>>
>>> Ben
>>
>> I get a whole smattering of errors now.  I also took the suggestion of
>> deleting qirc and qterminal.  These seem to have updated OK, but some path
>> must have gotten screwed up.
>>
>> In file included from MainWindow.h:31,
>>                from MainWindow.cpp:25:
>> backend/OctaveLink.h:28:27: error: octave/config.h: No such file or
>> directory
>> backend/OctaveLink.h:29:29: error: octave/cmd-edit.h: No such file or
>> directory
>> backend/OctaveLink.h:30:26: error: octave/error.h: No such file or
>> directory
>> backend/OctaveLink.h:31:28: error: octave/file-io.h: No such file or
>> directory
>> backend/OctaveLink.h:32:26: error: octave/input.h: No such file or
>> directory
>> backend/OctaveLink.h:33:24: error: octave/lex.h: No such file or directory
>> backend/OctaveLink.h:34:30: error: octave/load-path.h: No such file or
>> directory
>> backend/OctaveLink.h:35:27: error: octave/octave.h: No such file or
>> directory
>> backend/OctaveLink.h:36:29: error: octave/oct-hist.h: No such file or
>> directory
>> backend/OctaveLink.h:37:28: error: octave/oct-map.h: No such file or
>> directory
>> backend/OctaveLink.h:38:28: error: octave/oct-obj.h: No such file or
>> directory
>> backend/OctaveLink.h:39:24: error: octave/ops.h: No such file or directory
>> backend/OctaveLink.h:40:23: error: octave/ov.h: No such file or directory
>> backend/OctaveLink.h:41:31: error: octave/ov-usr-fcn.h: No such file or
>> directory
>>
>> Many more like these.
>
> The entire process I used is below ...
>
>        cd gui
>        rm -r ./qirc
>        rm -r ./qterminal
>        make clean
>        hg pull ; hg  update -C gui
>        qmake-qt4
>        make
>
> Ben
>
> I did this, but there seems to be no src/octave directory.  Do you have one?

No.

Maybe there are some files remaining from the past ?

From the top of your archive you can delete everything that isn't part of the mercurial archive by ...

        hg status | grep '^? ' | sed "s/^? /rm /g" | /bin/sh

... which means you'll have to rebuild everything.

        cd gui
        qmake-qt4
        make

Ben

I blew away the entire gui directory.  Still calls out the non-existent octive directory:
backend/OctaveLink.h:28:27: error: octave/config.h: No such file or directory
backend/OctaveLink.h:29:29: error: octave/cmd-edit.h: No such file or directory
backend/OctaveLink.h:30:26: error: octave/error.h: No such file or directory
backend/OctaveLink.h:31:28: error: octave/file-io.h: No such file or directory
backend/OctaveLink.h:32:26: error: octave/input.h: No such file or directory

etc.

Are you thinking that I need to rebuild Octave as well?

Re: Qhull test changes

At 08:58 AM 1/31/2012, Ben Abbott wrote:

>On Jan 30, 2012, at 9:25 PM, Brad Barber wrote:
>
>> At 08:25 PM 1/30/2012, Ben Abbott wrote:
>> 
>>> On Jan 30, 2012, at 7:42 PM, Brad Barber wrote:
>>> 
>>>> At 07:32 PM 1/30/2012, Ben Abbott wrote:
>>>> 
>>>>> On Jan 30, 2012, at 7:15 PM, Alexander Hansen wrote:
>>>>> 
>>>>>> On 1/30/12 6:02 PM, Rik wrote:
>>>>>> 
>>>>>> <snip>
>>>>>> 
>>>>>>>> I'm not certain, but doesn't "Qt" imply that the convex hull
>>>>>>>> should be made up of triangles ? (perhaps I should study the
>>>>>>>> qhull docs a bit ?)
>>>>>>>> 
>>>>>>>> In any event, I favored the more recent qhull because it matches
>>>>>>>> Matlab's result.
>>>>>>>> 
>>>>>>> Yes, the output should be triangulated when we pass the 'Qt' option
>>>>>>> and the new post-2011 Qhull behavior is mathematically correct.
>>>>>>> The problem is that Qhull is not returning triangulated output for
>>>>>>> versions less than 2011 and users will blame Octave when they see a
>>>>>>> failing test in the test report.  I am proposing that Octave work
>>>>>>> around the different Qhull versions so we don't generate a lot of
>>>>>>> spurious bug reports.
>>>>>>> 
>>>>>>> On the other hand, if we want we could leave the test in and also
>>>>>>> put in some comments that specifically say, "If you see this test
>>>>>>> failing, then you must upgrade your Qhull installation."  This
>>>>>>> might do a bit towards pushing users and distributions to upgrade
>>>>>>> to a new Qhull.
>>>>>>> 
>>>>>>> --Rik
>>>>>> 
>>>>>> Excuse me jumping in, but does this indicate that I should be using
>>>>>> qhull>=2011 for my Octave-3.4.3 and Octave-3.6.0 Fink packages?  I've
>>>>>> been using 2009.3.
>>>>>> 
>>>>>> -- 
>>>>>> Alexander Hansen
>>>>>> Fink User Liaison
>>>>> 
>>>>> To use qhull 2011 a patch is needed. 2009, 2010, or 2012 should each be ok. The problem appears to be in
the tests Octave runs (i.e. make check)
>>>>> 
>>>>> Ben
>>>> 
>>>> I hope that all builds of Octave upgrade to 2012.1.  There's a serious bug with 2009.1 and other bugs
fixed in 2011.2 and 2012.1.  For details, see
>>>>  http://gitorious.org/qhull/qhull/blobs/master/src/Changes.txt
>>>> 
>>>>                               --Brad
>>> 
>>> Is there a simple way to test for the serious 2009 bug ? Something that could be added to the configure process?
>>> 
>>> Ben
>> 
>> Hi Ben,
>> 
>> The easiest is to check the code for qh_gethash in poly.c.  It should read
>>     result %= (unsigned)hashsize;
>> Instead of
>>     hash %= (ptr_intT) hashsize
>> 
>> See http://www.qhull.org/download/poly.c-qh_gethash.patch
>> 
>> The problem occurs if the set elements have the high-bit set.  This only occurs on 32-bit machines with
more than 2G memory.   The data needs to be allocated in high-mem.  Typically, qhull will overwrite an
arbitrary location with undefined results, often a segfault.
>> 
>> For other notes about bugs see
>>   http://www.qhull.org/news/qhull-news.html#bugs
>> 
>>                                --Brad
>
>Do I understand that 2009 can be patched to work properly by making the change above ? If so, perhaps some
linux distributions have done that?

Yes, some have.  For an example, see 2009.1.3 on the Qhull download page.  This build will go away after 2012.1
is released.   The source files have become out-of-date.
    http://www.qhull.org/download/

>Is it possible to write a simple program that can be used to test if the bug is present? That would allow us to
test for this during the configure process and give a warning at the end.

No.  You could grep the source poly.c for the bad line, but that seems wrong.  

                                        --Brad

>Ben
>
>
>
>
>
>
>-----
>No virus found in this message.
>Checked by AVG - www.avg.com
>Version: 10.0.1416 / Virus Database: 2109/4777 - Release Date: 01/30/12

Re: Qhull include files

On 01/31/2012 06:18 PM, Brad Barber wrote:
> At 01:59 PM 1/31/2012, Rik wrote:
>> On 01/30/2012 09:09 PM, Tatsuro MATSUOKA wrote:
>> > Hello
>> >
>> > One thing I have to tell that directories of the header files of the
>> qhull 2012 are 'libqhull' and 'libqhullcpp' in the include directory.
>> >
>> > However, the octave assume that header files in the 'qhull'.
>> >
>> > I have copied libqhull to qhull in the build
>> >
>> > Regards
>> >
>> > Tatsuro
>> 1/31/12
>>
>> The Qhull include files have drifted around in the file system which is
>> why it is necessary when using Qhull2012 to either specify
>> '--with-qhull-includedir=DIR' or rename the libqhull directory to qhull
>> so that the build system can find them.
>>
>> From configure.ac, Octave is checking for Qhull in 4 places
>> [qhull/libqhull.h libqhull.h qhull/qhull.h qhull.h].
>>
>> --- configure.ac ---
>>
>> OCTAVE_CHECK_LIBRARY(qhull, QHull,
>> Â  [Qhull library not found -- this will result in loss of functionality
>> of some geometry functions.],
>> Â  [qhull/libqhull.h libqhull.h qhull/qhull.h qhull.h], [qh_qhull], [], [],
>>
>> --- configure.ac ---
>>
>> The resulting include file is similarly convoluted.
>>
>> --- oct-qhull.h ---
>>
>> #if defined (HAVE_QHULL_LIBQHULL_H) || defined (HAVE_QHULL_QHULL_H)
>> # if defined (HAVE_QHULL_LIBQHULL_H)
>> #Â  include <qhull/libqhull.h>
>> # else
>> #Â  include <qhull/qhull.h>
>> # endif
>> # include <qhull/qset.h>
>> # include <qhull/geom.h>
>> # include <qhull/poly.h>
>> # include <qhull/io.h>
>> #elif defined (HAVE_LIBQHULL_H) || defined (HAVE_QHULL_H)
>> # if defined (HAVE_LIBQHULL_H)
>> #Â  include <libqhull.h>
>> # else
>> #Â  include <qhull.h>
>> # endif
>> # include <qset.h>
>> # include <geom.h>
>> # include <poly.h>
>> # include <io.h>
>> #endif
>>
>> --- oct-qhull.h ---
>>
>> Qhull2012, using the cmake build and install instructions in the README,
>> installed the required header file in /usr/local/libqhull/libqhull.h.
>>
>> One option for Octave would be to add a fifth location
>> [libqhull/libqhull.h] to configure.ac.  In addition oct-qhull.h would
>> then need a third #elif branch to locate the necessary config files.
>>
>> However, I have a question about how downstream package maintainers
>> intend to treat Qhull.  They may decide to override the source code's
>> default install location and put the files in one of the existing
>> directories.  If they do that then a build on an ordinary system will
>> be fine.  I have CC'ed Jordi, who has experience with Debian packaging,
>> and Jussi, who has experience with Fedora packging, to get their opinion
>> on how the source code default paths and the distribution's default
>> paths interact and what the likely location of a Qhull2012 package would be.
>>
>> --Rik
>
> The qhull source tree was reorganized for 2011.1 to support multiple
> build systems  and the C++ interface.  I was following Qt convention. 
> They split up the headers into modules.
>
> In the code, there's multiple references to libqhull/*.h, especially from
> the C++ code to the C code.  This helps distinguish between C and C++
> headers.
>      #include "libqhull/qhull_a.h"
>
> The 'install' destination for include files was changed to reflect this
> organization.    It could be changed, at the cost of increasing the
> search paths for include files in the code.
>
> What is your preference?    If the qhull build can not use the installed
> 'include' directory, is that OK?

I think my preference is to wait for the package maintainers to weigh in on
this question.  Once we know where the include files will be we can code up
configure.ac appropriately.

>
> .../include/qhull/...  with C and C++ headers mixed together
>
> or
> .../include/qhull/libqhullcpp/... for C++ headers
> .../include/qhull/... with everything else
>
> or
> .../include/qhullcpp/...  with C++ headers mixed together
> .../include/qhull/...       with everythingelse
>
> or as is currently done:
> .../include/qhull/libqhull/...
> .../include/qhull/libqhullcpp/...
> .../include/qhull/road/...
>
> Can Octave simply upgrade to the current version?  Users should not be
> using qhull 2003.1 and 2009.1, especially as they move to 64-bit and
> larger memories.
Not always.  For example, sometimes users are on a Long Term Release of a
distribution which means the libraries are fixed except for security
patches.  Is there something glaringly wrong with earlier distributions,
like they add 2+2 and get 5, or is it performance-oriented like 64-bit
support?  Generally, Octave guru John W. Eaton frowns upon version checks
in the configure file.  Rather, it is usually preferable to test a library
for a specific functionality.  If it has the specific functionality we
need, even if other parts of the library are bad, then we will use it.

--Rik

qh_new_qhull calling conventions

1/31/12

Brad,

I built a small C++ test case to verify the problem with Qhull returning
either 6 or 12 facets when given a 3D cube input.  I was correct that the
behavior changed from 2009 to 2012.  But, you were correct that something
was wrong with the Octave code.

The prototype for the function qh_new_qhull is:

int qh_new_qhull(int dim, int numpoints, coordT *points, boolT ismalloc,
                 char *qhull_cmd, FILE *outfile, FILE *errfile);

In Octave, the FILE pointers are initialized as

// Replace the 0 pointer with stdout for debugging information.
FILE *outfile = 0;
FILE *errfile = stderr;

In Qhull2012 this causes no problems.  In Qhull2009, however, I get a hull
with only 6 facets.  However, if I initialize outfile to a valid FILE
pointer such as stdout or a pointer returned from fopen() then Qhull2009
returns 12 facets.  If I had to guess, I'd say that Qhull2009 is not
checking the argument for a NULL pointer and there is some sort of memory
corruption happening.

In my test case, I solved the problem by using

FILE *outfile = fopen ("/dev/null", "w");

Octave Maintainer's:

This should be solved before the 3.6.1 release.  Does anybody have a good
way to create a throw-away FILE pointer?

The "/dev/null" solution would be fine except I'm not certain it would work
on MinGW and Cygwin platforms.  My little bit of a web search seemed to
indicate that they DO implement this special file.

Otherwise, we could always use fopen with a temporary file name created
through tmpnam and then delete it afterwards but this seems like a lot of
work for every convhull, voronoi, or delaunay call.  

I've attached my test case and Makefile.  On my machine I had Qhull2009
installed by the package manager in /usr and Qhull2012 installed by hand in
/usr/local and used -L options to flip between the two.

--Rik

all: qhulltst2012 qhulltst2009 qhulltst2009FIX

qhulltst2012:
	g++ -o $ <at>  -DQ2012 -I/usr/local/include/ -lqhull -L/usr/local/lib qhulltst.cc

qhulltst2009:
	g++ -o $ <at>  -lqhull qhulltst.cc

qhulltst2009FIX:
	g++ -o $ <at>  -DQ2009FIX -lqhull qhulltst.cc

clean:
	 <at> -rm qhulltst2012 qhulltst2009 qhulltst2009FIX