geomview-users — Geomview users' discussion list

Re: [geomview-users] Fwd: Re: Fwd: Re: [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

On 07/23/18 12:52, Michele Denber wrote:
>
> Michele
>
> since gmake install is now complaining about comm.o, that suggests
> that my patch to comm.c was not the right thing to do.
>
> Some possibilities here:
> - The INET stuff expects listenOps to be defined somewhere else,
> so it's only added in comm.c for UNIX sockets. But Solaris doesn't see it?
> It's implicitly defined in a non-included header, so 
> #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS)
> #include whatever-that-header-is.h
> #endif
> at start of comm.c might work?
Unfortunately, no.  I added in comm.c:

#ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS)
#include /usr/include/sys/socket.h
#endif

and got:

cc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -I..    -g -c 
-o comm.o comm.c
comm.c:23:8: error: macro names must be identifiers
  #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS)
         ^
gmake[5]: *** [Makefile:437: comm.o] Error 1

No idea what that means.

>
>
> - configure decided on INET when it should have picked UNIX?
> So, forgetting my previous change and doing
> #def HAVE_UNIX_SOCKETS 1 
> ?
Well in config.h, HAVE_INET_SOCKETS and HAVE_INET6_SOCKETS were both 
definted to 1 but

HAVE_UNIX_SOCKETS was not.  So I deinfed UNIX and tried again.  Didn't work.

>
> What version of Solaris are you using?
Solaris 10, update 11.
> (and when did gmake
> start being the default on Slowlaris?
When Sun went out of business and stopped updating their software :-(  
Sure you can still get support from Oracle, but not being Bill Gates or 
the Sultan of Brunai, that's out of my league.
>   Whatever happened to
> Solaris Studio/CC?
Oh I have that too.  Didn't work either.
> That might have something to do with UNIX/INET confusion?)
>    uname -a
# uname -a
SunOS canadice 5.10 Generic_147147-26 sun4u sparc SUNW,SPARC-Enterprise
#

> What does configure think about your system?
>    cd geomview-1.9.5
>    ./configure>  capture.log
>
> and send capture.log as an attachment
Attached.  I've been pulling my hair out for a day now over this.  The 
undefined symbols come from libsocket.so and I do have that in 
/usr/lib/.  But for the life of me I can't get geomview to look there.  
Maybe I'm just doing something wrong so simple I can't see it.

             - Michele

Re: [geomview-users] Fwd: Re: [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Stuart L. <sa...@il...>]

Since it compiles, but common network functions bind() and accept() are
undefined, I think that means that the header files are reasonable but
there's a missing -l (dash-ell) library.   Long ago "-lnsl" was the
right thing for Solaris for network functions, but not any more apparently.

This page says that for socket functions (bind() and accept() should be
among those) one should link with the library:

    -lsocket

Can someone see where in the Makefiles  -lnsl gets specified, and
replace it with-lsocket ?

On 07/22/2018 07:52 PM, Lloyd Wood via geomview-users wrote:
> Michele
>
> since gmake install is now complaining about comm.o, that suggests
> that my patch to comm.c was not the right thing to do.
>
> Some possibilities here:
> - The INET stuff expects listenOps to be defined somewhere else,
> so it's only added in comm.c for UNIX sockets. But Solaris doesn't see it?
> It's implicitly defined in a non-included header, so 
> #ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS)
> #include whatever-that-header-is.h
> #endif
> at start of comm.c might work?
>
>
> - configure decided on INET when it should have picked UNIX?
> So, forgetting my previous change and doing
> #def HAVE_UNIX_SOCKETS 1 
> ?
>
> What version of Solaris are you using? (and when did gmake
> start being the default on Slowlaris? Whatever happened to
> Solaris Studio/CC? That might have something to do with UNIX/INET confusion?)
>   uname -a
> What does configure think about your system?
>   cd geomview-1.9.5
>   ./configure > capture.log
>
> and send capture.log as an attachment
>
> thanks and regards
>
> Lloyd Wood
> http://savi.sf.net
>
>
> On Monday, 23 July 2018, 02:49:32 GMT+10, Michele Denber <md...@gm...> wrote: 
>
>
> Thanks very much Lloyd.  Your patch worked fine and gmake has completed without error.
>
> Unfortunately, now gmake install isn't happy:
>
> ...
> gmake[5]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview/x11'
> (echo 'char builddate[] = "'"`date +%Y%m%d%H%M`"'";'; \
>  echo 'char buildinfo1[] = "'"  By `whoami`@`hostname`[`uname -s`-`uname -r`]"'";'; \
>  echo 'char buildinfo2[] = "'"  On `date`"'";'; \
> ) > buildinfo.c
> gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include   -I/usr/openwin/include -I..    -g -O2 -MT buildinfo.o -MD -MP -MF .deps/buildinfo.Tpo -c -o buildinfo.o buildinfo.c
> mv -f .deps/buildinfo.Tpo .deps/buildinfo.Po
> /bin/bash ../../../../libtool  --tag=CC   --mode=link gcc  -g -O2   -o gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o ../common/libgvcommon.a buildinfo.o ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/libgeomview.la -L/usr/openwin/lib -R/usr/openwin/lib  -lSM -lICE -lXt -lXext -lX11  -lnsl -lm
> libtool: link: gcc -g -O2 -o .libs/gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o buildinfo.o  ../common/libgvcommon.a ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/.libs/libgeomview.so -L/usr/openwin/lib -L/usr/local/lib -lGL -lGLU -lz -lSM -lICE -lXt -lXext -lX11 -lnsl -lm -R/usr/local/lib -R/usr/openwin/lib
> Undefined                       first referenced
>  symbol                             in file
> bind                                ../common/libgvcommon.a(comm.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
> accept                              ../common/libgvcommon.a(comm.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
> listen                              ../common/libgvcommon.a(comm.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
> socket                              ../common/libgvcommon.a(comm.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
> ld: fatal: symbol referencing errors. No output written to .libs/gvx
> gmake[5]: *** [Makefile:494: gvx] Error 1
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> geomview-users mailing list
> geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geomview-users

Re: [geomview-users] Fwd: Re: [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Lloyd W. <ecl...@ya...>]

Michele

since gmake install is now complaining about comm.o, that suggests
that my patch to comm.c was not the right thing to do.

Some possibilities here:
- The INET stuff expects listenOps to be defined somewhere else,
so it's only added in comm.c for UNIX sockets. But Solaris doesn't see it?
It's implicitly defined in a non-included header, so 
#ifdef (HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS)
#include whatever-that-header-is.h
#endif
at start of comm.c might work?


- configure decided on INET when it should have picked UNIX?
So, forgetting my previous change and doing
#def HAVE_UNIX_SOCKETS 1 
?

What version of Solaris are you using? (and when did gmake
start being the default on Slowlaris? Whatever happened to
Solaris Studio/CC? That might have something to do with UNIX/INET confusion?)
  uname -a
What does configure think about your system?
  cd geomview-1.9.5
  ./configure > capture.log

and send capture.log as an attachment

thanks and regards

Lloyd Wood
http://savi.sf.net


On Monday, 23 July 2018, 02:49:32 GMT+10, Michele Denber <md...@gm...> wrote: 


Thanks very much Lloyd.  Your patch worked fine and gmake has completed without error.

Unfortunately, now gmake install isn't happy:

...
gmake[5]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview/x11'
(echo 'char builddate[] = "'"`date +%Y%m%d%H%M`"'";'; \
 echo 'char buildinfo1[] = "'"  By `whoami`@`hostname`[`uname -s`-`uname -r`]"'";'; \
 echo 'char buildinfo2[] = "'"  On `date`"'";'; \
) > buildinfo.c
gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include   -I/usr/openwin/include -I..    -g -O2 -MT buildinfo.o -MD -MP -MF .deps/buildinfo.Tpo -c -o buildinfo.o buildinfo.c
mv -f .deps/buildinfo.Tpo .deps/buildinfo.Po
/bin/bash ../../../../libtool  --tag=CC   --mode=link gcc  -g -O2   -o gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o ../common/libgvcommon.a buildinfo.o ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/libgeomview.la -L/usr/openwin/lib -R/usr/openwin/lib  -lSM -lICE -lXt -lXext -lX11  -lnsl -lm
libtool: link: gcc -g -O2 -o .libs/gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o buildinfo.o  ../common/libgvcommon.a ../../../../src/lib/mib/libmib.a -lXm -lXmu ../../../../src/lib/.libs/libgeomview.so -L/usr/openwin/lib -L/usr/local/lib -lGL -lGLU -lz -lSM -lICE -lXt -lXext -lX11 -lnsl -lm -R/usr/local/lib -R/usr/openwin/lib
Undefined                       first referenced
 symbol                             in file
bind                                ../common/libgvcommon.a(comm.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
accept                              ../common/libgvcommon.a(comm.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
listen                              ../common/libgvcommon.a(comm.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
socket                              ../common/libgvcommon.a(comm.o)  (symbol belongs to implicit dependency /lib/libsocket.so.1)
ld: fatal: symbol referencing errors. No output written to .libs/gvx
gmake[5]: *** [Makefile:494: gvx] Error 1

Re: [geomview-users] Fwd: Re: [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[Michele D. <md...@gm...>]

Thanks very much Lloyd.  Your patch worked fine and gmake has completed 
without error.

Unfortunately, now gmake install isn't happy:

...
gmake[5]: Entering directory 
'/export/home/michele/geomview-1.9.5/src/bin/geomview/x11'
(echo 'char builddate[] = "'"`date +%Y%m%d%H%M`"'";'; \
  echo 'char buildinfo1[] = "'"  By `whoami`@`hostname`[`uname 
-s`-`uname -r`]"'";'; \
  echo 'char buildinfo2[] = "'"  On `date`"'";'; \
) > buildinfo.c
gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include   
-I/usr/openwin/include -I..    -g -O2 -MT buildinfo.o -MD -MP -MF 
.deps/buildinfo.Tpo -c -o buildinfo.o buildinfo.c
mv -f .deps/buildinfo.Tpo .deps/buildinfo.Po
/bin/bash ../../../../libtool  --tag=CC   --mode=link gcc  -g -O2   -o 
gvx gvappear.o gvcameras.o gvcamui.o gvcolor.o gvcommands.o gvcredits.o 
gvevent.o gvfiles.o gvlights.o gvload.o gvmain.o gvmaterial.o 
gvmnpanel.o gvsave.o gvtoolui.o gvui.o ../common/libgvcommon.a 
buildinfo.o ../../../../src/lib/mib/libmib.a -lXm -lXmu 
../../../../src/lib/libgeomview.la -L/usr/openwin/lib 
-R/usr/openwin/lib  -lSM -lICE -lXt -lXext -lX11  -lnsl -lm
libtool: link: gcc -g -O2 -o .libs/gvx gvappear.o gvcameras.o gvcamui.o 
gvcolor.o gvcommands.o gvcredits.o gvevent.o gvfiles.o gvlights.o 
gvload.o gvmain.o gvmaterial.o gvmnpanel.o gvsave.o gvtoolui.o gvui.o 
buildinfo.o  ../common/libgvcommon.a ../../../../src/lib/mib/libmib.a 
-lXm -lXmu ../../../../src/lib/.libs/libgeomview.so -L/usr/openwin/lib 
-L/usr/local/lib -lGL -lGLU -lz -lSM -lICE -lXt -lXext -lX11 -lnsl -lm 
-R/usr/local/lib -R/usr/openwin/lib
Undefined                       first referenced
  symbol                             in file
bind                                ../common/libgvcommon.a(comm.o)  
(symbol belongs to implicit dependency /lib/libsocket.so.1)
accept                              ../common/libgvcommon.a(comm.o)  
(symbol belongs to implicit dependency /lib/libsocket.so.1)
listen                              ../common/libgvcommon.a(comm.o)  
(symbol belongs to implicit dependency /lib/libsocket.so.1)
socket                              ../common/libgvcommon.a(comm.o)  
(symbol belongs to implicit dependency /lib/libsocket.so.1)
ld: fatal: symbol referencing errors. No output written to .libs/gvx
gmake[5]: *** [Makefile:494: gvx] Error 1

Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared

[<llo...@us...>]

(adding in the geomview mailing lists)

Hi Michele,

The last time I used Geomview on a Sparc it was a Sparc20 in the year 2000...
but this looks like a clear bug in Geomview to me

>From code inspection of geomview/src/bin/geomview/common/comm.c

I see that listenOps is defined in the chunk of code if you have unix sockets:
#if HAVE_UNIX_SOCKETS
   static handleOps listenOps = blah de blah
#endif

but it is referenced in three chunks of code later on:
#if HAVE_UNIX_SOCKETS
#endif
#if HAVE_INET_SOCKETS
#endif
#if HAVE_INET6_SOCKETS
#endif

and from line 1659, you're failing in the HAVE_INET_SOCKETS case, so the Solaris
networking stack has changed in the last eighteen years. But the code would
never have worked for any inet non-unix sockets anyway?

I think the fix to this is to change the initial #ifdef HAVE_UNIX_SOCKETS to

#ifdef (HAVE_UNIX_SOCKETS || HAVE_INET_SOCKETS || HAVE_INET6_SOCKETS)

so that listenOps is always defined, as shown in the attached diff; I think the
assumption here is that Geomview is still supposed to work if no networking stack is 
present without defining or running any of these (though I don't know how X works if
no networking stack is present).

But I have not been able to test this, and I'd like an opinion on this from Geomview
developers before they commit a fix to the codebase. Your feedback on whether the
attached diff works would be appreciated.

cp comm.c comm.c.backup
patch comm.c < comm-mod.diff

thanks and regards


Lloyd Wood
http://savi.sf.net


On Sunday, 22 July 2018, 05:50:05 GMT+10, Michele Denber <mic...@us...> wrote: 





I hope this is in the right place.  While building Geomview 1.9.5 on a Sun Oracle Enterprise M3000 SPARC64 VII running Solaris 10U11, opencsw toolchain, gcc 4.9.2, I ran

./configure

which completed without error.

But then gmake gave:

~~~
...
Making all in geomview
gmake[4]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview'
Making all in .
gmake[5]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview'
../../../src/lib/oogl/lisp/lisp2c -cprefix "gv_" -o clang ./common/*.c ./x11/*.cgmake[5]: Leaving directory '/export/home/michele/geomview-1.9.5/src/bin/geomview'
Making all in common
gmake[5]: Entering directory '/export/home/michele/geomview-1.9.5/src/bin/geomview/common'
gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../include -I..    -g -O2 -MT comm.o -MD -MP -MF .deps/comm.Tpo -c -o comm.o comm.c
comm.c: In function ‘usepipe’:
comm.c:1659:63: error: ‘listenOps’ undeclared (first use in this function)
      Pool *p = PoolStreamOpen(pipename, fdopen(s, "rb"), 0, &listenOps);
                                                              ^
comm.c:1659:63: note: each undeclared identifier is reported only once for each function it appears in
gmake[5]: *** [Makefile:435: comm.o] Error 1
gmake[5]: Leaving directory '/export/home/michele/geomview-1.9.5/src/bin/geomview/common'
gmake[4]: *** [Makefile:483: all-recursive] Error 1
gmake[4]: Leaving directory '/export/home/michele/geomview-1.9.5/src/bin/geomview'
gmake[3]: *** [Makefile:406: all-recursive] Error 1
gmake[3]: Leaving directory '/export/home/michele/geomview-1.9.5/src/bin'
gmake[2]: *** [Makefile:473: all-recursive] Error 1
gmake[2]: Leaving directory '/export/home/michele/geomview-1.9.5/src'
gmake[1]: *** [Makefile:540: all-recursive] Error 1
gmake[1]: Leaving directory '/export/home/michele/geomview-1.9.5'
gmake: *** [Makefile:429: all] Error 2
~~~






---

[Solaris 10 build fails with error: ‘listenOps’ undeclared](https://sourceforge.net/p/geomview/discussion/134473/thread/ee3c4a35/?limit=25#1f08)


---

Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/geomview/discussion/134473/>



To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>

Re: [geomview-users] Difficulty loading swrast driver

[Snedden, A. <Ali...@na...>]

Thank you for the information.  I will give this a try.  Even simply running glxinfo fails with the same error.


From: Lloyd Wood <llo...@ya...<mailto:llo...@ya...>>
Reply-To: Lloyd Wood <llo...@ya...<mailto:llo...@ya...>>
Date: Friday, March 23, 2018 at 1:51 AM
To: Mark Phillips <mb...@ge...<mailto:mb...@ge...>>, Snedden Ali <Ali...@na...<mailto:Ali...@na...>>
Cc: "geo...@li...<mailto:geo...@li...>" <geo...@li...<mailto:geo...@li...>>
Subject: Re: [geomview-users] Difficulty loading swrast driver

[WARNING: External Email - Use Caution]


libGL error: failed to load driver: swrast



often appears related to mesa conflicting with nvidia drivers, which have to be reinstalled every time a kernel update is done. And it's a GL problem; Geomview just uses OpenGL.
See e.g.

https://www.centos.org/forums/viewtopic.php?t=56273<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centos.org_forums_viewtopic.php-3Ft-3D56273&d=DwMFaQ&c=FGzDrZ8hK6OoO1oc9Smc5l64O0n3B5aByDFzrvN9KLI&r=sYzXEOLE0nIGb8FZXZ4rzqcWzLgnZJS81SxbG89PYGcR31pru1BY9l2GBCwPyFaz&m=x8aY3SpsQ2DanPBWZH3MWvVQCyfETelmQBj4lRTrzHI&s=VEZozrSVjV_TIbYWsX7xEtJoqOQkkuC7digUStQVU_4&e=>
https://bugzilla.redhat.com/show_bug.cgi?id=1093323<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1093323&d=DwMFaQ&c=FGzDrZ8hK6OoO1oc9Smc5l64O0n3B5aByDFzrvN9KLI&r=sYzXEOLE0nIGb8FZXZ4rzqcWzLgnZJS81SxbG89PYGcR31pru1BY9l2GBCwPyFaz&m=x8aY3SpsQ2DanPBWZH3MWvVQCyfETelmQBj4lRTrzHI&s=0AZb29lC7P9xwH6whwnY-lbV4RfIO829hWxulLbQUos&e=>

and try

> rpm -e mesa-libGL.i686 --nodeps
> rpm -e mesa-libGL.x86_64 --nodeps


Geomview tends to live slightly better on Debian/Ubuntu; I've always found CentOS to be a lot of configuration work.


Lloyd Wood
http://savi.sf.net/<https://urldefense.proofpoint.com/v2/url?u=http-3A__savi.sf.net_&d=DwMFaQ&c=FGzDrZ8hK6OoO1oc9Smc5l64O0n3B5aByDFzrvN9KLI&r=sYzXEOLE0nIGb8FZXZ4rzqcWzLgnZJS81SxbG89PYGcR31pru1BY9l2GBCwPyFaz&m=x8aY3SpsQ2DanPBWZH3MWvVQCyfETelmQBj4lRTrzHI&s=8UxcKlgmIz_ou-5DcuALW8Do_7ly8R662ZZrZx9xF6U&e=>


________________________________

From: Mark Phillips <mb...@ge...<mailto:mb...@ge...>>
To: "Snedden, Ali" <Ali...@na...<mailto:Ali...@na...>>
Cc: "geo...@li...<mailto:geo...@li...>" <geo...@li...<mailto:geo...@li...>>
Sent: Friday, 23 March 2018, 0:30
Subject: Re: [geomview-users] Difficulty loading swrast driver



This is just a wild guess but I wonder if the error has something to do with your video drivers.  Have you been able to run any other programs that use GL?  Maybe try updating your video drivers?


On Thu, Mar 22, 2018 at 8:41 AM, Snedden, Ali <Ali...@na...<mailto:Ali...@na...>> wrote:

I am working on a CentOS 6.6 cluster and trying to get Geomview to work.  It appeared to install without error.
>
>
>From the tutorial :
>
>
>qmaster02: ~$ geomview tetra dodec
>libGL error: failed to load driver: swrast
>X Error of failed request:  BadValue (integer parameter out of range for operation)
>  Major opcode of failed request:  149 (GLX)
>  Minor opcode of failed request:  3 (X_GLXCreateContext)
>  Value in failed request:  0x0
>  Serial number of failed request:  1224
>  Current serial number in output stream:  1227
>
>
>Ok, so I figured maybe there is a problem in the shared library:
>
>
>qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/ libgeomview.so
>linux-vdso.so.1 =>  (0x00007fff897c9000)
>libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000)
>libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000)
>libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000)
>libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000)
>libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000)
>libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000)
>libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000)
>libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000)
>libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000)
>libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000)
>libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000)
>libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000)
>libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000)
>libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000)
>libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000)
>libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000)
>libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000)
>libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000)
>libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000)
>libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000)
>libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000)
>libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000)
>libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++ .so.6 (0x00002b732251d000)
>libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s. so.1 (0x00002b732282f000)
>libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000)
>/lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000)
>libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000)
>librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000)
>
>
>It appears that all the libraries are found.  I also  looked at
>
>
>ldd /opt/geomview-1.9.5/libexec/ geomview/gvx
>ldd /opt/geomview-1.9.5/libexec/ geomview/nose
>
>
>and it appears that there aren’t any missing libraries.  I also looked at the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any missing libraries.
>
>
>Question : How do I solve this error?
>
>
>
>
>Thanks,
>Ali

Re: [geomview-users] Difficulty loading swrast driver

[Lloyd W. <llo...@ya...>]

libGL error: failed to load driver: swrast



often appears related to mesa conflicting with nvidia drivers, which have to be reinstalled every time a kernel update is done. And it's a GL problem; Geomview just uses OpenGL.
See e.g.

https://www.centos.org/forums/viewtopic.php?t=56273
https://bugzilla.redhat.com/show_bug.cgi?id=1093323

and try

> rpm -e mesa-libGL.i686 --nodeps 
> rpm -e mesa-libGL.x86_64 --nodeps


Geomview tends to live slightly better on Debian/Ubuntu; I've always found CentOS to be a lot of configuration work.
 

Lloyd Wood
http://savi.sf.net/


________________________________
From: Mark Phillips <mb...@ge...>
To: "Snedden, Ali" <Ali...@na...> 
Cc: "geo...@li..." <geo...@li...>
Sent: Friday, 23 March 2018, 0:30
Subject: Re: [geomview-users] Difficulty loading swrast driver



This is just a wild guess but I wonder if the error has something to do with your video drivers.  Have you been able to run any other programs that use GL?  Maybe try updating your video drivers?


On Thu, Mar 22, 2018 at 8:41 AM, Snedden, Ali <Ali...@na...> wrote:

I am working on a CentOS 6.6 cluster and trying to get Geomview to work.  It appeared to install without error.
>
>
>From the tutorial : 
>
>
>qmaster02: ~$ geomview tetra dodec
>libGL error: failed to load driver: swrast
>X Error of failed request:  BadValue (integer parameter out of range for operation)
>  Major opcode of failed request:  149 (GLX)
>  Minor opcode of failed request:  3 (X_GLXCreateContext)
>  Value in failed request:  0x0
>  Serial number of failed request:  1224
>  Current serial number in output stream:  1227
>
>
>Ok, so I figured maybe there is a problem in the shared library:
>
>
>qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/ libgeomview.so 
>linux-vdso.so.1 =>  (0x00007fff897c9000)
>libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000)
>libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000)
>libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000)
>libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000)
>libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000)
>libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000)
>libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000)
>libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000)
>libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000)
>libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000)
>libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000)
>libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000)
>libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000)
>libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000)
>libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000)
>libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000)
>libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000)
>libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000)
>libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000)
>libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000)
>libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000)
>libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000)
>libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++ .so.6 (0x00002b732251d000)
>libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s. so.1 (0x00002b732282f000)
>libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000)
>/lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000)
>libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000)
>librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000)
>
>
>It appears that all the libraries are found.  I also  looked at 
>
>
>ldd /opt/geomview-1.9.5/libexec/ geomview/gvx 
>ldd /opt/geomview-1.9.5/libexec/ geomview/nose
>
>
>and it appears that there aren’t any missing libraries.  I also looked at the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any missing libraries.
>
>
>Question : How do I solve this error?
>
>
>
>
>Thanks, 
>Ali

   

Re: [geomview-users] Difficulty loading swrast driver

[Mark P. <mb...@ge...>]

This is just a wild guess but I wonder if the error has something to do
with your video drivers.  Have you been able to run any other programs that
use GL?  Maybe try updating your video drivers?

On Thu, Mar 22, 2018 at 8:41 AM, Snedden, Ali <
Ali...@na...> wrote:

> I am working on a CentOS 6.6 cluster and trying to get Geomview to work.
> It appeared to install without error.
>
> From the tutorial :
>
> qmaster02: ~$ geomview tetra dodec
>
> libGL error: failed to load driver: swrast
>
> X Error of failed request:  BadValue (integer parameter out of range for
> operation)
>
>   Major opcode of failed request:  149 (GLX)
>
>   Minor opcode of failed request:  3 (X_GLXCreateContext)
>
>   Value in failed request:  0x0
>
>   Serial number of failed request:  1224
>
>   Current serial number in output stream:  1227
>
> Ok, so I figured maybe there is a problem in the shared library:
>
> qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/libgeomview.so
>
> linux-vdso.so.1 =>  (0x00007fff897c9000)
>
> libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000)
>
> libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000)
>
> libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000)
>
> libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000)
>
> libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000)
>
> libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000)
>
> libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000)
>
> libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000)
>
> libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000)
>
> libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000)
>
> libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000)
>
> libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000)
>
> libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000)
>
> libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000)
>
> libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000)
>
> libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000)
>
> libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000)
>
> libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000)
>
> libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000)
>
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000)
>
> libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000)
>
> libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000)
>
> libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++.so.6 (0x00002b732251d000)
>
> libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s.so.1 (0x00002b732282f000)
>
> libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000)
>
> /lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000)
>
> libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000)
>
> librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000)
>
> It appears that all the libraries are found.  I also  looked at
>
> ldd /opt/geomview-1.9.5/libexec/geomview/gvx
>
> ldd /opt/geomview-1.9.5/libexec/geomview/nose
>
>
> and it appears that there aren’t any missing libraries.  I also looked at
> the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any
> missing libraries.
>
> Question : How do I solve this error?
>
>
> Thanks,
> Ali
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> geomview-users mailing list
> geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geomview-users
>
>

Re: [geomview-users] Difficulty loading swrast driver

[Snedden, A. <Ali...@na...>]

I also looked at the libGL libraries themselves and it appears that all the libraries are still found
E.g.


qmaster02: ~$ ldd /usr/lib64/libGL.so.1

linux-vdso.so.1 =>  (0x00007fff43bef000)

libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002ade209f0000)

libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002ade20c18000)

libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002ade20e2a000)

libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002ade2102c000)

libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002ade21232000)

libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002ade21433000)

libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002ade21770000)

libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002ade21987000)

libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002ade21b8b000)

libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002ade21da9000)

libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002ade21faf000)

libm.so.6 => /lib64/libm.so.6 (0x00002ade221ba000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ade2243e000)

libdl.so.2 => /lib64/libdl.so.2 (0x00002ade2265c000)

libselinux.so.1 => /lib64/libselinux.so.1 (0x00002ade22860000)

libc.so.6 => /lib64/libc.so.6 (0x00002ade22a7f000)

libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002ade22e14000)

librt.so.1 => /lib64/librt.so.1 (0x00002ade23017000)

/lib64/ld-linux-x86-64.so.2 (0x00002ade20547000)


Thanks,
Ali

From: Snedden Ali <Ali...@na...<mailto:Ali...@na...>>
Date: Thursday, March 22, 2018 at 8:41 AM
To: "geo...@li...<mailto:geo...@li...>" <geo...@li...<mailto:geo...@li...>>
Subject: Difficulty loading swrast driver

I am working on a CentOS 6.6 cluster and trying to get Geomview to work.  It appeared to install without error.

From the tutorial :


qmaster02: ~$ geomview tetra dodec

libGL error: failed to load driver: swrast

X Error of failed request:  BadValue (integer parameter out of range for operation)

  Major opcode of failed request:  149 (GLX)

  Minor opcode of failed request:  3 (X_GLXCreateContext)

  Value in failed request:  0x0

  Serial number of failed request:  1224

  Current serial number in output stream:  1227

Ok, so I figured maybe there is a problem in the shared library:


qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/libgeomview.so

linux-vdso.so.1 =>  (0x00007fff897c9000)

libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000)

libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000)

libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000)

libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000)

libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000)

libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000)

libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000)

libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000)

libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000)

libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000)

libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000)

libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000)

libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000)

libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000)

libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000)

libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000)

libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000)

libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000)

libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000)

libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000)

libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000)

libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++.so.6 (0x00002b732251d000)

libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s.so.1 (0x00002b732282f000)

libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000)

/lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000)

libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000)

librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000)

It appears that all the libraries are found.  I also  looked at


ldd /opt/geomview-1.9.5/libexec/geomview/gvx

ldd /opt/geomview-1.9.5/libexec/geomview/nose


and it appears that there aren’t any missing libraries.  I also looked at the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any missing libraries.

Question : How do I solve this error?


Thanks,
Ali

[geomview-users] Difficulty loading swrast driver

[Snedden, A. <Ali...@na...>]

I am working on a CentOS 6.6 cluster and trying to get Geomview to work.  It appeared to install without error.

From the tutorial :


qmaster02: ~$ geomview tetra dodec

libGL error: failed to load driver: swrast

X Error of failed request:  BadValue (integer parameter out of range for operation)

  Major opcode of failed request:  149 (GLX)

  Minor opcode of failed request:  3 (X_GLXCreateContext)

  Value in failed request:  0x0

  Serial number of failed request:  1224

  Current serial number in output stream:  1227

Ok, so I figured maybe there is a problem in the shared library:


qmaster02: ~$ ldd /opt/geomview-1.9.5/lib/libgeomview.so

linux-vdso.so.1 =>  (0x00007fff897c9000)

libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b731f375000)

libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b731f5d9000)

libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b731f859000)

libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b731fa61000)

libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b731fc7e000)

libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b731fee3000)

libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b73200f5000)

libz.so.1 => /lib64/libz.so.1 (0x00002b7320433000)

libm.so.6 => /lib64/libm.so.6 (0x00002b7320649000)

libc.so.6 => /lib64/libc.so.6 (0x00002b73208cd000)

libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00002b7320c62000)

libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00002b7320e89000)

libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002b732108b000)

libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00002b7321291000)

libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00002b7321492000)

libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00002b73216a8000)

libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002b73218ad000)

libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00002b7321acb000)

libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00002b7321cd0000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7321edc000)

libdl.so.2 => /lib64/libdl.so.2 (0x00002b73220f9000)

libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b73222fd000)

libstdc++.so.6 => /act/gcc-4.9.2/lib64/libstdc++.so.6 (0x00002b732251d000)

libgcc_s.so.1 => /act/gcc-4.9.2/lib64/libgcc_s.so.1 (0x00002b732282f000)

libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b7322a45000)

/lib64/ld-linux-x86-64.so.2 (0x00002b731ecf5000)

libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b7322c4a000)

librt.so.1 => /lib64/librt.so.1 (0x00002b7322e4d000)

It appears that all the libraries are found.  I also  looked at


ldd /opt/geomview-1.9.5/libexec/geomview/gvx

ldd /opt/geomview-1.9.5/libexec/geomview/nose


and it appears that there aren’t any missing libraries.  I also looked at the dynamic executables in /opt/geomview-1.9.5/bin and didn’t notice any missing libraries.

Question : How do I solve this error?


Thanks,
Ali

Re: [geomview-users] writing a correct geom file

[Lloyd W. <llo...@ya...>]

Charlie, 

Okay, stupid layman question here.

Don't qhull and CGAL do delaunay and convex hull calculations? 

https://academic.oup.com/bib/article/15/1/54/187726

"Several libraries have been established to calculate Delaunay triangulation and alpha shape such as the Qhull [16] and the Computational Geometry Algorithm Library (CGAL) [17]. Qhull is developed by Barber et al. based on the Quickhull algorithm which offers a programmable library to compute the convex hull, Delaunay triangulation and Voronoi diagram. CGAL is an open source project which aims to provide efficient and reliable geometric algorithms. Compared with Qhull, CGAL offers a wider range of geometric computation including polygons, convex hull, Delaunay triangulation, Voronoi diagram, alpha shape and mesh generation."

http://www.qhull.org
Qhull talks to geomview directly - see links.

https://doc.cgal.org/latest/Manual/index.html

or you can use PyDeT on PyMol, I suppose...
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2478735/
I'm a bit unclear on how much of the wheel you need to reinvent here, or whether leveraging the tools above could save you a lot of time.
 

Lloyd Wood
http://savi.sf.net


________________________________
From: "Carter, Charlie" <ca...@me...>
To: "geo...@li..." <geo...@li...> 
Sent: Saturday, 16 December 2017, 18:10
Subject: [geomview-users] writing a correct geom file



Hello out there. I’m not even sure that this list serve still functions. Nonetheless, I’m pretty desperately seeking some way into the club.


For many years, I had software developed by a former student to evaluate delaunay tessellations and convex hulls for 3D data sets derived from protein crystal structures. I am a Mac user and with the advent of OSX El Capitan (OSX 10.11.6), that executable no longer functioned, and I’m trying to re-build its functionality using Octave. The trouble I have is that there is no way to visualize what I’m generating using any of the octave commands. Inline plot commands (trisurf) create a plot and then hang; that is apparently a recurrent problem from discussions on the web.


I’ve installed geomview hoping to use it instead. However, although I can view any of the examples provided with the installation, I cannot determine how to configure the output files from octave so that they can be recognized by geomview or how to configure convex hull output from Octave into geoms or ool files.. 


Are there any examples or tutorials out there to help? I used to think that although I am not a programmer,  I was pretty savvy with software, but that period was long ago. I have not kept up with anything since Fortran!


Any assistance would be much appreciated.



Charlie Carter

Professor of Biochemistry and Biophysics

UNC Chapel Hill

Re: [geomview-users] writing a correct geom file

[Adrian R. <ad...@an...>]

Hi Charlie

On Sat, 16 Dec 2017, Carter, Charlie wrote:
> I’ve installed geomview hoping to use it instead. However, although I 
> can view any of the examples provided with the installation, I cannot 
> determine how to configure the output files from octave so that they can 
> be recognized by geomview or how to configure convex hull output from 
> Octave into geoms or ool files..

Maybe this link is useful

    https://alexbjorkholm.wordpress.com/2016/10/07/exporting-3d-objects-from-octave/

There is sample code for converting to wavefront OBJ format, which
you may be able to pipe through the Antiprism obj2off program
(possibly within Octave if that is more convenient)

    http://www.antiprism.com/programs/obj2off.html

The resulting OFF can be viewed in Geomview.

If it is of interest, for your visualisation, the Antiprism Antiview
program is able to detect the symmetry of your models and display
the symmetry elements

    http://www.antiprism.com/programs/antiview.html

Adrian.
-- 
Adrian Rossiter
ad...@an...
http://antiprism.com/adrian

[geomview-users] writing a correct geom file

[Carter, C. <ca...@me...>]

Hello out there. I’m not even sure that this list serve still functions. Nonetheless, I’m pretty desperately seeking some way into the club.

For many years, I had software developed by a former student to evaluate delaunay tessellations and convex hulls for 3D data sets derived from protein crystal structures. I am a Mac user and with the advent of OSX El Capitan (OSX 10.11.6), that executable no longer functioned, and I’m trying to re-build its functionality using Octave. The trouble I have is that there is no way to visualize what I’m generating using any of the octave commands. Inline plot commands (trisurf) create a plot and then hang; that is apparently a recurrent problem from discussions on the web.

I’ve installed geomview hoping to use it instead. However, although I can view any of the examples provided with the installation, I cannot determine how to configure the output files from octave so that they can be recognized by geomview or how to configure convex hull output from Octave into geoms or ool files.. 

Are there any examples or tutorials out there to help? I used to think that although I am not a programmer,  I was pretty savvy with software, but that period was long ago. I have not kept up with anything since Fortran!

Any assistance would be much appreciated.


Charlie Carter
Professor of Biochemistry and Biophysics
UNC Chapel Hill

[geomview-users] Antiprism 0.25.1 Released

[Adrian R. <ad...@an...>]

Hi All

Antiprism 0.25.1 polyhedron modelling software has been released

    https://groups.google.com/d/topic/antiprism/tmFpO_ctj1Y/discussion

The programs all work natively with OFF.

The new 'wythoff' program (and also 'conway') will lay out repeating
polygonal tiling patterns on arbitrary surfaces, e.g.

    https://groups.google.com/d/msg/geodesichelp/Hr_QJbKx2CI/Nu36-UBdBAAJ

Adrian.
-- 
Adrian Rossiter
ad...@an...
http://antiprism.com/adrian

Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017

[Lloyd W. <llo...@ya...>]

As Sourceforge CVS stops allowing commits and goes read-only for some indefinite time, I've made copies
of everything we have in CVS as tarballs under
http://www.geomview.org/dev

(This also buys more time for cvs2svn conversion, which is a nice idea in theory, but which I can't make work.)

cheers 
Lloyd Wood
http://savi.sf.net 



________________________________
From: Lloyd Wood <llo...@ya...>
To: Lloyd Wood <llo...@ya...>; Steve Robbins <st...@su...>; "geo...@li..." <geo...@li...> 
Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...>
Sent: Wednesday, 8 November 2017, 7:42
Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017



While saying that github can host active geomview development,
there's a bunch of other dormant little things in geomview cvs - 
maniview, orrery, gv1-modules, the fabled gv2.

sourceforge isn't guaranteeing the longevity of read-only
cvs, so worth also copying everything over to svn via e.g. a cvs2svn
import for longevity/archival?

thanks


Lloyd Wood
http://savi.sf.net/


________________________________
From: Lloyd Wood via geomview-users <geo...@li...>
To: Claus-Justus Heine <hi...@cl...>; Steve Robbins <st...@su...>; "geo...@li..." <geo...@li...> 
Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...>
Sent: Monday, 9 October 2017, 14:38
Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017



Okay, it looks like Mark bringing

https://github.com/geomview

up to date, then sticking a note in the sourceforge CVS that github
is where any current development is at, and my then
updating various geomview webpage pointers would be
the approach to take.

thanks

Lloyd Wood
http://savi.sf.net


________________________________

From: Claus-Justus Heine <hi...@cl...>
To: Steve Robbins <st...@su...>; geo...@li...; Lloyd Wood <llo...@ya...> 
Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...>
Sent: Monday, 9 October 2017, 14:20
Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017



Sorry, being buried in my every day's job activities I will not be able
to help much, unfortunately. For practical reasons I would vote for
github if I had a vote.

Kind thanks for your efforts to keep Geomview alive!

Claus


Am 09.10.2017 um 05:13 schrieb Steve Robbins:
> On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote:
> 
>> thoughts on the approach to take?
> 
> I'm fine with whatever the committers decide -- they are the biggest user of 
> the source control system.  
> 
> If I had a vote, however, I'd place mine on git.  Probably github.  The main 
> reason is that I think SVN will similarly die out at some point.  For 
> instance, Debian's forge (alioth) is being replaced and will likely only 
> support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/
> VCS
> 
> -Steve
> 

-- 
Claus-Justus Heine                      hi...@cl...
http://www.claus-justus-heine.de/

Schatzmeister der Camerata Academica Freiburg e.V.  ---  www.cafev.de

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
geomview-users mailing list

geo...@li...
https://lists.sourceforge.net/lists/listinfo/geomview-users

Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017

[Lloyd W. <llo...@ya...>]

While saying that github can host active geomview development,
there's a bunch of other dormant little things in geomview cvs - 
maniview, orrery, gv1-modules, the fabled gv2.

sourceforge isn't guaranteeing the longevity of read-only
cvs, so worth also copying everything over to svn via e.g. a cvs2svn
import for longevity/archival?

thanks
 

Lloyd Wood
http://savi.sf.net/


________________________________
From: Lloyd Wood via geomview-users <geo...@li...>
To: Claus-Justus Heine <hi...@cl...>; Steve Robbins <st...@su...>; "geo...@li..." <geo...@li...> 
Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...>
Sent: Monday, 9 October 2017, 14:38
Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017



Okay, it looks like Mark bringing

https://github.com/geomview

up to date, then sticking a note in the sourceforge CVS that github
is where any current development is at, and my then
updating various geomview webpage pointers would be
the approach to take.

thanks

Lloyd Wood
http://savi.sf.net


________________________________

From: Claus-Justus Heine <hi...@cl...>
To: Steve Robbins <st...@su...>; geo...@li...; Lloyd Wood <llo...@ya...> 
Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...>
Sent: Monday, 9 October 2017, 14:20
Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017



Sorry, being buried in my every day's job activities I will not be able
to help much, unfortunately. For practical reasons I would vote for
github if I had a vote.

Kind thanks for your efforts to keep Geomview alive!

Claus


Am 09.10.2017 um 05:13 schrieb Steve Robbins:
> On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote:
> 
>> thoughts on the approach to take?
> 
> I'm fine with whatever the committers decide -- they are the biggest user of 
> the source control system.  
> 
> If I had a vote, however, I'd place mine on git.  Probably github.  The main 
> reason is that I think SVN will similarly die out at some point.  For 
> instance, Debian's forge (alioth) is being replaced and will likely only 
> support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/
> VCS
> 
> -Steve
> 

-- 
Claus-Justus Heine                      hi...@cl...
http://www.claus-justus-heine.de/

Schatzmeister der Camerata Academica Freiburg e.V.  ---  www.cafev.de

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
geomview-users mailing list
geo...@li...
https://lists.sourceforge.net/lists/listinfo/geomview-users

Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017

[Claus-Justus H. <hi...@cl...>]

Sorry, being buried in my every day's job activities I will not be able
to help much, unfortunately. For practical reasons I would vote for
github if I had a vote.

Kind thanks for your efforts to keep Geomview alive!

Claus

Am 09.10.2017 um 05:13 schrieb Steve Robbins:
> On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote:
> 
>> thoughts on the approach to take?
> 
> I'm fine with whatever the committers decide -- they are the biggest user of 
> the source control system.  
> 
> If I had a vote, however, I'd place mine on git.  Probably github.  The main 
> reason is that I think SVN will similarly die out at some point.  For 
> instance, Debian's forge (alioth) is being replaced and will likely only 
> support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/
> VCS
> 
> -Steve
> 

-- 
Claus-Justus Heine                      hi...@cl...
http://www.claus-justus-heine.de/

Schatzmeister der Camerata Academica Freiburg e.V.  ---  www.cafev.de

Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017

[Lloyd W. <llo...@ya...>]

Okay, it looks like Mark bringing

https://github.com/geomview

up to date, then sticking a note in the sourceforge CVS that github
is where any current development is at, and my then
updating various geomview webpage pointers would be
the approach to take.

thanks

Lloyd Wood
http://savi.sf.net


________________________________
From: Claus-Justus Heine <hi...@cl...>
To: Steve Robbins <st...@su...>; geo...@li...; Lloyd Wood <llo...@ya...> 
Cc: "geo...@li..." <geo...@li...>; Mark Phillips <mb...@ge...>
Sent: Monday, 9 October 2017, 14:20
Subject: Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017



Sorry, being buried in my every day's job activities I will not be able
to help much, unfortunately. For practical reasons I would vote for
github if I had a vote.

Kind thanks for your efforts to keep Geomview alive!

Claus


Am 09.10.2017 um 05:13 schrieb Steve Robbins:
> On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote:
> 
>> thoughts on the approach to take?
> 
> I'm fine with whatever the committers decide -- they are the biggest user of 
> the source control system.  
> 
> If I had a vote, however, I'd place mine on git.  Probably github.  The main 
> reason is that I think SVN will similarly die out at some point.  For 
> instance, Debian's forge (alioth) is being replaced and will likely only 
> support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/
> VCS
> 
> -Steve
> 

-- 
Claus-Justus Heine                      hi...@cl...
http://www.claus-justus-heine.de/

Schatzmeister der Camerata Academica Freiburg e.V.  ---  www.cafev.de

Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017

[Steve R. <st...@su...>]

On Sunday, October 8, 2017 4:42:33 AM CDT Lloyd Wood via geomview-users wrote:

> thoughts on the approach to take?

I'm fine with whatever the committers decide -- they are the biggest user of 
the source control system.  

If I had a vote, however, I'd place mine on git.  Probably github.  The main 
reason is that I think SVN will similarly die out at some point.  For 
instance, Debian's forge (alioth) is being replaced and will likely only 
support git; see https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/
VCS

-Steve

Re: [geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017

[Larry P. <lp...@co...>]

On Sun, 8 Oct 2017 04:42:33 +0000 (UTC)
Lloyd Wood via geomview-users <geo...@li...> wrote:

> 
> thoughts on the approach to take?
> 

As long as it would be possible to download a tarball then it
should make no difference.

I am not sure, but with git only the source tree can be downloaded
while github allows the tree to be packaged into a tarball.

Also, does this mean the end of versioned releases?

[geomview-users] Sourceforge cvs support for geomview ending 30 Nov 2017

[Lloyd W. <llo...@ya...>]

We've had a long 17-year run out of cvs in SourceForge, but it's now reached end of life, and cvs clients are getting as rare as telnet clients in distros these days (e.g. not in current Mac OS X Xcode). So, geomview has to migrate to a new primary repository, per the SourceForge note below.

Mark was playing with github, and could bring that up to date:

https://github.com/geomview

which is one possibility, as are git on Sourceforge, mercurial on sourceforge -- or even svn on sourceforge, which I'll be looking at migrating SaVi to (as I'm pretty much the only developer there, and mercurial and git are complex configuration overkill for that project and this user. if you're capable of building the development geomview autoconf toolchain, git probably won't cause you too many difficulties.)

thoughts on the approach to take?

thanks, 

Lloyd Wood
http://savi.sf.net 
----- Forwarded Message -----
From: SourceForge Support <cvs...@so...>
Sent: Sunday, 8 October 2017, 3:22
Subject: CVS support at SourceForge and Nov. 30



Greetings project admin,


We have been planning to discontinue CVS support here at SourceForge for several years now, and that time has finally arrived. Since your project is making use of CVS for your source version control, you should now convert your repository over to another version control system.


The current plan is to stop allowing CVS commits by November 30th. To be able to continue making source code changes you’ll need to have your CVS repo converted by then. The ssh access method will stop working, but read-only access via both pserver, rsync, and interactive shell will continue to be available past the cutoff date (we haven’t determined if or when the read-only support will end). This means that you will have plenty of time to convert your data to a new SCM format, even well past the cutoff date.


If you don’t have a particular SCM choice in mind, we recommend choosing Subversion (SVN) since it has a workflow that is most similar to that of CVS. You might also want to choose Git, which is very popular these days, though it does have a steeper learning curve compared to switching to Subversion. You can even give each one a try and keep the one you like best. Don’t be afraid to experiment.


For information on how to convert your repository from CVS to SVN or Git, visit the following web page: https://sourceforge.net/p/forge/documentation/CVS/


The page also documents the rsync backup method.


We hope that your conversion goes smoothly. You can let us know if you run into any issues by replying to this email.


Sincerely,


SourceForge Support

Re: [geomview-users] Geomview on Cygwin

[Lloyd W. <llo...@ya...>]

Ken,

thanks for this. Despite reading John's webpage, I completely
missed PyDSTool, because his link went to a broken cgi. "Huh,"
I thought, "it's a webcgi, and student webtools in university
accounts never last. Must be a dead end."

Didn't think to google on pydstool - http://dstool.sf.net is something else.
John could have mentioned it when I asked him about
DsTool 64-bittiness, though!

http://pydstool.sourceforge.net/ redirects to wherever the
support webpages are (though the server for
http://www.ni.gsu.edu/~rclewley/PyDSTool/FrontPage.htmlwent offline yesterday.)

I guess DsTool (Tkv3) would still be unique in its Geomview animations,
but researchwise that's not that attractive or current. (Kind
of like, in my area of networking research, still using ISI's ns2
when ns3 is where a lot of the research community is at, despite
ns3 missing a number of things making ns2 attractive)

regards

Lloyd Wood
http://savi.sf.net


________________________________
From: Ken Brown <kb...@co...>
To: Lloyd Wood <llo...@ya...>; "geo...@li..." <geo...@li...>; Ananya Mondal <am1...@ii...> 
Sent: Tuesday, 27 June 2017, 5:31
Subject: Re: [geomview-users] Geomview on Cygwin



On 6/22/2017 9:17 AM, Lloyd Wood wrote:> - Cornell's DsTool - some notes at:
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/DsTool/
> on where DsTool is at.
> DsTool can run under 32-bit Cygwin with Tcl 8.5, but would need
> some attention to bring it up to date for 64-bit and/or Tcl 8.6.
> And a make install. (Disclaimer: it's a forerunner/compatriot of
> SaVi, tested out a lot of Tk interface code in SaVi.
> I'm quite biased.)

I've taken a look at DsTool and decided not to pursue it, for two reasons:

1. It is apparently not being developed any longer, so there is no one 
around who would update it for Tcl 8.6 and for 64-bit platforms (unless 
someone on this list is interested enough to do it).  I don't want to 
spend time on a Cygwin package that can only be used on 32-bit Cygwin 
with a downgraded Tcl installation.

2. According to http://www.math.cornell.edu/~gucken/software.html, 
development efforts have shifted to a python version of DsTool:

  http://www.ni.gsu.edu/~rclewley/PyDSTool/index.html
  http://www.ni.gsu.edu/~rclewley/PyDSTool/FrontPage.html
  https://github.com/robclewley/pydstool
  https://sourceforge.net/projects/pydstool/
  https://pypi.python.org/pypi/PyDSTool

It had a release two years ago, a commit to its GitHub repo one year 
ago, and discussion on its Sourceforge forum a few hours ago.  It can 
export curves to a Geomview data file.  I would hope that this meets the 
needs of DsTool users.


Ken

Re: [geomview-users] Geomview on Cygwin

[Ken B. <kb...@co...>]

On 6/22/2017 9:17 AM, Lloyd Wood wrote:> - Cornell's DsTool - some notes at:
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/DsTool/
> on where DsTool is at.
> DsTool can run under 32-bit Cygwin with Tcl 8.5, but would need
> some attention to bring it up to date for 64-bit and/or Tcl 8.6.
> And a make install. (Disclaimer: it's a forerunner/compatriot of
> SaVi, tested out a lot of Tk interface code in SaVi.
> I'm quite biased.)

I've taken a look at DsTool and decided not to pursue it, for two reasons:

1. It is apparently not being developed any longer, so there is no one 
around who would update it for Tcl 8.6 and for 64-bit platforms (unless 
someone on this list is interested enough to do it).  I don't want to 
spend time on a Cygwin package that can only be used on 32-bit Cygwin 
with a downgraded Tcl installation.

2. According to http://www.math.cornell.edu/~gucken/software.html, 
development efforts have shifted to a python version of DsTool:

   http://www.ni.gsu.edu/~rclewley/PyDSTool/index.html
   http://www.ni.gsu.edu/~rclewley/PyDSTool/FrontPage.html
   https://github.com/robclewley/pydstool
   https://sourceforge.net/projects/pydstool/
   https://pypi.python.org/pypi/PyDSTool

It had a release two years ago, a commit to its GitHub repo one year 
ago, and discussion on its Sourceforge forum a few hours ago.  It can 
export curves to a Geomview data file.  I would hope that this meets the 
needs of DsTool users.

Ken

Re: [geomview-users] Geomview on Cygwin

[Ken B. <kb...@co...>]

On 6/22/2017 9:17 AM, Lloyd Wood wrote:> Other than the 
previously-with-Geomview modules Ken mentions,
> and the Geometry Center's Orrery, there are two modules
> that could also be packaged for Cygwin, as they also run
> separately standalone and can be useful by themselves when
> not controlling Geomview:
> 
> - SaVi http://savi.sourceforge.net/ - needs a make install though
> (disclaimer: I try to maintain this. I'm quite biased about it.)

Hi Lloyd,

I've just added this one (to my personal Cygwin repository).  Please 
give it a try when you get a chance and let me know if it seems OK.  I 
suggest that you also download the source and look at the patches I 
used.  You might want to incorporate some version of a couple of them, 
especially the update for the current zlib.  (But I was lazy; a proper 
fix would condition the change on the zlib version.)

Ken

Re: [geomview-users] Geomview on Cygwin

[Lloyd W. <llo...@ya...>]

Thanks, Ken!

Here's the official Cygwin announcement of Ken's
Geomview 1.9.5 package:
https://cygwin.com/ml/cygwin/2017-06/msg00258.html

and the attached screenshot shows the packages in the
gui of the Cygwin installer. Ken got Geomview working well
on both 32-bit and 64-bit Cygwin.

On Geomview modules - a month back I refreshed the list of
third-party modules to see what was still out there:
http://www.geomview.org/thirdparty/
fixing broken links etc.

Other than the previously-with-Geomview modules Ken mentions,
and the Geometry Center's Orrery, there are two modules
that could also be packaged for Cygwin, as they also run
separately standalone and can be useful by themselves when
not controlling Geomview:

- SaVi http://savi.sourceforge.net/ - needs a make install though
(disclaimer: I try to maintain this. I'm quite biased about it.)

- Cornell's DsTool - some notes at:
http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/DsTool/
on where DsTool is at.
DsTool can run under 32-bit Cygwin with Tcl 8.5, but would need
some attention to bring it up to date for 64-bit and/or Tcl 8.6.
And a make install. (Disclaimer: it's a forerunner/compatriot of
SaVi, tested out a lot of Tk interface code in SaVi.
I'm quite biased.)

There are a bunch of other modules that used to be packaged
with much older versions of Geomview as demonstrations; they're
listed in the old FAQ at:

http://www.geomview.org/FAQ/answers.shtml
"What modules are shipped for which platforms with the current release?"

but I've got no idea where they're at. (I always had a soft
spot for gvclock as the most complex on-screen clock I
could find. xclock has nothing on it...)

I"ve no clue about crayola or labeler

thanks and regards, 
Lloyd Wood llo...@ya... http://about.me/lloydwood 

________________________________
From: Ken Brown <kb...@co...>
To: geo...@li... 
Sent: Thursday, 22 June 2017, 2:10
Subject: [geomview-users] Geomview on Cygwin



I have recently added geomview-1.9.5 to the Cygwin distribution.  I have 

also built (but not added to the distro) all the emodule packages 

mentioned in the README in the geomview source tarball:


* gvemod-cplxview

* gvemod-crayola

* gvemod-labeler

* gvemod-ndview

* gvemod-xforms-example

* gvemodules-xforms

* maniview


If anyone wants to try these, they can be obtained via Cygwin's setup 

program from my personal Cygwin repository:


  http://sanibeltranquility.com/cygwin/


There are instructions at that site.  Note: I have other packages there 

that you probably don't want to install, so be careful to just choose 

the emodule package(s) that you want (and let setup install any 

dependencies).


Most of the emodules seem to work OK, in the sense that something 

reasonable happens when I click on them in the emodule list.  (I'm not a 

geomview user, so I can't really test them properly.)  But there are a 

few glitches:


1. Clicking on "Crayola" yields the following error message in the 

terminal from which I started geomview:


Error in startup script: invalid command name "Ïúíþ`"

     while executing

"Ïúíþ`   H__PAGEZERO..."

     (file "/usr/libexec/geomview/tcl/Crayola" line 1)


This is due to the fact that /usr/libexec/geomview/tcl/Crayola is a 

binary file, not a Tcl script:


$ file /usr/libexec/geomview/tcl/Crayola

/usr/libexec/geomview/tcl/Crayola: Mach-O 64-bit x86_64 executable, 

flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>


2. The same thing happens with "Labeler".


3. Clicking on "NDdemo" yields


   sh: /usr/libexec/geomview/nddemo: No such file or directory


And indeed the gvemod-ndview sources do not contain a source file for 

nddemo or a Makefile rule for building it.


I assume all of these glitches are problems with the packaging of the 

emodules, but please let me know if there's something I can fix in my 

builds.


Ken