Menu
▾
▴
geomview-devel — Geomview Developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(2) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lloyd W. <llo...@ya...> - 2018-08-02 00:50:36
|
The manual is available from http://www.geomview.org/docs/ We moved building the manual to last because it seemed silly to break a working link and final build just because everything halted on a TeX problem earlier - and debugging other people's TeX installs is really difficult. Are there any tweaks for portability that can be made to improve Geomview as a result of this experience? I have no idea... Lloyd Wood http://savi.sf.net/ the idea companion to a new Geomview install ________________________________ From: Michele Denber <md...@gm...> To: Stuart Levy <sa...@il...> Cc: "geo...@li..." <geo...@li...>; "geo...@li..." <geo...@li...> Sent: Thursday, 2 August 2018, 2:05 Subject: Re: [geomview-users] [geomview:discussion] Solaris 10 build fails with error: ‘listenOps’ undeclared Well I was getting a slew of errors like: ... Loading texinfo [version 2013-02-01.11]: pdf, fonts, markup, glyphs, page headings, tables, conditionals, indexing, sectioning, toc, environments, defuns, macros, cross references, insertions, localization, formatting, and turning on texinfo input format.) (./geomview.aux) (/export/home/denber/geomview-1.9.5/doc/version.texi) [1{/opt/csw/share/texmf/f onts/map/pdftex/updmap/pdftex.map}] (Introduction to Geomview) [1] (Distribution) [2] (Copying) [3] (GNU LESSER PUBLIC LICENSE) [4] [5] [6] [7] [8] [9] [10] [11] [12] (History of Geomview's Development) [13] (Supported Platforms) [14] (How to Pronounce ``Geomview``) [15] Chapter 1 [16] Chapter 2 [17] /export/home/denber/geomview-1.9.5/doc/./geomview.texi:890: epsf.tex not found, images will be ignored. @image ...f.tex not found, images will be ignored} @global @warnednoepsftrue ... l.890 @image{figs/initial} [18] [19] Chapter 3 [20] [21] Underfull \hbox (badness 10000) in paragraph at lines 1189--1192 @texttt -Mcs fred[]@textrm Read com-mands from the UNIX-domain socket named. ... from gmake but that all looks like a texinfo problem, not geomview. So I just ignored them and did a gmake install anyway. That seems to have created entries in /usr/local/lib and /usr/local/bin for geomview so I'm guessing that in the end it worked, modulo the documentation (which doesn't matter too much to me). So thank you very much for all your help getting this installed. - Michele ------------------------------------------------------------------------------ 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 |
|
From: <llo...@ya...> - 2018-07-25 02:45:47
|
Michele typo on my part, sorry; the #ifdef () should just be an #if (), since we're testing values, not if a name has been defined. Will likely still fail for a different reason, though. Okay, attached is the bit of your configure output we care about, relating to socket use. the autoconf configure script detects that passing -lsocket as a flag to the linker is needed, so that should be somewhere. but since this is now autoconf generated, it's messy. If you edit the configure script that generates the makefile, and search for socket, you will see that it already looks for sys/socket.h - could try changing that to #include </usr/include/sys/socket.h> and rerunning? Stuart points out that Solaris used to use -nsl instead of -lsocket. So you could try adding that too as a flag to where the linker is invoked before making - though I suspect this old flag might be supported by Solaris CC and not gcc? The Oracle Solaris 11.3 docs we've looked at on http://docs.oracle.com suggest that dynamic linking to libsocket.so should suffice - but surely one of the flags should do that? hope this helps Lloyd Wood http://savi.sf.net On Wednesday, 25 July 2018, 02:53:49 GMT+10, Michele Denber <md...@gm...> wrote: 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 |
|
From: <llo...@ya...> - 2018-07-22 03:05:15
|
(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/> |
|
From: Lloyd W. <llo...@ya...> - 2017-11-24 05:45:53
|
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 |
|
From: Lloyd W. <llo...@ya...> - 2017-11-07 20:42:30
|
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 |
|
From: Claus-Justus H. <hi...@cl...> - 2017-10-09 03:46:04
|
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 |
|
From: Lloyd W. <llo...@ya...> - 2017-10-09 03:38:08
|
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 |
|
From: Lloyd W. <llo...@ya...> - 2017-10-08 04:42:44
|
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 |
|
From: Michele D. <de...@mi...> - 2015-06-20 20:58:32
|
On a Solaris 10 Sparc box, the command "./configure" gives the errors
below for v. 1.9.5 using gcc 4.9.2. I looked for this on the web
without success. Any help would be most appreciated. Thanks.
# more config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by geomview configure 1.9.5, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ ./configure
## --------- ##
## Platform. ##
## --------- ##
hostname = xxxxxx
uname -m = sun4u
uname -r = 5.10
uname -s = SunOS
uname -v = Generic_147147-26
/usr/bin/uname -p = sparc
/bin/uname -X = System = SunOS
Node = xxxxxx
Release = 5.10
KernelID = Generic_147147-26
Machine = sun4u
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 2
/bin/arch = sun4
/usr/bin/arch -k = sun4u
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /opt/csw/bin
PATH: /usr/xpg4/bin/sh
PATH: /usr/jdk/jdk1.8.0_25
PATH: /opt/csw/gnu
PATH: /usr/bin
PATH: /usr/sbin
PATH: /usr/X11/bin
PATH: /usr/openwin/bin
PATH: /usr/sfw/bin
PATH: /usr/ucb
PATH: /usr/local/lib
PATH: /usr/local/bin
PATH: /usr/ccs/bin
PATH: /usr/local/share
PATH: .
## ----------- ##
## Core tests. ##
## ----------- ##
configure:2793: result: configuring geomview 1.9.5
configure:2828: checking build system type
configure:2842: result: sparc-sun-solaris2.10
configure:2862: checking host system type
configure:2875: result: sparc-sun-solaris2.10
configure:2895: checking target system type
configure:2908: result: sparc-sun-solaris2.10
configure:2950: checking for a BSD-compatible install
configure:3018: result: /opt/csw/bin/ginstall -c
configure:3029: checking whether build environment is sane
configure:3084: result: yes
configure:3235: checking for a thread-safe mkdir -p
configure:3274: result: /opt/csw/bin/gmkdir -p
configure:3281: checking for gawk
configure:3297: found /opt/csw/bin/gawk
configure:3308: result: gawk
configure:3319: checking whether make sets $(MAKE)
configure:3341: result: yes
configure:3370: checking whether make supports nested variables
configure:3387: result: yes
configure:3513: checking whether to enable maintainer-specific portions
of Makefiles
configure:3522: result: no
configure:3637: checking for g++
configure:3653: found /opt/csw/bin/g++
configure:3664: result: g++
configure:3691: checking for C++ compiler version
configure:3700: g++ --version >&5
g++ (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:3711: $? = 0
configure:3700: g++ -v >&5
Reading specs from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/specs
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/sparc-sun-solaris2.10/4.9.2/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with:
/home/dam/mgar/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.9.2/configure
--prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin
--sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec
--datadir=/opt/csw/share --sysconfdir=/etc/opt/csw
--sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw
--libdir=/opt/csw/lib --infodir=/opt/csw/share/info
--includedir=/opt/csw/include --mandir=/opt/csw/share/man
--enable-cloog-backend=isl --enable-java-awt=xlib
--enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada
--enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix
--program-suffix=-4.9 --with-cloog=/opt/csw --with-gmp=/opt/csw
--with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw
--with-system-zlib=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-as
Thread model: posix
gcc version 4.9.2 (GCC)
configure:3711: $? = 0
configure:3700: g++ -V >&5
g++: error: unrecognized command line option '-V'
g++: fatal error: no input files
compilation terminated.
configure:3711: $? = 1
configure:3700: g++ -qversion >&5
g++: error: unrecognized command line option '-qversion'
g++: fatal error: no input files
compilation terminated.
configure:3711: $? = 1
configure:3731: checking whether the C++ compiler works
configure:3753: g++ -L/opt/csw/lib conftest.cpp >&5
configure:3757: $? = 0
configure:3805: result: yes
configure:3808: checking for C++ compiler default output file name
configure:3810: result: a.out
configure:3816: checking for suffix of executables
configure:3823: g++ -o conftest -L/opt/csw/lib conftest.cpp >&5
configure:3827: $? = 0
configure:3849: result:
configure:3871: checking whether we are cross compiling
configure:3879: g++ -o conftest -L/opt/csw/lib conftest.cpp >&5
configure:3883: $? = 0
configure:3890: ./conftest
configure:3894: $? = 0
configure:3909: result: no
configure:3914: checking for suffix of object files
configure:3936: g++ -c conftest.cpp >&5
configure:3940: $? = 0
configure:3961: result: o
configure:3965: checking whether we are using the GNU C++ compiler
configure:3984: g++ -c conftest.cpp >&5
configure:3984: $? = 0
configure:3993: result: yes
configure:4002: checking whether g++ accepts -g
configure:4022: g++ -c -g conftest.cpp >&5
configure:4022: $? = 0
configure:4063: result: yes
configure:4097: checking for style of include used by make
configure:4125: result: GNU
configure:4151: checking dependency style of g++
configure:4262: result: gcc3
configure:4340: checking for gcc
configure:4356: found /opt/csw/bin/gcc
configure:4367: result: gcc
configure:4596: checking for C compiler version
configure:4605: gcc --version >&5
gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:4616: $? = 0
configure:4605: gcc -v >&5
Reading specs from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.9.2/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/sparc-sun-solaris2.10/4.9.2/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with:
/home/dam/mgar/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.9.2/configure
--prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin
--sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec
--datadir=/opt/csw/share --sysconfdir=/etc/opt/csw
--sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw
--libdir=/opt/csw/lib --infodir=/opt/csw/share/info
--includedir=/opt/csw/include --mandir=/opt/csw/share/man
--enable-cloog-backend=isl --enable-java-awt=xlib
--enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada
--enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix
--program-suffix=-4.9 --with-cloog=/opt/csw --with-gmp=/opt/csw
--with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw
--with-system-zlib=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-as
Thread model: posix
gcc version 4.9.2 (GCC)
configure:4616: $? = 0
configure:4605: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:4616: $? = 1
configure:4605: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:4616: $? = 1
configure:4620: checking whether we are using the GNU C compiler
configure:4639: gcc -c conftest.c >&5
configure:4639: $? = 0
configure:4648: result: yes
configure:4657: checking whether gcc accepts -g
configure:4677: gcc -c -g conftest.c >&5
configure:4677: $? = 0
configure:4718: result: yes
configure:4735: checking for gcc option to accept ISO C89
configure:4798: gcc -c -g -O2 conftest.c >&5
configure:4798: $? = 0
configure:4811: result: none needed
configure:4836: checking whether gcc understands -c and -o together
configure:4858: gcc -c conftest.c -o conftest2.o
configure:4861: $? = 0
configure:4858: gcc -c conftest.c -o conftest2.o
configure:4861: $? = 0
configure:4873: result: yes
configure:4892: checking dependency style of gcc
configure:5003: result: gcc3
configure:5028: checking for ISO C99 features with "gcc -g -O2"
configure:5044: gcc -c -g -O2 conftest.c >&5
configure:5044: $? = 0
configure:5046: result: variadic macros and variable length arrays are
available
configure:5071: checking for gawk
configure:5098: result: gawk
configure:5115: checking how to run the C preprocessor
configure:5146: gcc -E conftest.c
configure:5146: $? = 0
configure:5160: gcc -E conftest.c
conftest.c:12:28: fatal error: ac_nonexistent.h: No such file or directory
#include <ac_nonexistent.h>
^
compilation terminated.
configure:5160: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "geomview"
| #define PACKAGE_TARNAME "geomview"
| #define PACKAGE_VERSION "1.9.5"
| #define PACKAGE_STRING "geomview 1.9.5"
| #define PACKAGE_BUGREPORT "Claus-Justus Heine
<Cla...@IA...>"
| #define PACKAGE_URL ""
| #define PACKAGE "geomview"
| #define VERSION "1.9.5"
| #define HAVE_ISO_C99 1
| /* end confdefs.h. */
| #include <ac_nonexistent.h>
configure:5185: result: gcc -E
configure:5205: gcc -E conftest.c
configure:5205: $? = 0
configure:5219: gcc -E conftest.c
conftest.c:12:28: fatal error: ac_nonexistent.h: No such file or directory
#include <ac_nonexistent.h>
^
compilation terminated.
configure:5219: $? = 1
configure: failed program was:
| /* confdefs.h */
|
|
From: <l....@su...> - 2014-03-16 05:04:08
|
headsup below if anyone is on the developers list but not subscribed to users, worth subscribing to that as well. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Wood L Dr (Electronic Eng) Sent: 13 March 2014 07:29 To: geo...@li... Subject: Geomview 1.9.5 released Just a heads-up to the geomview-users list - Claus-Justus Heine has released geomview 1.9.5, which brings together his work since 2007 that was in the repository. http://sourceforge.net/p/geomview/news/2014/03/geomview-195-released/ http://sourceforge.net/projects/geomview/files/geomview/1.9.5/ at bottom Haven't played with Geomview 1.9.5 yet, and I will need to update webpages, freshmeat etc. Please try it out and see how you go. Thanks, CJ! Lloyd Wood http://savi.sf.net/ ** Well, after years one more release. This release has two "parts": as of 2007/2008 I have added major changes to the builtin Lisp-interpreter, adding true defuns and lambda-expression and some other in-principle-need-to-be-there-lisp-stuff as of today, this is a naive maintenance release, making sure that the stuff still compiles (Gentoo Linux, OSX, I do not care about winzig-weich) Both together manifest the current state of the software; also, occasionally at least I still need Geomview for myself, and partly for university courses. So at least for me it was a long over-due task to give the current state of Geomview a name. The name is "1.9.5". |
|
From: Jorge B. de A. <fic...@gm...> - 2013-02-10 13:14:45
|
I made some changes in FAQ and need to a description to finish the tables in pages 9 and 10: http://sourceforge.net/projects/geometriaptbr/files/FAQ.dvi/download If someone can put this description here it is good. Thanks. -- Data Estelar 2456331,086863 http://sites.google.com/site/ficmatinf Desejo-lhe Paz, Vida Longa e Prosperidade. São Bem Vindas Mensagens no Formato texto UTF-8 com Acentos. |
|
From: <l....@su...> - 2013-01-27 06:48:09
|
Antiprism, the Stagehand package (and SaVi, for that matter) are still (relatively) actively maintained by their authors, but are outside the Geomview distribution. Other Geomview modules like Orrery and Clock are included with Geomview, but not necessarily built, because they have extra dependencies. I believe the FAQ is well out of date, and hasn't been overhauled in years. Lloyd Wood http://savi.sf.net/ ________________________________________ From: Jorge Barros de Abreu [fic...@gm...] Sent: 26 January 2013 19:43 To: geo...@li... Subject: [Geomview-devel] FAQ Hi for all. I need update the FAQ. Can someone verify the FAQ in http://www.geomview.org/FAQ/ ???? On the FAQ there is a list of geomview modules. ?Is all modules on this list read to use??? ?Is all modules on this list still maintained??? My doubt is related to tables with "MODULE DESCRIPTION" first line. For instance, on "our" geomview there is: Animator Antiprism models CenterStage Clipboard Clock Draw Boundary Nose Orrery StageHand StageManager StageStills In the lista above only stagetools is in the faq description. Thanks -- Data Estelar 2456317,444178 http://sites.google.com/site/ficmatinf Desejo-lhe Paz, Vida Longa e Prosperidade. São Bem Vindas Mensagens no Formato texto UTF-8 com Acentos. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Geomview-devel mailing list Geo...@li... https://lists.sourceforge.net/lists/listinfo/geomview-devel |
|
From: Jorge B. de A. <fic...@gm...> - 2013-01-26 22:15:14
|
The original files FAQ.html and a ported file FAQ.tex are in: http://sourceforge.net/projects/geometriaptbr/files/?source=navbar -- Data Estelar 2456317,461493 http://sites.google.com/site/ficmatinf Desejo-lhe Paz, Vida Longa e Prosperidade. São Bem Vindas Mensagens no Formato texto UTF-8 com Acentos. |
|
From: Jorge B. de A. <fic...@gm...> - 2013-01-26 21:51:58
|
Hi for all. I need update the FAQ. Can someone verify the FAQ in http://www.geomview.org/FAQ/ ???? On the FAQ there is a list of geomview modules. ?Is all modules on this list read to use??? ?Is all modules on this list still maintained??? My doubt is related to tables with "MODULE DESCRIPTION" first line. For instance, on "our" geomview there is: Animator Antiprism models CenterStage Clipboard Clock Draw Boundary Nose Orrery StageHand StageManager StageStills In the lista above only stagetools is in the faq description. Thanks -- Data Estelar 2456317,444178 http://sites.google.com/site/ficmatinf Desejo-lhe Paz, Vida Longa e Prosperidade. São Bem Vindas Mensagens no Formato texto UTF-8 com Acentos. |
|
From: <l....@su...> - 2013-01-25 22:55:53
|
The FAQ is just a set of webpages. It might be possible to check the webpages into the repository, and then serve them from the repository, as I do for the SaVi instructions: http://savi.cvs.sourceforge.net/*checkout*/savi/savi-dev/manual/index.html which would make checking in modifications easier. Lloyd Wood http://savi.sf.net/ ________________________________________ From: Jorge Barros de Abreu [fic...@gm...] Sent: 25 January 2013 18:43 To: geo...@li... Subject: [Geomview-devel] FAQ Hi. Is there a FAQ source code? http://www.geomview.org/FAQ/ Thanks. -- Data Estelar 2456316,403484 http://sites.google.com/site/ficmatinf Desejo-lhe Paz, Vida Longa e Prosperidade. São Bem Vindas Mensagens no Formato texto UTF-8 com Acentos. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Geomview-devel mailing list Geo...@li... https://lists.sourceforge.net/lists/listinfo/geomview-devel |
|
From: Jorge B. de A. <fic...@gm...> - 2013-01-25 20:51:37
|
Hi. Is there a FAQ source code? http://www.geomview.org/FAQ/ Thanks. -- Data Estelar 2456316,403484 http://sites.google.com/site/ficmatinf Desejo-lhe Paz, Vida Longa e Prosperidade. São Bem Vindas Mensagens no Formato texto UTF-8 com Acentos. |
|
From: Jorge B. de A. <fic...@gm...> - 2010-07-18 20:21:55
|
Hi. I will be to update manual pt_BR translation. Thanks -- Data Estelar 2455396,347419 http://sites.google.com/site/ficmatinf Desejo-lhe Paz, Vida Longa e Prosperidade. São Bem Vindas Mensagens no Formato texto UTF-8 com Acentos. |
|
From: Francesco P. <fr...@fi...> - 2009-08-19 14:44:32
|
Hi all, the following issue has been raised more than once on the geomview-users list, but failed to reach a resolution. I was suggested (thanks, Frank Peters) to direct these types of questions to the geomview-devel list, hence here I am! ;-) geomview-devel list readers may want to read the full Debian bug report (with replies) at: http://bugs.debian.org/357445 A patch was proposed by Steve M. Robbins (maintainer of Geomview Debian package): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357445#57 or http://sourceforge.net/mailarchive/forum.php?thread_name=20061228053548.GA19891%40sumost.ca&forum_name=geomview-users if you prefer the geomview-users list archives. This patch was criticized because it lacked back-compatibility: http://bugs.debian.org/357445#62 I proposed a back-compatible amendment: http://bugs.debian.org/357445#67 or http://sourceforge.net/mailarchive/forum.php?thread_name=20070908103751.7aa450a8.frx%40firenze.linux.it&forum_name=geomview-users Unfortunately, my proposal was received with a deafening silence... :-( Is there any chance to see this modification accepted in the official Geomview distribution? Please, do not forget to Cc: <35...@bu...> on replies. Thanks in advance. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 |
|
From: Jorge B. de A. <fic...@so...> - 2007-07-12 13:33:52
|
Hi. I will be to translate geomview font documentation for brazilian portuguese. The geomview compilation under slackware 11 with previous xforms instalatio= n=20 is ok. Thanks. =2D-=20 Data Estelar 2454293,877315 http://usr.solar.com.br/~ficmatin Desejo-lhe Paz, Vida Longa e Prosperidade. S=E3o Bem Vindas Mensagens no Formato Texto Gen=E9rico com Acentos. |
|
From: Lloyd W. <L....@su...> - 2006-06-25 21:21:28
|
At Saturday 24/06/2006 22:16 +0200, Claus-Justus Heine wrote: >There are indeed some bugs in the build-system; some dependencies >are wrong; also: the >wa.yacc.c stuff is slightly out of date and will not work with >recent flex/bison >combinations. Also, geomview.texi needed some polishing to work with >recent texinfo >releases. Also, the building of the documentation needs the >psfree.fig TeX style-file, >which has a licence incompatible with the GPL and so cannot be >packed with Geomview. > >I think I have fixed that stuff. BTW, writing Makefiles etc., that >is not black magic. If >I can do that, then others can do it, too. my comment was only that reconf was black magic (because it was unique to Geomview yet undocumented within Geomview -- and leads to somewhat unpredictable output!). I've attempted to improve the documentation files in the top level of CVS to discuss reconf (both pre- and post- your recent rewriting of reconf.) >However, I have prepared a new Geomview "distro". I have labeled it >geomview-1.8.2-beta >The tar-achives can be found at > >http://www.mathematik.uni-freiburg.de/IAM/homepages/claus/geomview-1.8.2-beta.tar.gz >http://www.mathematik.uni-freiburg.de/IAM/homepages/claus/geomview-1.8.2-beta.tar.bz2 This can indeed be compiled, at least on Cygwin -- many thanks for that. (I had to install a Cygwin-base snapshot to get around src/bin/animate/glob.c presuming d_ino is always supported, when it's optional under POSIX. I've updated http://www.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/building-under-Windows/ with instructions for installing cygwin snapshots. Also, compilation success is only when not installing xforms first. The xforms make process seems to generate many errors.) However, when using this with any verison of SaVi, this Geomview 1.8.2 beta throws a problem with drawing a simple sphere; SaVi still works, but the user can't see the Earth sphere that is central to SaVi. The error comes from SphereCreate in Geomview's src/lib/gprim/sphere/spherecreate.c (which uses va_args in interesting ways, I see...) This downwards trends in drawing simple spheres concerns me -- in 1.8.1 drawing simple spheres and texturemapping worked fine, in the 1.8.2 "alpha", drawing simple spheres works but turning on texturemapping leads to an invisible texturemapped sphere, so I'd have to use 1.8.1 to get screenshots of texturemapping, and now with this 1.8.2 beta there's no sphere at all, even without texturemapping! (You can turn off 'Central Body' in SaVi's Rendering menu to view a ghost continents outline I deliberately included to support spherical/hyperbolic space views, but that's all the Earth you'll see. No spheres, no texturemaps.) I haven't tried the Orrery, but imagine it will be similiarly affected. I should add that compiling this beta is only successful is when first doing configure -with-motif=/usr/X11R6 -with-opengl=/usr/X11R6 I attempted to see if this was an opengl-only problem by make clean, then configure -with-motif=/usr/X11R6 then make. This produced an initial error: make[5]: Entering directory `/home/lloyd/geomview-1.8.2-beta/src/lib/mg/opengl' if gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -I/usr/local/Geomview -I../../../. ./include -g -O2 -MT mgopengl.o -MD -MP -MF ".deps/mgopengl.Tpo" -c -o mgope ngl.o mgopengl.c; \ then mv -f ".deps/mgopengl.Tpo" ".deps/mgopengl.Po"; else rm -f ".deps/mgopengl. Tpo"; exit 1; fi In file included from mgopengl.c:32: mgopenglP.h:33:21: GL/glx.h: No such file or directory In file included from mgopengl.c:32: mgopenglP.h:82: error: parse error before "GLXContext" [..] suggesting that this Geomview beta can't actually be built without OpenGL. now, here's that Sphere error: $ cd /home/lloyd/geomview-1.8.2-beta lwood@lwood-wxp01 /home/lloyd/geomview-1.8.2-beta $ ./geomview -run ../savi-dev/savi [2] 4864 lwood@lwood-wxp01 /home/lloyd/geomview-1.8.2-beta $ SphereCreate: Undefined option: 2279636 "read geometry" in "../savi-dev/oogl/earth_vect_h.oogl": error reading geometry's: > appearance {shading smooth material {diffuse 0.2 0.4 1} } > SPHERE 1.0 --------------^ > 0.0 0.0 0.0 (the linefeed in the above doesn't matter, and the same error occurs without it -- oogl is freeform.) Fiddling with SaVi's oogl doesn't help, e.g. $ SphereCreate: Undefined option: 2279636 "read geometry" in "../savi-dev/oogl/earth_vect_h.oogl": error reading geometry's: > > (read geometry { define unit_sphere_h { > SPHERE 1 0 0 0 --------------^ > appearance {shading smooth material {diffuse 0.2 0.4 1} } and the pipe problems are still present with large LIST objects on cygwin, of course: SaVi: loaded data/iridium-66.tcl changed coverage angle from 0.0 to 8.2. Error reading "[1]../savi-dev/savi ": can't seek back far enough (on pipe?): > ... transform { 0.340785 0 0 0 0 0.340785 0 0 0 0 0.182152 0 0 0 0 1 } geom: cone_h } } ) -----^ "read geometry" in "[1]../savi-dev/savi ": error reading geometry's: > ... transform { 0.340785 0 0 0 0 0.340785 0 0 0 0 0.182152 0 0 0 0 1 } geom: cone_h } } ) -----^ gv_ready: error, got char: (-1) crashing SaVi as before. This sphere drawing problem does not appear to my eyes to be a configure/make-related problem, so I've skipped including the logs of configure/make here. Requiring opengl does, however, appear to be a make/configure problem, and more... so, not ready for prime time, I think. thanks, L. oh well, back to 1.8.1 to admire my dynamic texturemapping in SaVi. http://savi.sf.net/ > The reason >is that I have included the documentation, pdf, info and html, into >the tar-files. Don't >bother me if you cannot access those files, if so, then some server >is down. I have >checked the links for typos and tried that they work and are >accessible from the outside. > >I was using the following programs to build the stuff: > >gcc-4.1.1 >autoconf-2.59 >automake-1.9.6 >texinfo-4.8 (makeinfo stuff) >bison-2.1 >flex-2.5.33 >pdftex, pstoepsi, epstopdf, convert >openmotif-2.2.3, a recent xorg-x11 system, xforms-1.0.90 > >For the compilation only the following _should_ be needed: > >- C-compiler/binutils >- X-libraries, Motif-libs, xforms-libs (optional) > >In particular, the autoconf stuff should not be needed, bison/flex >should not be needed, >"make" should not try to regenerate the documentation. > >The tar-balls were created with "make dist", I was able to run "make >distcheck" >successfully (this means that the tarballs could be successfully >extracted, it was >possible to do a VPATH build with the extracted sources, it was >possible to run "make >dist" again, the combination of "make install" and "make uninstall" >did not leave any >traces on the system (with the exception of empty directories), >"make distclean" did not >leave any files in the build-directory). > >I was able to compile and run this version (i.e. the sources >extracted from the tarballs) >of Geomview on the following systems: > >- Desktop AMD X86_64, Linux 2.6.16, Gentoo distro >- Laptop Intel Pentium M, Linux 2.6.16.1, Gentoo distro >- Desktop Intel P4 (at work), > >Please test the stuff; if it works -- basically -- then we should >label it 1.8.2 and move >it to the sourceforge download area. NOTE: I did not change the >source code, just some >small changes to the build-system, i.e. the wa.yacc.c stuff should >be resolved etc. Most >of my "efforts" went into "porting" the TeXInfo documentation such >that recent texinfo >release can eat it. > >In comparision with the "alpha" snapshot: the most remarkable >difference _should_ be that >it is possible to use this beast, at least on Linux (X86 and >X86_64). At least I am able >to use it there ;) > >Two year ago or so I have change the oogl2vrml program to output >VRML2, otherwise there >are no new features compared to the "alpha" tar-ball. > >If you test it and feel inclined to report bugs: > >POINT ZERO: FIRST TRY TO FIX THE STUFF YOURSELF. If that should not >work out after >spending a day or so: > >- include the output of "configure" >- include "config.log" >- include all the output of the "make command" you used to compile the stuff >- include information about the program versions used for building >the stuff (i.e. > gcc --version, autoconf --version etc.) >- COMPRESS the stuff before sending. > >Claus > > > > > >-- > Claus-Justus Heine <ch...@do...> > > Ftape - the Linux Floppy Tape Project http://ftape.dot-heine.de/ > NFS Swapping for > Linux http://nfs-swap.dot/heine.de/ <http://www.ee.surrey.ac.uk/Personal/L.Wood><L....@su...> |
|
From: Lloyd W. <L....@su...> - 2006-04-29 21:06:44
|
(if someone can delete all queued-for-moderator messages, that would be great.) It turns out that Geomview can't be built on current Cygwin base, due to Geomview's use of d_ino in src/animate/glob.c. (Geomview's use is apparently not POSIX-compliant.) I've updated http://www.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/building-under-Windows/ with notes about this. Geomview compiled on Cygwin 1.5.18 and earlier will work on 1.5.19; you can move a compiled Geomview tree to the same directory location in a new Cygwin and have it work. L. <http://www.ee.surrey.ac.uk/Personal/L.Wood<L....@su... |
|
From: Lloyd W. <L....@su...> - 2006-04-28 19:16:53
|
At Friday 2006-04-28 11:36 -0700, Chris Elliott wrote: >Hi, > >Thanks Lloyd for the quick reply! I've tried out your recommended >and its still giving me problems. The output below is the result of >changing the sense of !define(__CYGWIN__) to define(__CYGWIN__), Hmmm, that looks like the same output that you'd get with the other sense. (Did you do 'make clean' beforehand?) >I also tried installing geomview 1.8.1 but that gives me problem >when running the ./configure .. command line. Kick me out with the >following message: okay, the lex/flex one is solvable; I see I have flex installed under Cygwin on this machine (though I haven't used it to install Geomview). It must be another prerequisite. Odd that your "1.8.2-alpha" tarball doesn't complain about the same thing - but the configure script is autogenerated by the reconf script in the top-level directory (run by a developer before packaging), so it depends very much on the autoconf install on the machine that produces the configure script. The config files are different in their use of flex. I can't say I like the way the 1.8.1 configure below discovers you don't have flex OR lex, then defaults to deciding that you must therefore have lex, but it's likely an old autoconf bug... Simple 1.8.1 fix: Quit cygwin, run the Cygwin installer and install flex (it's under the Devel tab). That should get you further in compiling 1.8.1. (Installing all the Devel tools so you can attempt to run reconf and recreate the configure files from scratch is a last resort. I've never run autoconf successfully myself.) hope this helps, L. >checking whether c++ accepts -g... yes >checking how to run the C preprocessor... gcc -E >checking for flex... no >checking for lex... no >./configure: line 1435: flex: command not found >checking for flex... lex >checking for yywrap in -ll... no >checking lex output file root... ./configure: line 1523: lex: >command not found >configure: error: cannot find output from lex; giving up > >So even trying that route has led me to problems, so its all a >little frustrating! There must be someone who has setup geomview on >cygwin recently? If so please let me know what the fix is! > >Cheers, >Chris Elliott <http://www.ee.surrey.ac.uk/Personal/L.Wood><L....@su...> |
|
From: Lloyd W. <l....@ei...> - 2005-11-28 14:58:34
|
Rajmund,
I'm forwarding your email below to the geomview developers list for
further advice. Nice to know I'm not the only person attempting
dynamic texturemapping with Geomview.
I've found that geomview stutters on texture { file "" } (not
texturing - that's an appearance keyword that defines on/off) with
SaVi when I write large uncompresssed textures to the file to be read
by geomview. Compressing the textures while writing them with zlib
(so geomview reads .ppm.gz files) helps tremendously with decreasing
disk I/O, at the cost of some CPU -- but then I'm generating a new
texture for every animation cycle. Including zlib support in SaVi for
gzipped files was easy enough.
Rather than having the client application overwrite a texture file
that is read by Geomview again and again, it seems better to cycle
around multiple filenames, so that Geomview can finish reading in a
texture file before it's overwritten by the client application. This
prevents blank textures appearing, or Geomview getting confused and
breaking the command pipe. (I'm rather lax in that the SaVi
src/coverage_vis.c texturemapping code doesn't do this yet, but it
really should. It will be even more boring to write than good
satellite element-handling code.)
I think the obvious way to eliminate disk reads between the client
application running geomview and geomview itself would be to set up
and use named pipes, rather than writing and reading to disk. But
support for this would require modifying geomview's behaviour and
parser handling of the texture command.
Take a look at how SaVi spreads the texture over a precomputed sphere
mesh -- then the only transform applied to the result is to rotate it.
I think you may be able to transform elements, or precompute the mesh
before loading in, before applying the texture. SaVi seems reasonably
quick at this; the way the hierarchy of elements is separated out in
its oogl/ code _may_ be a good model to follow. OTOH, SaVi's not
really stressing things here. Or you may be able to turn off texturing
most of the time via the appearance keyword, and only turn it on when
it's needed. Other than that, I'm out of ideas.
hope this helps,
L.
<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L....@ei...>
---------- Forwarded message ----------
Date: Mon, 28 Nov 2005 14:28:45 +0100 (CET)
From: Rajmund Krivec <Raj...@ij...>
To: L....@ei...
Cc: raj...@ij...
Subject: Geomview textures
Dear Lloyd,
this is not related directly to SaVi, but I hope you might have a
wise remark about it. I'm using Geomview as displayer for a
changing terrain and if I do texture mapping, it is either very slow
or stuttering (= momentary freeze):
if I use a large image spread over many mesh elements, it is
incredibly slow (on an Opteron) (I'm using "transform" to tell
how many elements the image is spread over)
if I use small images (cut by pamdice) an read them one by
one based on my in-view clipping, and using the "texturing { file"
keywords, it is reasonably fast, but I get stuttering e.g. at
every 5 seconds or so, a sign that the system has issues with it
(and, stutter is more pronounced on a SATA disk system than on an
ATA system ...)
It appears to me that the problem is disk I/O. With plenty of memory
around, is there a way to eliminate disk read in Geomview? Using
larger textures (on submeshes, less disk I/O) improves the behaviour
somewhat, but the optimum size of submesh is system-dependent.
If you could point me in some direction, I would be very happy.
Geomview seem to be a nice program to avoid programming in openGL,
but probably it was not meant as a real time displayer of large
structures (and this seekback thing is really annoying).
Sincerely,
Rajmund Krivec
PS: I'm using 1.8.2-alpha because 1.8.1 cannot be installed on newer
Linuxes; "cannot seek back" is not a fatal error if geomview is run
via FIFO, but it usually locks up the system completely if run directly,
(Fedora Core 4 32 bit) or crashes incessantly (Gentoo 64).
Geomview runs best on Solaris but I don't have a 3D card there ;-)
Rajmund Krivec Phone +386 1 477 36 90
J. Stefan Institute Fax +386 1 477 37 16
P.O. Box 3000 E-mail raj...@ij...
SI-1001 Ljubljana, Slovenia WWW www-f1.ijs.si/~krivec
---------------------------------------------------------
Few-Body XVIII OC chairman fb...@ij... fb2002.ijs.si
|
|
From: Stuart L. <sl...@nc...> - 2005-02-03 17:47:07
|
On Tue, Feb 01, 2005 at 11:10:11PM +0000, Lloyd Wood wrote:
> Aha, enlightenment dawns.
>
> I modified SaVi to update an appearance by sending the cached
> appearance from a buffer:
>
> fprintf(gv_out, "(read geometry { define earth_h {\n %s \n} } )",
> dynamic_description);
>
> so that Geomview wouldn't have to do any work with reading .oogl files
> on each animation iteration. (We're still stuck with writing and
> reading compressed texturemaps, alas. Haven't figured out how to pipe
> those to Geomview via telling Geomview to open a named pipe or
> something.)
>
> Once I started sending appearances that way in the pipe, going back
> to the old way of telling Geomview the appearance from this line in a
> file that was copyfile'd to gv_out:
> (read geometry { define earth_h < "$SAVI/oogl/earth.oogl" })
>
> to read the appearance from a file, asynchronously and initiated from
> SaVi's Tcl interpreter in a tk_update() to boot, seemed to result in
> setting up some sort of race condition Geomview couldn't handle.
>
> Going to doing everything via the first, new, method, fixed that. New,
> improved, and very fast and responsive SaVi in the 1 February snapshot
> at:
>
> http://www.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/src/unreleased/
>
> savi -dynamic-texture is really getting smooth.
Whew. Glad you could find a workaround. That would be my bug,
but that code is 10 years old now, and I'd have a hard time tracking
it down.
Re compressed textures, doesn't it help to write .sgi images?
They can use RLE compression, which should let them become much smaller
than .ppm/.pgm images for simple graphics like I'd expect on maps.
|
|
From: Lloyd W. <l....@ei...> - 2005-02-01 23:10:34
|
Aha, enlightenment dawns.
I modified SaVi to update an appearance by sending the cached
appearance from a buffer:
fprintf(gv_out, "(read geometry { define earth_h {\n %s \n} } )",
dynamic_description);
so that Geomview wouldn't have to do any work with reading .oogl files
on each animation iteration. (We're still stuck with writing and
reading compressed texturemaps, alas. Haven't figured out how to pipe
those to Geomview via telling Geomview to open a named pipe or
something.)
Once I started sending appearances that way in the pipe, going back
to the old way of telling Geomview the appearance from this line in a
file that was copyfile'd to gv_out:
(read geometry { define earth_h < "$SAVI/oogl/earth.oogl" })
to read the appearance from a file, asynchronously and initiated from
SaVi's Tcl interpreter in a tk_update() to boot, seemed to result in
setting up some sort of race condition Geomview couldn't handle.
Going to doing everything via the first, new, method, fixed that. New,
improved, and very fast and responsive SaVi in the 1 February snapshot
at:
http://www.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/src/unreleased/
savi -dynamic-texture is really getting smooth.
L.
http://savi.sourceforge.net/
On Tue, 1 Feb 2005, Lloyd Wood wrote:
> Date: Tue, 1 Feb 2005 17:47:58 +0000 (GMT)
> From: Lloyd Wood <l....@ei...>
> To: geo...@li...
> Subject: [Geomview-devel] Re: TxDelete warnings?
>
> Stripping out a few wrapping (progn ) statements to see what's going
> on in Geomview gets me:
>
> $ ./savi-dev -dynamic-texture &
> [8] 2788
> $ /bin/csh: not found
> SaVi: texturemaps will be uncompressed. Compile SaVi with zlib for
> compressed.
> SaVi: dynamic texture mapping will benefit from large coverage map
> (-large-map).
> SaVi: temporary texturemap scratchfile is /tmp/te1c.0-savi.ppm
> Internal warning: TxDelete on non-Texture 102e9f90 (1cf40001 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (1cf40001 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (610e9040 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (610e9040 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (610e9040 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (610e9040 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (610e9040 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (610e9040 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (610e9040 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (610e9040 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (10192378 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (10192378 !=
> 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Internal warning: TxDelete on non-Texture 102e9f90 (0 != 9cf40001)
> Geomview: internal error: Segmentation violation; dump core now (y/n)
> [n] ? SaVi: cleaned up temporary scratchfile /tmp/te1c.0-savi.ppm
>
> That looks like a misset null pointer inside Geomview...
>
> L.
>
> On Thu, 27 Jan 2005, Lloyd Wood wrote:
>
> > Date: Thu, 27 Jan 2005 23:46:00 +0000 (GMT)
> > From: Lloyd Wood <ee...@ei...>
> > To: geo...@li...
> > Subject: TxDelete warnings?
> >
> > I've managed to upset Geomview by switching from a textured to a
> > non-textured Earth very quickly in SaVi and recreating my Earth
> > geometry. I've even managed to make Geomview dump core -- I can't
> > recall the last time, if ever, Geomview did that. Most unusual, hence
> > this email.
> >
> > Can anyone shed any light on the cause of this TxDelete error
> > message?:
> >
> > Internal warning: TxDelete on non-Texture 102ea018 (102ea140 !=
> > 9cf40001)
> > Internal warning: TxDelete on non-Texture 102ea018 (102ea140 !=
> > 9cf40001)
> > Geomview: internal error: Segmentation violation; dump core now (y/n)
> > [n] ?
> >
> > thanks! To duplicate if you're that interested, today's SaVi
> > snapshot, launched with: geomview -run savi-dev/savi -dynamic-texture
> > and then turn on texturemapping in Rendering menu, open coverage
> > window from Views menu, run animation with >>, then change SaVi's
> > Earth projection from sinusoidal so SaVi has to stop texturemapping to
> > the Geomview sphere.
> >
> > I've committed a workaround to CVS that avoids, but does not solve,
> > this problem by simply turning off texturemapping when SaVi's earth
> > projection changes; SaVi's driving Geomview pretty hard and fast
> > texturewise now, and other than this new twist it's pretty slick. I
> > guess the code in savi-dev/src/earth.c needs a complete rethink...
> >
> > http://www.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/src/unreleased/
|
