[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
>
>
- Re: qhull6 and octave,
Brad Barber <=
- Re: qhull6 and octave, Petr Gajdos, 2011/11/22
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: qhull6 and octave, Brad Barber, 2011/11/30