octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qhull6 and octave


From: Brad Barber
Subject: Re: qhull6 and octave
Date: Mon, 21 Nov 2011 21:11:44 -0500

Dear Petr and others via CC,

Thanks for following up with the qhull6 build for Octave.  From notes from 
those on the CC list, there's problems with the build.  

It appears that the build has not been updated for qhull6 or is missing 
something important.  Rafael Laboissiere developed the first Octave build, but 
he is no longer active.

Since no output was generated, Qhull probably reported an error.  Octave may be 
swallowing the error message.

New to the 2011.1 release was a code reorganization and builds for CMake, 
DevStudio, gcc, mingw, and Qt Creator.  I tried to figure out the 
configure/Debian/Octave build but was unsuccessful.

These builds should provide a model for Octave.  Once you have functioning 
code, compare the trace output (T1...T5), with a normal qhull build.  It will 
identify where the Octave implementation diverges.  

Please replace #include "qhull.h" with #include "libqhull.h".  On Windows 
systems, qhull.h got confused with the C++ Qhull.h.   For 2011.2, I'm adding 
back qhull.h, but renamed as qhull.h-deprecated.

Some notes:

- Qhull 2011.2 should be released shortly.   You will probably want to upgrade. 
 It fixes a long standing bug in qh_new_qhull (qh_prepare_output is not called 
if outfile==NULL).  It reports an error if qh_newhashtable, qh_setnew, or 
qh_memalloc are passed a negative size (due to int overflow on 64-bit hosts).

- For Qhull 2012.1, I'm thinking of redoing the shared library for 
multi-threading and 64-bits.    Currently, Qhull supports multiple threads with 
only one thread active at a time.  The C++ interface is clumsy for this reason. 
 While qhull currently works fine on 64-bit architectures, its widespread use 
of 'int' type eventually overflows.  

The new shared library, qhull7, would allow multiple threads to run multiple 
instances of qhull at the same time.  It would not be multi-threaded 
internally, nor  would it be interface compatible with qhull6.   It would be 
somewhat slower since most of the functions would need a pointer to global 
state.  The C++ interface would only work with qhull7.    

Qhull6 would be maintained indefinitely for users that do not need 
multi-threading.  Since the code has been stable for many years, both qhull6 
and qhull7 would be maintained in parallel.

Let me know if you have strong feelings one way or the other. 

Many thanks everyone for keeping Qhull in Octave.  

                                --Brad

P.S. Pete Cheeseman reported the line endings problem with Qhull 2009.1.1.  
I'll fix it as part of updating 2011.2.


At 11:12 AM 11/21/2011, Petr Gajdos wrote:
>Hi,
>
>I have problems with octave built against qhull6 (see qhull-test.c
>derived from octave code).
>
>work/qhull> gcc -o qhull-test qhull-test.c -lqhull -lm
>-DQHULL5
>qhull-test.c:4:2: warning: #warning qhull5 [-Wcpp]
>work/qhull> ./qhull-test
>4 20 47
>6 20 29
>2 44 29
>53 35 33
>66 30 56
>25 43 4
>25 41 50
>25 41 43
>98 53 33
>51 35 44
>[...]
>work/qhull> gcc -o qhull-test qhull-test.c -lqhull6
>-lm
>qhull-test.c:7:2: warning: #warning qhull6 [-Wcpp]
>work/qhull> ./qhull-test
>work/qhull>
>
>So there is any output from qhull-test when building against qhull6 in
>contrast when building against qhull5.
>
>What I am doing wrong?
>
>Background:
>https://mailman.cae.wisc.edu/pipermail/help-octave/2011-November/048583.html
>
>Thanks a lot,
>Petr
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]