Schlegel diagrams using jreality

[madd]

Hi,

Having undertaken the mild adventure that is installing polymake 2.11 from source on MacOS X 10.6 (i386), I've come across some slightly unusual behaviour, that I think may be a bug.

If I build the truncated icosahedron from the tutorial page and then attempt to visualise it:
$trunc_icosahedron -> VISUAL;
it all works fine, the jreality window comes up as expected and displays the soccer ball, which I can manipulate to my heart's content.

However, if I wish to view the corresponding Schlegel diagram:
$trunc_icosahedron -> SCHLEGEL; or
$trunc_icosahedron -> SCHLEGEL_DIAGRAM -> VISUAL;
then, "de.tuberlin.polymake.common.SelectorThread" appears briefly in my menu bar and disappears, leaving no error message.

I'd really appreciate being able to take advantage of the prettier output in jreality. So firstly, is this a bug? Secondly, how can I help find the problem?

Regards,
Matt

[gawrilow]

It must be a Mac-specific problem, this function works under Linux smoothly, so that I unfortunately can't help you directly. To get more insight, please try running polymake with -d switch. You'll see a lot of internal communication garbage, but hopefully some relevant diagnostics will also pop up. If you find anything promising, please post it here.

[madd]

The tail of the debug output seems indicative...
VISUAL works:

$trunc_icosahedron -> VISUAL;

Code: Select all

java: selecting controlPipe... jv->pm: n 2 sent. controlPipe...done java: selecting initing gl com.sun.opengl.impl.GLImpl@4e8c2f76

SCHLEGEL fails:

$trunc_icosahedron -> SCHLEGEL;

Code: Select all

java: selecting controlPipe... jv->client: read Schlegel diagram of trunc_icosahedron on facet 0 sent. controlPipe...done java: selecting clientChannel... Exception in thread "SelectorThread" java.lang.NegativeArraySizeException at de.tuberlin.polymake.common.geometry.PointSet.resize(Unknown Source) at de.tuberlin.polymake.common.geometry.PointSet.readFromSMM(Unknown Source) at de.tuberlin.polymake.common.io.SimpleGeometryParser.parse(Unknown Source) at de.tuberlin.polymake.polytope.PolymakeSchlegelControl.update(Unknown Source) at de.tuberlin.polymake.common.SelectorThread.run(Unknown Source)

Regards,
Matt

[paffenholz]

I currently can't reproduce the error on my Mac (but with a 64bit version). One thing you could try is to recompile the java part of polymake using

Code: Select all

make all-java

[madd]

make all-java Arch=i386 proceeds without incident, however, linking then fails with a series of:

Code: Select all

ld: warning: in ../perlx-5.12.3-darwin-multi-2level/Customize.o, file was built for unsupported file format which is not the architecture being linked (i386)

OK. Clearly a problem.

I did read the warning in the FAQ that only the 64 bit version was tested, but starting from a clean install of fink with 64 bit selected yields:

Code: Select all

polymake-2.11 me$ ./configure WARNING: perl module XML::LibXML required for polymake seems to be unusable. An attempt to load it has failed because of the following: Can't load '/sw/lib/perl5/5.10.0/darwin-thread-multi-2level/auto/XML/LibXML/LibXML.bundle' for module XML::LibXML: dlopen(/sw/lib/perl5/5.10.0/darwin-thread-multi-2level/auto/XML/LibXML/LibXML.bundle, 1): no suitable image found. Did find: /sw/lib/perl5/5.10.0/darwin-thread-multi-2level/auto/XML/LibXML/LibXML.bundle: mach-o, but wrong architecture Please be sure to rectify the problem prior to starting to use polymake. WARNING: perl module XML::LibXSLT required for polymake seems to be unusable. An attempt to load it has failed because of the following: Attempt to reload XML/LibXML.pm aborted. Compilation failed in require Please be sure to rectify the problem prior to starting to use polymake. WARNING: perl module Term::ReadLine::Gnu required for polymake seems to be unusable. An attempt to load it has failed because of the following: Cannot do `initialize' in Term::ReadLine::Gnu Please be sure to rectify the problem prior to starting to use polymake. Configuration goes on, nevertheless.

Why would configure guess wrong and what should I be telling it?

Regards,
Matt

[paffenholz]

I would be rather surprised if building on i386 does not work, although I didn't test it.

But apparently Customize.o is x86_64, so somehow the arch-flag didn't make it to the appropriate gcc-command, or was wrongly set. Are other files compiled correctly (e.g. the *bundle files in <POLYROOT>/build*/lib/ ? You can check this with the command "lipo -info <file>").

I assume that your fink version is the same as for the i386-build of polymake? Then it's i386 itself, and configure has no chance to find something appropriate. You would have to create a new version of fink (you can pass a different installation directory as an option to bootstrap, if you want to keep the other).

configure should be clever enough to guess the approriate architecture for its own build from the one of fink, so basically it should not be necessary to pass an arch-flag at all. But maybe that got messed up, I'll check.

[madd]

So I have two clean installs of fink: /sw32 and /sw64. I make the appropriate one /sw before running configure.

Adding a print statement to line 371 of support/configure.pl tells me that $Platform is x86_64
and

Code: Select all

$ lipo -info /sw/lib/perl5/5.10.0/darwin-thread-multi-2level/auto/XML/LibXML/LibXML.bundle Non-fat file: /sw/lib/perl5/5.10.0/darwin-thread-multi-2level/auto/XML/LibXML/LibXML.bundle is architecture: x86_64

Which is baffling.

Returning to the i386 build, all files in <POLYROOT>/build*/lib/ seem to be compiled correctly (i386). I think I found the problem though:

Code: Select all

$ find . -name "Customize.o" ./build.darwin.i386/perlx-5.10.0-darwin-thread-multi-2level/Customize.o ./build.darwin.i386/perlx-5.12.3-darwin-multi-2level/Customize.o

The first is i386, the second is x86_64.

Regards,
Matt