From olly@survex.com Tue, 07 Mar 2000 17:20:03 +0000 Date: Tue, 07 Mar 2000 17:20:03 +0000 From: Olly Betts olly@survex.com Subject: List changes Hi folks, I'm having to move the survex mail handling (including mailing lists) to another machine. As some of you may know I'm taking an extended trip to Australia and I need to sort this out before I go away (on the 17th). Unfortunately I've got enough to do without this so I'm having to rush it and there's likely to be a little disruption. I'll send another message when it's all sorted out letting you know what's changed. In the meantime, please try to be patient - if there's an urgent problem, mail me directly. In particular you may find subscribing and unsubscribing may not work for a day or two. Cheers, Olly From olly@survex.com Wed, 08 Mar 2000 20:13:05 +0000 Date: Wed, 08 Mar 2000 20:13:05 +0000 From: Olly Betts olly@survex.com Subject: Details of recent mailing list changes Hi folks, As some of you know (and many others probably don't) I'm off on an extended trip to Austrlia at the end of next week. Unfortunately last week I was told I needed to move survex.com (it's currently hosted at a company I used to work for who've been very lax about kicking me out). So I've had to relocate the mailing lists at short notices. It's possible that some list mail has been eaten during the change - if you've sent something and not seen it back then please resend it. The list are now run by different software, but it's nicer in many ways. Here's an overview of what's different. It would be wise to read this and/or keep this message so you can refer to it later. The lists now have a nice web interface (there's also an email interface - send a message "help" to survex-request@survex.com): http://lists.tartarus.org/mailman/listinfo/survex There is now a web archive of the list, which is available to non-subscribers too. You need a password to change you subscription details with the web interface - you won't currently know your password, but you can request it be sent to you from the web interface. A couple of new options of note: You can choose to receive a daily "digest" of list messages. You can also suspend email to your address without actually unsubscribing which might be useful if you are away for a while (e.g. undergrads during university vacations). If there are any problems let me know. But bear in mind that I'm off on my travels in just over a week and my access to email will then be sporadic until June. Don't worry, I'm definitely going to get 0.92 released before I go... Cheers, Olly From brian@bclipstone.freeserve.co.uk Wed, 8 Mar 2000 21:38:25 -0000 Date: Wed, 8 Mar 2000 21:38:25 -0000 From: Brian Clipstone brian@bclipstone.freeserve.co.uk Subject: Survex 0.92 prerelease 6 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BF8946.A264E320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have downloaded the MSDOS version and have tested it on OFD.=20 CAVERN is now slower by over 100% , 25.71 secs against 57.58secs for = OFD2, otherwise no other problems. CAVEROT Keys :- Delete, U & D and the cursor keys do not work. Added = extra if you press the left and right buttons together on the mouse you = toggle Plan/Elevation. PRINTPCL is OK, label size OK. As an aside, I print out two sheets, one = for drawing and one with the labels on. Brian Clipstone. ------=_NextPart_000_000A_01BF8946.A264E320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have downloaded the MSDOS = version and=20 have tested it on OFD.

CAVERN is now slower by over = 100% , 25.71=20 secs against 57.58secs for OFD2, otherwise no other=20 problems.

CAVEROT Keys :- Delete, = U & D=20 and the cursor keys do not work. Added extra if you press the left = and=20 right buttons together on the mouse you toggle=20 Plan/Elevation.

PRINTPCL is OK, label size = OK. As an=20 aside, I print out two sheets, one for drawing and one with the labels=20 on.

Brian=20 Clipstone.

------=_NextPart_000_000A_01BF8946.A264E320-- From olly@survex.com Wed, 08 Mar 2000 22:02:30 +0000 Date: Wed, 08 Mar 2000 22:02:30 +0000 From: Olly Betts olly@survex.com Subject: Survex 0.92 prerelease 6 >I have downloaded the MSDOS version and have tested it on OFD. >CAVERN is now slower by over 100% , 25.71 secs against 57.58secs for >OFD2, otherwise no other problems. Which version are you comparing against? I would expect cavern 0.92 to be slower than 0.91 or earlier. This is because cavern now performs full covariance calculations in the least squares solution. The benefit is better loop closure results (though the difference will be small) but more importantly it allows better further analysis of the errors. I'm suprised it's as much as 100% slower. What spec is the machine? If it's the old SWCC machine (which I suspect doesn't have a floating point unit) I'd be less suprised. Brian - are you happy to let me have a copy of the OFD data set to play with? If so, could you send it to me (either by email or on a floppy) so I can investigate further. > CAVEROT Keys :- Delete, U & D and the cursor keys do not work. OK. Did they work in the previous version? If so, which version was that? >Added extra if you press the left and right buttons together on the >mouse you toggle Plan/Elevation. That what the middle button does on a 3-button mouse (or if you depress the wheel on a wheelmouse). Clicking both buttons together emulates the third button (a useful feature). >PRINTPCL is OK, label size OK. Great. Cheers, Olly From brian@bclipstone.freeserve.co.uk Wed, 8 Mar 2000 23:47:59 -0000 Date: Wed, 8 Mar 2000 23:47:59 -0000 From: Brian Clipstone brian@bclipstone.freeserve.co.uk Subject: Fw: Survex 0.92 prerelease 6 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01BF8958.BC479B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have downloaded the WIN 32 version and have tested it on OFD.=20 CAVERN is now slower by nearly 100% , 40.69 secs against 78.88secs for = OFD2, otherwise no other problems. Other ver. was Win 0.91. CAVEROT Keys :- Delete, U & D and the cursor keys do not work. The Delete key acts as a right cursor key and the right cursor key acts = as the delete key. Added extra if you press the left and right buttons together on the = mouse you toggle Plan/Elevation. Brian Clipstone. ------=_NextPart_000_001C_01BF8958.BC479B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have downloaded the WIN 32 = version and=20 have tested it on OFD.

CAVERN is now slower by nearly = 100% ,=20 40.69 secs against 78.88secs for OFD2, otherwise no other = problems. Other=20 ver. was Win 0.91.

CAVEROT Keys :- Delete, = U & D=20 and the cursor keys do not work.

The Delete key acts as a right cursor key and the right cursor = key acts=20 as the delete key.

Added extra if you = press the left=20 and right buttons together on the mouse you toggle=20 Plan/Elevation.

Brian=20 Clipstone.

------=_NextPart_000_001C_01BF8958.BC479B40-- From furbrain@furbrain.screaming.net Fri, 10 Mar 2000 02:14:27 +0000 Date: Fri, 10 Mar 2000 02:14:27 +0000 From: Phil Underwood furbrain@furbrain.screaming.net Subject: Chasm and survex-0.92 I've finally got around to making the patch for survex-0.92 To re-iterate, chasm requires an extended file format to do all the cleve= r things it does. To produce these files, cavern needs to be patched. I've posted patches for survex-0.91 and 0.92-pre-release6 (which will probably work with most fo them, in fact); these are also available from the chasm home page http://members.xoom.com/bighairyone/chasm. I've also put the chasm help files on-line; access them from the same pag= e. On a completely different vein, I can confirm survex-0.92-pre-release-6 compiles and loads happily on my machine, even when patched. It is also about 100% slower on my machine (cyrix 200 MHz, 32Mb, Linux redhat 5.1); it takes 18s to process evenmore.svx , compared with 9s for v0.91 I must admit that it doesn't really bother me though... Phil U From olly@survex.com Fri, 10 Mar 2000 14:36:06 +0000 Date: Fri, 10 Mar 2000 14:36:06 +0000 From: Olly Betts olly@survex.com Subject: Chasm and survex-0.92 Phil Underwood writes: >On a completely different vein, I can confirm survex-0.92-pre-release-6 >compiles and loads happily on my machine, even when patched. It is also >about 100% slower on my machine >(cyrix 200 MHz, 32Mb, Linux redhat 5.1); it takes 18s to process >evenmore.svx , compared with 9s for v0.91 I've realised why this is - there's quite a bit a paranoid checking still enabled in the new covariance code. I'd like to leave this on for now since if there are any remaining problem it will shake them out as people try it in anger. I will turn off these checks (at least the expensive ones) in a future release and then you'll see quite a speed-up. Cheers, Olly From olly@survex.com Mon, 13 Mar 2000 01:40:52 +0000 Date: Mon, 13 Mar 2000 01:40:52 +0000 From: Olly Betts olly@survex.com Subject: Survex 0.93 released Yes, that really does say 0.93... I had just finished uploading the 0.92 release when Wookey reported a problem, so I held off announcing it here while I investigated. It turned out to be a problem with the articulation point code (this splits up the network into sections which can be solved separately). I know where the problem lies, but since time is short I've just disabled the problem code for now. http://www.survex.com/download.html Checking the logs I noticed several people had spotted the new release on the web site and downloaded it. If you have, you needn't bother redownloading the documentation - the contents of the 0.92 and 0.93 documentation archives are identical. Here's the user visible changes for 0.93, and also 0.92 (since I didn't announce that here): Changes in 0.93: * Quick fix for problem with finding articulation points in particularly contorted components with 2 or more fixed points - for now each component is solved separately, but they aren't split at articulation points * Turned off some debug code left active by mistake * Test suite was missing a file Changes in 0.92: * 3dtodxf's DXF output can be opened by AutoCAD 13, 14 and 2000, as well as ArcView 3.x. Adobe Illustrator 8.0, and CorelDraw 8. [checked by Mike Yocum] * HTML documentation now has meaningful filenames (no more "x532.htm") * RISC OS documentation zip file now has correct filetype for Postscript version of docs * RISC OS binary distribution now includes !CLIcon GUI front end * Changed naming scheme for .zip archives to be more consistent * Added OLDNEWS with details of user-visible changes in much older versions Cheers, Olly From benchoff@vt.edu Wed, 15 Mar 2000 10:22:40 -0500 Date: Wed, 15 Mar 2000 10:22:40 -0500 From: Phil Benchoff benchoff@vt.edu Subject: 0.93 on Digital Unix and Linux Developers, Let me thank each one of you for putting survex together. I use Digital Unix at work and Linux at home, so I was very happy to find an open-source program to map some survey data. Here are some comments on quick tests on Digital Unix 4.0F and RH Linux 6.1 with 0.93. DU: Don't have gtk-- and didn't try aven. Compiled ok, but several messages about incompatible pointer types. xcaverot - All of the buttons and the two controls on the right are empty (no text or symbols). They appear to function properly. Perhaps they are displaying in black on black. xcaverot core dumps with a segv sometimes. I haven't looked at the core file to see where yet. A common problem is with the 64-bit longs on this platform. Linux: Had to install gtk-- and gtk--devel. aven still didn't compile and it was too late for me to figure out why. If I remember correctly, it was complaining about missing header files. Are there additional packages required? cavern and xcaverot seem to work fine. I'll report my findings if I get a chance to look into these. Phil From olly@survex.com Wed, 15 Mar 2000 15:38:51 +0000 Date: Wed, 15 Mar 2000 15:38:51 +0000 From: Olly Betts olly@survex.com Subject: 0.93 on Digital Unix and Linux >DU: > Don't have gtk-- and didn't try aven. > Compiled ok, but several messages about incompatible pointer types. Assuming you're using a recent version of gcc (probably 2.95 or later) this is a known issue. It's to do with const-ness and pointers to arrays. I believe gcc is being too fussy (there seem to be similar examples discussed on the gcc mailing list) but I've not found a clean way to workaround the warning. I may just end up disabling it. > xcaverot - All of the buttons and the two controls on the right are > empty (no text or symbols). They appear to function properly. Perhaps > they are displaying in black on black. The buttons should have labels; the two boxes should have a compass and clinometer. I'm no Xlib expert, but if anyone can see what's going wrong I'll happily correct it. > xcaverot core dumps with a > segv sometimes. I haven't looked at the core file to see where yet. > A common problem is with the 64-bit longs on this platform. Xcaverot has been checked on a alpha before, but it was some time ago so perhaps recent changes aren't 64 bit safe. > Had to install gtk-- and gtk--devel. aven still didn't compile and > it was too late for me to figure out why. If I remember correctly, > it was complaining about missing header files. Are there additional > packages required? You need some gnome devel packages too. Check Mark's aven page for details (also linked to from "related packages" on www.survex.com): http://mrs30.quns.cam.ac.uk/aven/ >I'll report my findings if I get a chance to look into these. Thanks. Cheers, Olly From john.pybus@zoology.oxford.ac.uk Wed, 15 Mar 2000 15:43:08 +0000 Date: Wed, 15 Mar 2000 15:43:08 +0000 From: John Pybus john.pybus@zoology.oxford.ac.uk Subject: 0.93 on Digital Unix and Linux Phil Benchoff wrote: > > Developers, > Let me thank each one of you for putting survex together. I use Digital > Unix at work and Linux at home, so I was very happy to find an open-source > program to map some survey data. > > Here are some comments on quick tests on Digital Unix 4.0F and RH Linux 6.1 > with 0.93. > > DU: > > Don't have gtk-- and didn't try aven. > Compiled ok, but several messages about incompatible pointer types. > xcaverot - All of the buttons and the two controls on the right are > empty (no text or symbols). They appear to function properly. Perhaps > they are displaying in black on black. xcaverot core dumps with a > segv sometimes. I haven't looked at the core file to see where yet. > A common problem is with the 64-bit longs on this platform. I started using xcaverot under Digital Unix, and seem to remember getting the 64bit issues sorted at the time (1996). However its possible that changes made since then have broken it again, I've only been trying it on Linux more recently. The black-on-black issue, may be something to do with default colours on your Xserver being set differently. Xcaverot isn't really under much active development at the moment. I got it working in 96, and added a few experimental bits shortly after, but never got round to properly tidying it up. I have access to a Digital Unix box, and will have a look when I get a moment to two. Yours John Pybus From olly@survex.com Wed, 15 Mar 2000 16:20:51 +0000 Date: Wed, 15 Mar 2000 16:20:51 +0000 From: Olly Betts olly@survex.com Subject: 0.93 on Digital Unix and Linux In message <38CFAF8C.42864D77@zoo.ox.ac.uk>, John Pybus writes: >Xcaverot isn't really under much active development at the moment. I >got it working in 96, and added a few experimental bits shortly after, >but never got round to properly tidying it up. Ideally I'd like to phase out xcaverot in favour of aven. But there are barriers to this - xcaverot just requires an ANSI C compiler and the most basic X libraries; aven requires a C++ compiler, GTK, GTK--, and some gnome libraries. Cheers, Olly From Mike.Lake@uts.edu.au Fri, 17 Mar 2000 02:13:44 +1100 Date: Fri, 17 Mar 2000 02:13:44 +1100 From: Michael Lake Mike.Lake@uts.edu.au Subject: 0.93 on Digital Unix and Linux Olly Betts wrote: > > In message <38CFAF8C.42864D77@zoo.ox.ac.uk>, John Pybus writes: > >Xcaverot isn't really under much active development at the moment. I > >got it working in 96, and added a few experimental bits shortly after, > >but never got round to properly tidying it up. > > Ideally I'd like to phase out xcaverot in favour of aven. But there > are barriers to this - xcaverot just requires an ANSI C compiler and > the most basic X libraries; aven requires a C++ compiler, GTK, GTK--, > and some gnome libraries. I find that xcaverot is usually fine for my needs when working with others to find mistakes in our survey data. Its fast, basic and although there are bugs it compiles and works. I have not yet got around to compiling aven or chasm on my Alpha as I am in a: /--> gtk-devel-++-lib-dependency-upgrade-cycle --\ | | \------------------------------------------------/ ;-) It would be nice if xcaverot could remain - OK not developed further in termsof functionality, but just tidied up so its basic functionality was all there, no major bugs, and it could run then on any 486 PC with Linux or low end laptops with Linux. The gnome libs take lots of space and mem. Mike -------------------------------------------------------------------- Michael Lake University of Technology, Sydney Email: mailto:Mike.Lake@uts.edu.au Ph: 02 9514 1724 Fx: 02 9514 1628 URL: http://www.science.uts.edu.au/~mikel Linux enthusiast, active caver and interested in anything technical. -------------------------------------------------------------------- From furbrain@furbrain.screaming.net Thu, 16 Mar 2000 04:15:41 +0000 Date: Thu, 16 Mar 2000 04:15:41 +0000 From: Phil Underwood furbrain@furbrain.screaming.net Subject: DEMs I was asked by an american caver (Nick Yost: yostn@gte.net) if I thought that his program would be a useful thing to have - it's essentially a viewer for DEMs - digital elevation maps. These are digital representatio= ns of surface topography. He was considering whether to add support for surv= ex files, so one could see the cave in relation to the map. It's actually a pretty competent viewer; homepage is at http://www.linuxstart.com/~g3DGMV= / This also got me thinking, so I've written a little utility that will convert DEM files into an svx file (similar to the surface grids that cuc= c have used in austria). The program was written using some hacked code from Nick's program. This is now available from my chasm site - http://members.xoom.com/bighairyone/chasm under "Goodies" (at the bottom)= =2E Would this be worth adding to the survex distribution? the actual file itself is very small. From mrs30@cam.ac.uk Thu, 16 Mar 2000 11:35:15 +0000 Date: Thu, 16 Mar 2000 11:35:15 +0000 From: Mark Shinwell mrs30@cam.ac.uk Subject: 0.93 on Digital Unix and Linux On Fri, Mar 17, 2000 at 02:13:44AM +1100, Michael Lake wrote: > Olly Betts wrote: > > > > In message <38CFAF8C.42864D77@zoo.ox.ac.uk>, John Pybus writes: > > >Xcaverot isn't really under much active development at the moment. I > > >got it working in 96, and added a few experimental bits shortly after, > > >but never got round to properly tidying it up. > > > > Ideally I'd like to phase out xcaverot in favour of aven. But there > > are barriers to this - xcaverot just requires an ANSI C compiler and > > the most basic X libraries; aven requires a C++ compiler, GTK, GTK--, > > and some gnome libraries. > > I find that xcaverot is usually fine for my needs when working with > others to find mistakes in our survey data. Its fast, ^^^^ (ahem) Yeah, right! It is possible that I could do a plain Xlib version of Aven without any fancy features; the core code would not be that difficult to port. (And I bet it would run even faster). But unfortunately I have Finals in eleven weeks, so it'll have to wait until after that, I suspect! Mark -- Mark Shinwell -- President, Cambridge University Caving Club Queens' College, Cambridge, UK Mail: mrs30@cam.ac.uk Web: http://mrs30.quns.cam.ac.uk From leandro@dybal.eti.br Sun, 19 Mar 2000 20:04:38 -0300 Date: Sun, 19 Mar 2000 20:04:38 -0300 From: Leandro Dybal Bertoni leandro@dybal.eti.br Subject: xcaverot patch This is a multi-part message in MIME format. --------------FF3FD7D31E3CF3D408783833 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Lake wrote: > > Olly Betts wrote: > > > > In message <38CFAF8C.42864D77@zoo.ox.ac.uk>, John Pybus writes: > > >Xcaverot isn't really under much active development at the moment. I > > >got it working in 96, and added a few experimental bits shortly after, > > >but never got round to properly tidying it up. > > > > Ideally I'd like to phase out xcaverot in favour of aven. But there > > are barriers to this - xcaverot just requires an ANSI C compiler and > > the most basic X libraries; aven requires a C++ compiler, GTK, GTK--, > > and some gnome libraries. > > > It would be nice if xcaverot could remain - OK not developed further in > termsof functionality, but just tidied up so its basic functionality was > all there, no major bugs, and it could run then on any 486 PC with Linux > or low end laptops with Linux. The gnome libs take lots of space and > mem. > That's why I keep fiddling (sp?) with xcaverot: my "field" computer is a 486 DX2 with 16Mb of RAM. If there were a SVGAlib version I probably would be using it (and freeing some Mb of RAM from X+WM). This is a patch to fix a number of small problems: - lenght is scalebar and its text display - mouse right-button "cave drag" and center-button "plan/elevation switch" - "menu button" zoom in/out now updates the drawing Sorry for the "untimeliness" of the patch, but for most of the pre0.92-series I was recovering from eye surgery and couldn work on it. Enjoy, Leandro ------------------------------------------------------------------------------ --------------FF3FD7D31E3CF3D408783833 Content-Type: text/plain; charset=us-ascii; name="xcaverot-0.93-patch.1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xcaverot-0.93-patch.1" --- survex-0.93.orig/src/xcaverot.c Sun Mar 12 21:04:08 2000 +++ survex-0.93.new/src/xcaverot.c Sun Mar 19 19:45:16 2000 @@ -497,6 +497,7 @@ static void draw_scalebar(void) { + char temp[20]; float l, m, n, o; if (changedscale) { @@ -521,6 +522,11 @@ XDrawLine(mydisplay, scalebar, scale_gc, 13, 2, 13, 2 + scale * datafactor * sbar); + if (sbar<1000) + sprintf(temp, "%d m", (int)sbar); + else + sprintf(temp, "%d km", (int)sbar/1000); + XDrawString(mydisplay, mywindow, slab_gc, 8, BUTHEIGHT+5+FONTSPACE, temp, strlen(temp)); } /* FIXME: Zoom In -> In / Zoom Out -> Out ??? */ @@ -532,6 +538,7 @@ changedscale = 1; flip_button(display, mainwin, button, egc, mygc, "Zoom in"); draw_scalebar(); + fill_segment_cache(); } void @@ -542,6 +549,7 @@ changedscale = 1; flip_button(display, mainwin, button, egc, mygc, "Zoom out"); draw_scalebar(); + fill_segment_cache(); } void @@ -978,7 +986,7 @@ else sprintf(temp, "%d km", (int)sbar / 1000); // FIXME: add BUTHEIGHT to FONTSPACE if buttons on - XDrawString(mydisplay, window, slab_gc, 8, FONTSPACE, temp, strlen(temp)); + XDrawString(mydisplay, window, slab_gc, 8, FONTSPACE, temp, strlen(temp)); } static void @@ -1219,6 +1227,8 @@ /* mouse moved down */ scale = rotsc_scale * pow(2, -a); } + changedscale = 1; + draw_scalebar(); } fill_segment_cache(); @@ -1373,7 +1383,7 @@ myhint.x = 0; myhint.y = 0; myhint.width = WidthOfScreen(DefaultScreenOfDisplay(mydisplay))-5; - myhint.height = HeightOfScreen(DefaultScreenOfDisplay(mydisplay))-5; + myhint.height = HeightOfScreen(DefaultScreenOfDisplay(mydisplay))-25; myhint.flags = /* PPosition | */ PSize; if (have_double_buffering) { @@ -1459,8 +1469,8 @@ ind_fg, ind_bg); #else scalebar = - XCreateSimpleWindow(mydisplay, mywindow, 0, BUTHEIGHT, 23, - attr.height - (BUTHEIGHT + FONTSPACE + 5), 0, ind_fg, + XCreateSimpleWindow(mydisplay, mywindow, 0, BUTHEIGHT+FONTSPACE+10, 23, + attr.height - (BUTHEIGHT + FONTSPACE + 10) -5, 0, ind_fg, ind_bg); #endif @@ -1675,7 +1685,9 @@ press_left_button(myevent.xbutton.x, myevent.xbutton.y); /* process_focus(mydisplay, mywindow, * myevent.xbutton.x, myevent.xbutton.y); */ - } else if (myevent.xbutton.button == Button2) { + } + } + else if (myevent.xbutton.button == Button2) { /* toggle plan/elevation */ if (plan_elev == PLAN) { switch_to_elevation(); @@ -1686,7 +1698,6 @@ /* translate cave */ press_right_button(myevent.xbutton.x, myevent.xbutton.y); } - } } else if (myevent.type == MotionNotify) { if (myevent.xmotion.window == ind_com) { int old_angle = (int)view_angle; @@ -1895,6 +1906,7 @@ } if (redraw) { perform_redraw(); + draw_scalebar(); #ifdef XCAVEROT_BUTTONS draw_buttons(mydisplay, mywindow, mygc, enter_gc); #endif --------------FF3FD7D31E3CF3D408783833-- From mrs30@cam.ac.uk Sun, 19 Mar 2000 23:33:18 +0000 Date: Sun, 19 Mar 2000 23:33:18 +0000 From: Mark Shinwell mrs30@cam.ac.uk Subject: xcaverot patch On Sun, Mar 19, 2000 at 08:04:38PM -0300, Leandro Dybal Bertoni wrote: > > That's why I keep fiddling (sp?) with xcaverot: my "field" computer is a > 486 DX2 with 16Mb of RAM. If there were a SVGAlib version I probably > would be using it (and freeing some Mb of RAM from X+WM). For the next release of Aven, which will probably not occur until June, I am planning to produce a version which has a modular structure, so new graphics "engines" can be easily added. I plan to produce GTK, Xlib and OpenGL engines; one utilising SVGALib could be easily added if the demand is there or if somebody wishes to write one. If you're using a slow computer, there will then be no need for Xcaverot, as Aven is very many times faster. Mark -- Mark Shinwell -- President, Cambridge University Caving Club Queens' College, Cambridge, UK Mail: mrs30@cam.ac.uk Web: http://mrs30.quns.cam.ac.uk From wookey@aleph1.co.uk Mon, 20 Mar 2000 13:18:46 +0000 (GMT) Date: Mon, 20 Mar 2000 13:18:46 +0000 (GMT) From: Wookey wookey@aleph1.co.uk Subject: svx2dxf and CAD fuer Hohlen This message is in MIME format. If you are reading this text, then your mail package doesn't fully support MIME - there may be a newer release available from your supplier. Created using the !Marcel mail package from ANT Ltd --401825-1025186760-953558326=:1784828741 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE I'm forwarding this to the list as I don't know anything about DXF myself. Thilo Mueller uses Survex and CAD fuer Hoehlen by Tobias Bossert, which uses AUTOCAD for cave drawing. It seems that the current 3dtodxf converter does not satisfy it's import function, which requires the data in a specific manner. It would be nice to support this, so if any of you who know about this stuff/would like to fiddle feel like a go, feel free. I've taken the liberty of attaching the example file as it's only 12K - hope that's OK. Thilo or I can help with examples of the same dataset generating a dxf using 3dtodxf, and Thilo can get further info out of Tobias if required (Looking at the file I suspect it is?) Wookey --=20 Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ ---------- Forwarded message ---------- Date: Sun, 19 Mar 2000 16:13:02 EST From: Hoehle@aol.com To: wookey@aleph1.co.uk Subject: Re: Loser International In einer eMail vom 3/17/00 8:55:45 (MEZ) Mitteleurop=E4ische Zeit schreibt= =20 wookey@aleph1.co.uk: > Good. Can you check if CfC can use the DXFs that survex's svx2dxf utility > puts out? It has been checked on a number of other programs as OK, but > not this. If there is a problem we should fix it... Hi Wookey, no, that doesn=B4t work yet. CfC expect the dxf in a very special way. So t= he=20 dxf defines all layers (and there are some 40-50 in a sigle cave I think) a= nd=20 some more information. I=B4ve added a dxf from 115 as Toporobot produces it= now. Cheers Thilo --401825-1025186760-953558326=:1784828741 Content-Type: APPLICATION/RISCOS; NAME="115dxf/zip,ddc"; TYPE=Archive; LOAD=&fffddc49; EXEC=&a23f03b9; ACCESS=&03 Content-Transfer-Encoding: BASE64 UEsDBBQAAAAIALuwcyg7CcY4Xy8AACqIAgAJAAAARzAwMDIuZHhm7Z1Lsiy3 kabnNDt74AYyLByI57BUze6imYqqlmiy7lGtoPY/rXghIk6m/4C7A8gky64G 0r0UkZ/Hj5fD4QB+/rn9+ukfv/zr77/+7bevn37+2X399Mtvv//6+6+//GP9 6/J//vrbP375++/rX6avn/5P27b0WP/rP9f/+ue/L/+cln+pbdrlv3921x87 +vqJmu1P7vyTD39aOVthMWFo1l/cCDQ17VwB4Zq+OxDON85VQFAz+wPh24bq fEU7BYRrfI26eNClVNfuFVOe4Zvp/JC+mWtUx4OGpg1f4uc6LXf9kkuurqE6 X7K03tC0urmZhkqQNkB633R15HLNMARIX1GuG2Tq/oCQ//jbX///X3/97ReA +evyzzeh1v/QUeafi1m//L9ICX60FhdlhmFxWWZ8FZdlBk4F92VEFJflhjpF YWYMU5RmBicV+2XUUZRmhhNV6ZdxQlX6ZQDQWf7c6fJL/+OX//vLb//r+Mvy O6Dv/+U/vqBD1K6tuP/ah4C2mTZRxq+ftjJrB27lP895Q8nfJ/nvc65Q8ved /Pc5Pyj5+15j/6sTlPz9Tv77rAeUBPQaAOf+JAmDhsD5PknCqPuGV8cnSZg0 BM7rSRJmHeHV5UkSqNUhXh2eNELRnXlPJI1Q9GgrQtCp8SJz3Az8eXObfia6 /pXrj7sJwYdsm2Gzod/qqDnN+fdgzn8WNeccJuh5mPiYQWFYoedh5WMWhQ5G zx1MbVHMK/+3v0ObDpd8++Ppk/ftatt8NNnlH28/kEl5uMIYEBXhMb4/vrIY 57F8GxUFgRgM4CzTli/KWT5o4JSzg0DEZ5kZ2RqaGyrKefANOwME4ksecNrC HNjkzCAYzWrZT3JzWNAUIy3DAtcaskggesar56bRrh4ggbEuCwWidahJ9Lus BUlrDTIflYXC0UGGtI6+hUFLj/KFSSAWydfTXJyz1JJjvigLxMY9UcPzzViY 9ACjUSYLBFr5Nl6etDS9Cig25trx8u3TfUEO+qTiIH54HVqro4K/qJeTImuC 376CozLMB8X7htapY23lbvvlvVONJ4QWQ+Z1/Rh8/424Ov/bbuX6D3tq/+u3 3+T8rTGeXaxvPMUsoNHt7m7EgFZvQB9mzMWAIUS/rAZ0882AWF3/5d++nrYM VnvggujrXuff9yi2X1px//L773//9S8R3N6Pf97+ZYA714Rri4ut4q9Awjk6 7IaM4Q+0OqIhRPUtZqvXxbTjXFeYYBJ9wbBvRBlqQrAlUxnTRnldZdwVaEEB 64gyy6qvjDKm/f26ygSTCIfao22mkDKmtITabWY3ifAmQUSZfbQuoIwtm6Ku NDhw+d4x2JgFUlscGEQVqdOVU8eUvlJbnWAU4X2l6IgzlVLHlHdTv+1cPQvs iUVnqmJtx5QwVFudYBTh/bx3zFbGTKf66oCtEuGoHDagC6hjSNGqr85uFOFt 1Kg6bTl1DGlfb+hZN3XY7dmYt/NDHCxOp246/h2ZiHfIMqveYh5CH1MJWYwP kZ01gCebUHSMdo8GbQhqqIZWY+Nv0+I4VUAMV/xnQcw1EEuFj/3FaMcajL4Z xsAYG1ejNlzfrIGv0HBdjYbrpssTGto63+GX6SX08mFpVlUYw96WDkbBxOmL 0S1DYqjzcWy6Goy+a1xou+tuYV+DsfxuqI+Zmll5EiOamu3Vqdk+K331XpoZ 5+WlmQFcXJgZmcVlmSFXXJYZS8VluUFSXpgZ/cSFuWFNXpgZr8SFuYFIXpgZ YcSFuaFDXJgbE+SFmc7+4q3BnRt/y3Hk3Ki1LcRzHDsFgnOi0oReTuBcqDRg kAM4ByoNGOUAzn1KAyY5gHWe0oRkWvGNwLlOSYJr5QTWcUoTSEHg3KY0wckJ rNOUJngFgXOZ0gRFh2YdpjRB0aFZdylNUPRo1llKEwRdWpMoHEZGeh4Zgw+a n7msMujsw/Tchz9k0NnU6Lmpfcigs93Qc7tRGxRz6t+VKyMAaXJlhCQQueHz bYmUKaMCEkpaz0DBSBGXOkWtMhMxDXoA9ewkEJhCnGFPUCzGARnEGSAQBgNt wevSX5OYx1CYA0JufHdddxKKYlAXMnNQeI9PPqRWmXOdBoFE6BwSiCbyiZuT 0x2ZSXNAk7ODUOiSr6Nl8jaOpogDGl0GCMZJuQ9yYzOX5YDUWjsIBWV5zuCs TRtxwDSUAQIRYOCVeLNwgAOanB0UCTcznK61Tg+IA2rIDsKx7bKDAuI8+INn GSAQSOebXDdZZzzEAQfcWFBkVROSsw+fdhtLl8XJ1g5akJq9NJR5bTSRzOxJ khp+0WmptdvcNEUzw4du74QR/KjDu+H29UMiMf3h29L85RfHc1hZvi4s8fnE +KWJb/OekB9rZW/PVfB/plwFpI4pp6C2OsEowhH6kmkuSBxTLkRlbWAA7b0N x5TDUVeaYBLhPZGimeBAGVPqSV1lgkmEN3PeoYwpY6auMsEkwrtQRbMNgTK2 RJ+60pw2Ed4/e0ersSUoVdYG7hq8VxtbYlVdbU6b6GaTXJtOnd+MtDElhFXW Zroy49Fua7TdhF3RTG1siWx1tTltIrxP/A7PxpaAV1mbYBPhHe53aGNLHKyr Dd4wfa82toTHutqcNhHOKohoM5Qai22JmpW1gfvaQm1apTZ9qbxVEWOZXsaw eJ19M1ANxtS48zv647qWwozRX91qYVCN75j8FbFbtOplw5qScRseZndcOfNn Z/j9WHpxxnSdF56P7dUKjG1IOPpgKwvu6BiLPuv/7FPCvF9YUpzRXeHe5Zva Koy+6bqDMQ4lz29802oIjKHoJf5vZ2z9bmMM1dpVfUbfzIGxzleyJYKSMTfd GUV06rEken6jV5/f6JOp5qLC3MQrL8zMqOLC3FQpLszNgfLCzMTzgcLHdCQv zMwzmsIvE4i4MDczyAszQ768MDOWa8x+GUDfVvhlyHtTYWYglBdmRri1sOzQ Sn+dluC8+XYdFa/FCpO8PSkInC+fJiSPS1wE1pNPEs6XPgQE1o9PE0hB4Dzs NMFVJ3gjIXjwaUKnIHD+e5rQqwiv3nuaMMgJrO+eJowKAue5pwmKPs367WmC ok+zHnWSsH12XYKiT7PedJqg6NNGgqJPs956mqDo06yvniYI+nRYDURiduv/ bhvZYQqh5ynEnUbkHo5RGXSOdPQ80n3IoHNQoedB5VMGhf5Lz/33UwaFhkzP DVltUGyR+6bcyjRHk1spAqHIMp/jPx7ZxOU44PGADBAIY/Npw4v7ZBUOcEDC tR2EYuYTy1m9hLIc0OTsIBSg5z+InNed1EuD4NkfOwnE6sEndcO1GVUGBA5i VCDxrWFpPKozOeYvKgS67XXwjaH3uhMfaQ44iJoBAhsr/IhKXW9WDoDAyJBH Qvs4LMjeugEITEcZJLRtBECu0x0PTYPQ0JBBArtUI19L/WSdKRAI1VIGCW2K tfw3LZ28L0tCnSmDhDfIOFAQuxwInekuT+K9VZqVp3kFn1SDxG7/Ie0oYyBi QfAFvOIkoN04Wt0u+EnlSWADFZxW78k8tgIQ+qQMEtiv5Q9dz8rnctIcMDqw oEiwIJxUG2gfSw+3a2u66yjDn1Rrl3/s1r/cxvgtLHCdVBskJ+Uu/ni72nyp xDMsyPKn9EG9Xodf1jr+ttbZ/gzx3iXxnRJ/3Jt+uIjnax9WvFfiFw/1tojw UfGXObXfm2E5A5YpbQzRgKUqti4MDeh3T6YofQptf2mHwxT//C7Z9p2Sf58t p+vkDeC75PNJogekvvHP1jf0zRiigHzfn/ZJI4IXPR91wy/rnYBfxuwuWvlp vBc+HtW/Oz23/xOl5/La2PJo62pz2kQ3m+TaTOq0bqSNKf+3sjbBJrrZJNfm vA01Uxpb2nJdafDumUiasVSXsqVb19XmtIluNn1CG1MKd2VtbqdIUEpKrEtN P6RB0pQaiW1Z+W/UBuQZRbTRH65G2phOE1TWBuYNiLTRH5LF2hhOQVTXZreJ vmBuV0SbvlS7QdHxT2pz2kRfMCvtHZ6f7dRJZW1g6otwxVBKG9NpmcraBJsI ZwK+w72JbDB8ThuYoSSbw39Ig6RxBZuN4cBTdW12mwgndUaH4h/a1G83pkNs 1YfiOWiDUnXf4RbbDt9V1gbmZlZyi4dSZxFFjHUP6QyYrRfbyfrqHxLS7xWx QfRHUKNHNwf10c0heeBKVJiV7m2lGUVfmjLcWhjORH2+/tvvnYjJ1B/qI0YN gmtgacT0lW7Fb9rPTnM0+9kiEOz7INl8vEbTQiCQZ1WBBK7dVt5SLfkkKk4C gyev3dwWB4HEUpYU6aznbua8l9swfr9sEu9m+iN7KLKdKbpx+eJvVRd2FO7j EWvAYu0U30z2oiuP73zfbCPPwd/uBszhixJJ7vzuVs994sppAb+XbScP7/Ys hz+RZ8lrY/TO6opzGUV4Po+t14KX9UOcV3G2BV4RcUwud21xglGE3bRYv9J2 q7nYEkQIuV1afI6sf0oIDc3sLojvq0Dm67Levm36Kl/ibreXdtOeCvPnhFC/ ZxdvkLHZ7usoDZmHPb1sZfhJ/Yh8dKU+q1fqc3rBKyzN9Jl3lea6kqI000fk pbl2+a7SXHMVl+ba4cvID53d+RYZ4EbL9f+IRwaSt1pkI/pWgWCH4zSCNAhu ME4jnALBjpJphK+P6BQIdhhOI3o5gh2E04QhTVDcfHA1a3pu1u60IvcuBp1F Z+XSc+V+yqKzLdBzW/iQRWfToeemozYo5i+8KzolAGmiU0ISdrAZELWhM5Yj ofOnFVD8Ry3NSHWQzf5NGSS0RgEn2RzpDroKSKieclBgTQRIvtOd7heQ0MPC GajI8ogjkfJ5TwEJ1VQFFJBvmorL9wDXf2Sg0BqTl8+tT2cVJj34U/4ZKLSm 5ScOT8rdpzQITFE8KeIHXBH8/noBap0Lw3KAjeCPx3NMkQh+J9lBuPOH/SeP 8fA8bmXli44jfuf72xxzxuetfNFxxBt/+Zk7P/Fq5ux2hUoaMDbD2QC6/bgj NMC3qfOYar5rd9G3zjvvkyPkDy51HtWLzmPe+e7KKF74W9Q8h9/KtrDmtwfb 5z9RsB2JY4pX1xYHLm5F4mzvTf0QhxdnKNVybJsQlcU5jSIciouIs70+VUQc 0+ZJbXHm66lDFESMtRxXSBzbfkxlcXD4SiTOVKpb/U8UZzujUqRbmTbZancr GGYUiePV+ShAHdvuYF1xcMRTNh7vZsq1ISq1WSpjTPu5va090n4PSHGGu3nz R75dacZ0X7L5ppMNOjrGOF73pAzj/sB3acYwXMl7C6/tajDm60zgUjd9jXa1 LIq22XljzNLz8TpGf3tUd3Uq5yof0u13U2yQ9eqfYpk9N8h642ioEfJLU67R fLvheJN+g8wFX0j8Xu9nuiWtE20VSNfMwcNYb5DzNSp+pIamEzI1na8B6RoX ugktn9XK/AHl2Oiv8ZfGvk5nHKdrLqXR1/mSob9V/HoLWlsDMl1nX2mZH6ca Fb+4Wefa07Xzvu9WHOKvOCqFvPjSEHevkzlc1lsYQse12btcdFzQVxrSXvdP uGU+0fb4WHbaglFmpx0lkCMoL8x4ePLCjOsmLsz5ZOLCnLMlLsx5UfLCjHsk L8z4PeLCrEMjR3Oeirg064LIS3O+hUa0V6dB892v3oC8nXHTvLw0N3/LOwg3 McvZ3IwrV42bSuWluTlS3lq4yU9empvVxKXZ6Upcmp2H5KW5CWYtLUo7Jboy +LhV+wqIZ/CNCgK3Zk8TJjmBXbGnCbOcwK7Xk4Tz4VUBgV2tpwmkIHBr9TTB KQjcSj1N8HICv05PIzo5gl+lpxG9HMGv0dOIQYFgV+hphKJf8+vzNELRsfnV eRqh6dns2jyJOP0KCYJdmacRir7Nr8vTCEXn5lflaYSid/Nr8jRC07vZFXka oend7Ho8jdD0bnY1nkYoeje/Fk8jFL2bX4mnEYreza/Dk4jTi4wgwlI/svGz /i/RzXugZ+8hxB6yc+91Bp1z3PrT3+e4D1l0DsP0Mgx/yKJzSKWXIfVTtTZd t9Y9jV0fsujsXvTSvdQWxeJqb0qQFYBUCbIyEtg25e+B8V73yo0ABHKzc0hg l5bPl/bL0K85gyAAoU+yk/CmMJdC732rOisiAD18aRLag3aghc9W7RAIXBOV QYpseXOgrrW2cAQCL4jlkMAOO9DujKwXA6FayiCBDX3+NJR3umdBBaAHfxFa BgnmD7TgeJzqdJwEBMYHOwlmK/Ag3RvIEs7j6DOlQDAzAkzpvbNKB0loeMhA 4UwMrpa61jq0QhA4hGcnwbwPHrSGhQqDQDVlkFCWCQ9ahtbSIHDZn50Uy2lh QL63Dq0QBD4pg4QzaLiGVwH0KE2K5OuwIKd73FlCQt9kR8XygxiSm3SP7EpI 4A3SDFQsH4mTr+us8kESWmJkoFD+E1rcdmZvBZGQ+2pHwXwr0CZ6s6MMSY/D qyuIQvld/KTrnO6IvYQEDr5noGA+Gf8OvBt1NzxISMvox9aUHQXz13j5vGut QxIkITc2A4Xy5fia8m4uTgJ+LI+KhE/Dyd9lDT2Gdr64WedJGP7kNfVt49fq w0d/3Sw4enwzYJou97ab91eB8wyQXF98M2D5xVOBxforXg0s6I7ld8QCyQXG dwv6xp1OyTKNbZcpYwvWxXVZA4ZhD6SEudYlKmFZLH6LludbsKxFhzAyubbf fWlsweKVpepAconzzYBlUNjcpn1o7JNPMnva+1vEAtk1zosN7z0adgD/HEfD gDamM1yVtQk2Ec5Qi2pDhbQxnT2rrI27NilRbl1Em64J2RmZ2tjOzNXV5rSJ cFZgRBsKKR+Z0tiO+tWVBickyKRpy0hjO6FYV5rTJsJ5mBFp1C8KQm1MJysr azNfry2iDNKINnMxbUwnQitrE2winPsa0UZ98B1pYzzJWlec0yi6GyVXh5qx jDrGI7iVmw7OxhKp0zYhdTBTHePZ4brqnEbR3Si5Oq7UqGM89FxZnWAU3Y2S q1OuZ9lOa1cflM/XcWCKelSdtpA6tmPm1ced3Si6GyVXpy01ZxnPx9dVJ5KR +mZ1bAf7K6sTjKIvfKbhHeoYbySoq04kd/jNbcd2lULlthOMortRcnWKRbuM d0BUHpX726iMDsFE/Z1Cbcd4eUVldXAO/Ju9QdutG3XVOY2iyNGj6Cq0lDq2 60IqqxOMortRcnXIlRHHeM1JXXHcfdhB570i4sylhh3j/Sx11TmNoshRtWjH KrREN14sU1mdFh4DqhMYbMfzpp25u+7Xnqb9+uy0HoLbfG6M7anMc4GyVP8g CxuJrvNZOMrrfI4S6OvFhfnPeqkGtMfbjucxS7YSnur/9ZRlKweAGkgiKI1Q HHc7P5OePzOMUanTbi75hpLKoEsWepFFbVKsK5zpM6i78Tn0br66vSBNR8B5 hJSAYiTcuflTIjVIIKGKRUVazvnoQNvuDy2soHlsphDY4VMu1lcXVn1xxkXX yV4dGPlJyzZGC+asA2iZs3BfFk1Zo9bdQdpY55a66sQGlupTej82FPzjmY43 W5KC6Kb0vt29lKOHDL2OUW1C575dXpj5KMt0zlbAU91nTees+kkApQGKufP8 SHr+SOnM6ctO5qco9CyK2iDRdIS6GTgO187Nfp+Vet5DIHSWPoMEejU4A1Ae pPokwUze+ysfbz62ayIT+doo1n8lMpOPWTO5bWiuO1fhjiyaqbpSM7ltSqms DRxT6kTabzPsY42ZBMfG98fLW0k9dNP4w/VXkNpPTVcF4t3+wyvETY1Xrv6F kLnxJ2TenzX6I3gkbD3KS3MVJC/NKa8ozUhq8Yf4ptym/JVWQWDbcZJACgLb iJMEpyFwLThJ8GmCwom6qoqeqyoMDSkvqivr1l3C07PwaotEvkls4F1/+jnI MJE1oAFJ6ChfBgoN9Lxr57pJdUBMQnqAU4MZKDSxAPm6weqvQhI4HpuFAhMZ OnSpu9BDQkLhNDWKd/SMnk1dTy8y8IlcvaGUG2x0ySqrcxpFeH4t6wgDdWy+ ZGV18BRVJ20Aq2NygmurE4wi7NfE0ga06pArtiqQQTp3nRkovPRYMMqlx1Ei 6sDLSnOf9VIN8ASruxxbVp+nBvDq2HZpgsaNPI14aYVhgC3gRpJ71zwuIRWa x++oSFNnSSGIVo4E7hngUZG289sJavdH059bJzjgHTg4RtiT7Hy1e/cgfhD/ FIP4J+JHl9vlCj5kd4d0XTNRgHTHdQZlZoq8IFV2oOhFO3lpThTxPJMfomk1 BK6RJAmkILAtJElwacJ7Qy594SDQKQs9y6K2KNZT0wt+MNGtqdQb0lUPLeSg wBgHXJK5U12yJCHBj7Kj0JgKPmqazfIhEvKzWJRg1/Lhx2YMvo+n/V6hiEuy npdebRG6JBILlk+96q9rKGwKAguWL52nuAUua+P0x7o/ro7Jeam/7r9iRmCy fIs6Nq+rsjp4RhM61Np443zlfNd6zf7O6JsxMNbHHcoloV2M9X6R8WA8hoKv wN8Zfq+FjUFDwedu72Itc1UfIMvgXzAL/waZ91rYIZP0kiEdhFrf9GGcfnR9 Hb1omWP8KVg37teqlKfQdU/Kox/3Dyuv2Ljfq7e34lZ9OEJI6fZbQ/ZvmaU3 d+go07TffrdBxn4/xFsc4pop5FA9lr8MyrqPLqJn9SJ6vg6TqN+Gvhdmxktx YW4glBfmRji53dzQJS/NjUni0vxgIy/OjiKK4tzwoDCe6/eK4lyHFhdne6q8 NNcFX3wRuM6Yr4NPnCeyfl1exOYG4NyQJIDkANYHSQKcAsA6IEmClxN47yNJ 6BQE1vVIEno5AfgdScSgQPBORxIxahCsx5FETBqhWHcjiZg1CNbXSCK2AUnI 4D2NNELRs3k/I40Q9G1F5BPfbBuc0VTgc0iGYnUGhb5ML335QxZdvYZees2n TDq7AL10gQ+ZdDZnemnOaotifvoZLtW9NUkT6eKyaRA4TJJDAkGNln+lbFaG mtMgED7PIKEYCojTt8rNhzQI7QhkkFDIhg/T09iqHsiQkEACbwYKhog8TyLl MWsBCTW+DBQKSQH5nO4hJwkJ7N1koHAIDOjnlMfoJCjUADNYsZgb91md7jUT EQq8G5XFigT5GJRbJC+OQs9hZbAiUUV2W3SY7e0dodDQnsPCYUz+szp730Io dDrDzoJxU/5FMefI2i4gCbwGmINCcdpjX+uZtPg5xgkfktCRExYVcbPDtvia OHmCaLruUkYv8hyi4m1x30o25i8L1qtJBhdM8PN1XBc9S5Q2QZauuBjB7q5W ew7mAFo2V9/9HAzUxrQJWlmbYBN9wYhoRJuulDa2zdu62pw20RcM5kYzFkLE Mlcb26ZzZXGCUXQ3Sq5OuV5l2y2v3K2CUXQ3Sq6O/hoFpI5tm7+yOjhoKFJH fSkvUsean1BXnssqulsl14dK9S1rZkVlfU6r6G6VRp+ulD62nJDa+uAIuLB/ tYX0MWaz1O5fwSr6wpte0Zm9mD62PJza+uDtCmH7oTL6GDOI6spzGkVfeLMx qs5YSB1b6lNldfDGkkidVv2ETvuOFL1vFL9flL9Tlr4i011JcdN1k+X6lu7+ 5HFpinfXlWiPbvHLqnxLR9djT49+8W6oEqW9KP1+aKI8Zb4e53wMk/QRECWl H/ZDlYEyVamXpVkNp2IjlTwQf6MM/hakGo+73xWU6In4Vn0ivs3K2ftWnBsI 5MXZHi4vznZdeXG2T6qKv3Y2RXGuF8mLs91DUZxr9/LibIN+mbJQ/Jba7Ayv VoNgZ6skghQIfqpKIpwCwc9TSYRXIPhJKonodAhmhkoieg2CnZ6SiEGB4Oem JGLUINiJKYmYFAh+VkoiUpmPC+LNyWpjKjNMadLZSOmlkX7KpLOu6KWu1CbF fBbB5vy42/i0h9jp9kVFJLBfnoNCC5eZJY1HMkxJEvioDBRcJ/EPTgydal9Z RAIJGxkouCxr2WSDYVadlxeR0EfZUbFVIENa5xlNBoUIhVKG8lj8spNvgBR2 zkqiUN5aDgutc4GCrrUriFAwHc/Oggtr8FnKdEYR6gFaRg4Lr+S5nJd1LCuO Qn0rgwVDB6i2dBeHiFAoeZJlRRyeM2lnvT3z6sVjM6yecSRppz2SeiNJO06Q N3Q3YR3uzlF/aZrn440odcntYe6ICV52zVn79p20A/nn2EnD+tiCzrX1CVbR 3apP6GMMl1fW57SK7lbJ9aFmKqSPMdBfWZ/TKrpbJddH/8Qu0se4RVFZn9Mq ulsl10d9D3VMH8vmSn19UKzi3e3Hti1UW59gFd2tkuszFtPHuKFVWZ/TKrpb JdenL9a/jFtxtfUJVtHdKrk+U7H2Y9xErKxPJDBZq3/dMgT8npmzWthNBS/V +pYg0F7XDy8DbC9LUNLmOiwL4i5A5oIXXn37En/dGThOewZYcUg4YLFC1oVb uduJv1Fu2fLz2LgqNd9Pl15bSliVTxluD9SvywlXhzLdqmVZ1GlfKJVRlgGg H09KuydClacM1/2F1M7qxKB66RTcgCQvzY00CjYzhCjYzNggL812ekVxpjcr SnPdVF6c7X+K4lzHkhdne4yiONcVXmZTUQoDN5eu/0exPAx2Ik0SSEFgZ9Ek wWm+gZtCkwSvIPDzZxLRaRDc5Jkk9BoCO3MmEZocDH7aTCJGDYKdM5OISYHg J8wkQpCDcSHY2TKJoDbN0GQwnOMLPY8v7rQinsAwFc6pOPsyPfflT1l0dkx6 7pifsuhsPPTSeNQmyXah0JqO3+/qBnsyAwCBvckMElpBgse91yh5YRLYRs5B oRUrIHWdeQsUkUBF5aDQCpmvKTfu24YFQeiKEDsJrsf5ipp0l3aISODisRwU WP7z91uMzq4eAIGbNHJIKNiA7uywi4dIDz5VIgMFYxstm1GQkQQHSeCjclAo lAJydRaJrfmKEAXaXw4Lxm7aPcvjBTWqbi0SoUBlZbEiwSIORUN51OPI1hKx JNkrvr2OhQ7HFWY4ecW1+7U4wmt3Yh8L9iZsgfjKWxN4xSHamaBSG1u2DYTK 4pxGEQ7GvGVb1LbzUbvpBKMIB5Leoo5ty6Z224ELZ+GWcSl1jHtNtbeMg1V0 t0quT7mUDNsuWW15YJBDNiw3IUpYIOGA94M/K890dS4YOn2LPsaNycr6nFbR 3Sq5Pq4J0fhsfWxbqrX1CVbR3Sq5PlQsoce4GVxZn9Mqulul0YdK6WPbxq6t D474ivTJur7kLRkqnvb3OzfIMoB0VSDH85cbxFXKgunc/k5iWAZW+ZL1YcYA WeSqkwSzpmmeddLXSk3yV4bhRPsNauUh035b3fYlS53IOrU2m8c1FIbWyTVj FbmGxTmjC1Ipl8dfcs3LV7kqkL7x3QEh5/bLcItT1isvQ5en9SriGt/i2sX8 0IjX7G9hGqiSsiyAt6DfRllaW19jaHF+uN8HPO6hy+KUdT/oVGyZVeYavcUN /T407oqNzVAjJdGtVXHWSz/vd6wWp6zbGGd/6fq9wRWnTP4aX9aZv8pE7Oah oatXVroRzS0LWfKBsnaeKrU/9Zfnsvr21Nag9N2t77dU8D3kb72SLu93DQNU aWJubtog2NxV6i3LhHJe8blMYa5KpdDSwCY7pF7Ka17iKOeLK0ozTra8NOc9 K0ozbrGiNOPvyktzjqyiNOOhyktzrqeiNONTyktzzqKiNOcFyouz7p24OO+3 yYuzDpm8OOtpyYuzLpS8OOsbKYpzTo+8OOvNyIuzboq8OOt/KIpzjoXCeM5j kBdnXQFFs2HmeEWTZyZvRWlmVpaX5qbbtbQ6rd6WMN5qCFw4K0kgDYGLZSUJ TkFgA1lJgtcQuChWktBpCFwIK0noFQQ2fpUkDBoCF7xKEkYFgY1cJQmThsCF rZIEVUY9F7NKEs6hV4RgI1ZphqZb8/GqNEPRsUG0Ks1QdG0Qq0ozFJ0bRKrS DEX3BnGqNEPRwUGUKs1QdHEQo0ozFJ0cRKjSDEU3B/GpJOP0FSQMPjqVZij6 OYhNpRmafs5HptIMTT/n41Jphqafs1GpNELTzdmYVBqh6eVsRCqN0HRyNh6V Rgj6eAh5SY4n5R/hmkvfHRy8QHr2Aj9l0emt0LO38iGLrsl0M+/bZPopk845 i17mrE+ZdE4/9DL9fMqkc7ail9nqYyqFiYdeJp5PmXTOIfQ8h3zKonOwpufB Wm1RbLfCfI6utV9aqj1Il4MCeUPoQuW2OAne3ZyBwnlKHIluuV+FSOCl7RwU yoviD2gtzcZ8oTcAoUNnGSSQhdWyB+l6Zz7Xi0Dgk3JIMOeLBXXmo5UIBO41 ziChDDMelHNaFIDwaceMc6lsPhs4Pnx05oIgUEsZJJQ9xx90HFtzC0cgVEsZ JJirx4EGKg4CtZRBQpmBvA9Bk7mFIxCabTNIKA+Rv8nAHYuSkiTwURmoWNoj Q8poEZAEboKwo3CWJT/s2R86wSTgF2WgYFInuPHEWb0VTAIflYGCOaR8TfWD 1avEJNCnMlAwZZWvqXmynlnHJLCAykDBDFkwog/m6RCjHvzrVVksmJLb8qzR fO8JZqG5KoMFk4DBNRddZ3XIMArcHJPDglnHfHvPuHoCo9CSN4MF05zBSzuu Mzd4iHqgFp8Dg4nVgLVYV5yFmmEGC6ZyT7x/5s2LUowCn5XDgrnjjr9aqDcv TDEK9K4cFkpW5xc9ru/Noy4iIb89A4WT4/mqMl+rBklg0ZiFwsn43EcNrXnE RSRwNVMOCiX/H1usz6SxNc+OiPQ4llIiVGTX4rrByF2TyLJY7bapsf1CNxj5 Zl4bivAGI4kBy5KjO4OC7f6ICjbA034hTEEDFrd026lZDZj8dU4fGLAMXlPc AFIaEEKh+3RHzXp0JGLBMQCVe4PNdcP+TZsBy4JqnKIGEE3JZ+C80oTF89wA mwmL55kyofNNl6iGTmnCTNcFSOT7/TkxbMJI+yo0YkGvtGBpfRRa4rrtkmgI 60SaqodB2xT8/vLVMe2dr9BgC1I3mo15N5r9uHgpqo7pCoXa6tCVCoAS4SPq lHupx3b3Q211glGEk/gj6gzF1LFdWlFZndMowgcQIuqUu/DNdttGbXWCUYQP T0THnb6UOqZrQmqrA1P+3jwq2+43qazOaRThQysRdbpibcd2MUttdaYrORMd uHnLqGy7UaayOqdRhA8LvaVn2a7Cqa3OeCWIooNO0Z5VSh3bHT6V1cFpz2/u WcbLh2rLE6yiu1Vyfcr1LeO1SZX1Oa2iu1VyfeZS+lgvfKqrz2UV3a2S60Ol 5DHeVFVZntMqulsll6eY22O9Y6uyPpEjIG/uXsbbwSrrc1pFd6vk+hTrXsZr zSrLc1pFd6vk8hSL9VgvZKutDz7O9N54hvUqucr6nFbR3Sq5PsV8Z+sleJX1 iZw9E+njiuljvL6vsj6Rg3AifYpd8W+9eLC2PsEqulsl16fc+GO8MrF2/8Kn Ft+sj/Gyx8r6nFbR3Sq5PuXmd9s1lZXlwSdM39x6bPdrVlbnNIq+4AUL74hs GC8Gra1OMIqezwLLFhbF1LHdaFpZHXxSupbf8+bbfb1v91Sq3WFom8nVoHTT vpexu21zs130Upyy9O4rgainOg8gdM5f2/lrWLmtoVi3eEndRen3SipPmfYU p40ytXsyk4JS7R7hzJsq+WYtL862V3lxtiGKi/MtTFGcazqK4lybeBnDKt4C 1coRYPhKIkiB4MeuJMIpEPzAlUR4OQKMWklEp0GwQ1YS0WsQ7HiVRAxpxJsv maG27J0ul/j0Iv7nbAq1RS+1pbcpNqEJDrfwZ1vsN3BEjtHwR3bsKOyj8ST7 OWdMKn6eH7uEPKmfrS9ZYxI4J56Bgh4of8508NYjSJiEasqMwg4vqKnWKh8m odtmMlDYv+ZIfrDLh0jgZFAOCrnzfE25o1WWJIGaYlGi4xDtFVIicg0F1wgc hziGxHJnEfwwXyeDttRXilvQJy0YdRZ0NOyvlW8WrA96hvAnb0Hvk+cxpqzT ED+i6HF9rEGVuvpcVtEXXitF9CmWZGENB1XW57SKvvBC7x27eNZAVmV9Tqvo C69S3xFJt4bg6upzWUVfeIkdjaWHpXC2PrbgYW198BJVGE0vpo8t7FlbH7xc Fo4/an3e/C6ib7vdedl9KaoT1fbrM9V0UsbjMHdxypGGt1MqvSPqabyS6anv mr7Kzgn1t7SsftyPd5WnLCub/qTMdd53XRXbQkq7tzwfK4bSFOea0QfKuHhW Veol5MrslHl/qr48xd9a8tSp34+utwuU91oaP9woinPjiKI4N0DIi7M9X1Gc 69KK4lxfVRn/2gnlxdnepSjOdRtFca4/vMyrkh0w43surRwBptQkgjQIdj5N IpwGwU6mSYRiBwzMpElEp0Gw02gSodgBA3NoEiHYAbsLxUygScSoQPCzZxIx aRDs1JlEzBoEO28mEdSmGZrtyALPcBCV3fq7egK99ISP2XRWF71Ul94mUZgc r6pK79zpb2HM2LqLrOLYXRpvvekMk8DeSQ4KLxo5kv3ab0wCW3c5KLRGBRtC 5tdQMAltCNlRkSUxW1PmW1QxCdVUBgqtwHnSYFcPgdAF43YSWu6DG4PtzRyS wDCRg0LRBb6e/Gi9nh2TQEVloGLBDIbUDeVJoEfloFDshG9+fmk31s4LUeCr sliRYA33Wd78QABGPfibRnmWZI+dutuGcn9cxRnZ4R72zZWCu/xLb7vtsc9H tUELOtWFgxIDlgnxGpfHxZsLHjNrwDpyp24gzbvy8MdRy7g+1r2Mypu0p1V0 t0quD5XTx7YLU1uf+XaUGcWy3rFJa90/qq1PsIruVn1CH+POV2V9TqvobtVH 9LHt2dXWBwd+hPq4UvrYdhtr6xOsortVGn0K9i/LPmn9/rVbRV84+BxNEmkL 6WPc4a2sz2kVfeHI+Xv0se1N19YnWEV3qzT6lOpfxl312vrgILhw/AlbSX/U JKM1ZfzquN28/6U4xXjT0x8+aYKXT16c1eWlvfwxNs9BU0kiSIHg20kS4dKI d+8RusLP0EduJdPbJIpo4QGIf+3Ne/OpqciGHH8UMYuFRjzwWcsi2PpKFESh UGcGCw6x4KGyqTef5sQvKRKvIQ8TBPrc7G9+0/rQSTTQ9yBBsFP9wkt7X1r7 6z4uYMJSh9s1KAWfuRmG/XzFbsJ0XVpkN8H/iHe++msFr5azuVW19QlW0Ree wcsmzQN9/mde/am/Oo1OH3ny+/J0XyH2x/yQVETiiF+Q+RtkaMahAmQ9Tjid g/bcN9NUhbL07+mguLZrXJVv8bfAoaPp2GwrTekW3y0sf9f7r+tQ+rZZZ4Sd 4p16RRldhZF6FUbnOoht++LSbKMWl+Zbq6I41wzlxdn2JS/ONhx5cbZFvIxf 0EWhc+XGj17rX/KWnxeBH7qSBJITwLiVRDgNgh20kgivQPAjVhLRKRD8cJVE 9AoEP1YlEUMaoVh1n62aXlp1GDqTi26fDASoTLq0pxftP2bTWVn0Ull6m2Jz 2bkGjXlL628/LUAn5fvBAtCDz4yyk6Bvxq+p1/edCoPQbThmEvYEQaxlurzr UiR0cUwGCjmeniV1Xpc7LiE9+CfhM1DQz+Xl60h3mZCE9Agv4RRDQbea77vd ESorSUKpmnZUzItnPqqf9gosSUJ3gXGoyBQT4lvT7XXBdYw9XTs+vLUMsVvW Fo5uuUkSYLsMIOebIVjg1qyeLmpB73aDIxbMsvga8fERYzBAEh4hc3gk4g2J oiOtOnoE1DFGMeqqM39TB6xPisYegTrW8EtdeS6r6AsvrqL6jKX0sQWOausT rKLIyvAt7ccY8qqsj7/lysFlbTQ26wrpYwzWVdYnsi4U6aN/NQ/pYwwzVtYn skYV6aO/kMv/E6+h03JIYrsXob9tELo9abI0wjc+1Cr5fawqjXD7MY0NQY1X IqLhaa8OT/szTPpafeKiTL2IyzKCi8sySr40XegY+zMMxzTc9nuPMcR0r5/n Wm3y90n++1yTTf6+k/8+116Tv5+M5XpN7C38K9cflXG3LhkLVNkTJKFnSfQG xYaMc5EKh9btj+eQsaehkC67JkUBIUA7BoziKN9KeVgxyUFnZe0gMGcA3bpZ l5KU5IAPygCBGarjOe2sCzImOSCapAfxrpvFT5G4bd7stqHhrdKSEehi8q7q ChNMoi84dUZDMYWUMTmFdZUJJtEXnPQjyszqZRBQxuTL1lUGzs0iZSg4Lt+E Wf70j1/+Nfzlb//766f/BlBLAQIUABQAAAAIALuwcyg7CcY4Xy8AACqIAgAJ AAAAAAAAAAEAIAC2gQAAAABHMDAwMi5keGZQSwUGAAAAAAEAAQA3AAAAhi8A AAAA --401825-1025186760-953558326=:1784828741-- From Mike@vodafone.net Mon, 20 Mar 2000 21:06:29 -0000 Date: Mon, 20 Mar 2000 21:06:29 -0000 From: Mike McCombe Mike@vodafone.net Subject: svx2dxf and CAD fuer Hohlen I had some e-mail correspondence with Thilo about this a few months back. My SpeleoGen software seems to be along similar lines in that it reads Survex ".3d" and outputs as DXF. However, it seems "CAD fuer Hohlen" needs the DXF structured differently. Thilo kindly sent me a spec for the DXF variant, in german, which I couldn't understand and, as I was in the middle of moving house, I lost the plot. I now have two sets of code which must both be very close to doing what is needed. One (SpeleoGen) is in C++ and the other, more recent, in Java. Both of these read .3d and create output as DXF. If anyone would like the source code and/or a copy of Tobi's DXF spec just drop me an e-mail. Much as I'd like to do it myself, I've too many unfinished jobs already!! Mike ----- Original Message ----- From: "Wookey" To: "Survex User Group" Sent: Monday, March 20, 2000 1:18 PM Subject: svx2dxf and CAD fuer Hohlen I'm forwarding this to the list as I don't know anything about DXF myself. Thilo Mueller uses Survex and CAD fuer Hoehlen by Tobias Bossert, which uses AUTOCAD for cave drawing. It seems that the current 3dtodxf converter does not satisfy it's import function, which requires the data in a specific manner. It would be nice to support this, so if any of you who know about this stuff/would like to fiddle feel like a go, feel free. I've taken the liberty of attaching the example file as it's only 12K - hope that's OK. Thilo or I can help with examples of the same dataset generating a dxf using 3dtodxf, and Thilo can get further info out of Tobias if required (Looking at the file I suspect it is?) Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ ---------- Forwarded message ---------- Date: Sun, 19 Mar 2000 16:13:02 EST From: Hoehle@aol.com To: wookey@aleph1.co.uk Subject: Re: Loser International In einer eMail vom 3/17/00 8:55:45 (MEZ) Mitteleurop�ische Zeit schreibt wookey@aleph1.co.uk: > Good. Can you check if CfC can use the DXFs that survex's svx2dxf utility > puts out? It has been checked on a number of other programs as OK, but > not this. If there is a problem we should fix it... Hi Wookey, no, that doesn�t work yet. CfC expect the dxf in a very special way. So the dxf defines all layers (and there are some 40-50 in a sigle cave I think) and some more information. I�ve added a dxf from 115 as Toporobot produces it now. Cheers Thilo From benchoff@vt.edu Tue, 21 Mar 2000 12:35:54 -0500 Date: Tue, 21 Mar 2000 12:35:54 -0500 From: Phil Benchoff benchoff@vt.edu Subject: More on xcaverot vs Digital Unix I posted here last week about some problems I was having running xcaverot on Digital Unix. The buttons (including the tilt and rotate on the right) have no visible text. They do work. Labels do display if I turn them on. My suspicion is that the labels for the buttons are not displaying due to background=foreground or some similar attribute problem. I have a working copy (including the recent patch 1) on a Linux machine, so I know pretty much what the display should look like. I haven't ever done any X programming, but I played with the code a bit to see if I could get the labels to display. In the process, I used xrdb to set *foreground and *background. That did not cause any changes when I started xcaverot until I ran the program from an xterm that I had started with the new defaults. The labels displayed once, but tests following that didn't show the labels. This is really acting like something isn't being initialized. ( I know that's not a very useful report since I can't reproduce it. ) Anyway, I decided to see what would happen if I disabled the double buffering code and added have_double_buffering = 0 right after the test. I now get labels on the buttons. I don't have any man pages on the Xdbe stuff, so I don't know what else to do. Maybe this will help someone figure out what is going on. Phil From mrs30@cam.ac.uk Tue, 21 Mar 2000 17:42:02 +0000 Date: Tue, 21 Mar 2000 17:42:02 +0000 From: Mark Shinwell mrs30@cam.ac.uk Subject: More on xcaverot vs Digital Unix On Tue, Mar 21, 2000 at 12:35:54PM -0500, Phil Benchoff wrote: > Anyway, I decided to see what would happen if I disabled the double > buffering code and added have_double_buffering = 0 right after the > test. I now get labels on the buttons. I don't have any man pages > on the Xdbe stuff, so I don't know what else to do. Maybe this will > help someone figure out what is going on. It sounds like it might be something nasty to do with the X visual selection. If you have such a program, could you run "xdpyinfo" (probably /usr/bin/X11/xdpyinfo or something similar) and mail the output? Mark -- Mark Shinwell -- President, Cambridge University Caving Club Queens' College, Cambridge, UK Mail: mrs30@cam.ac.uk Web: http://mrs30.quns.cam.ac.uk From mrs30@cam.ac.uk Tue, 21 Mar 2000 17:43:25 +0000 Date: Tue, 21 Mar 2000 17:43:25 +0000 From: Mark Shinwell mrs30@cam.ac.uk Subject: More on xcaverot vs Digital Unix -- PS. On Tue, Mar 21, 2000 at 12:35:54PM -0500, Phil Benchoff wrote: > I posted here last week about some problems I was having running xcaverot > on Digital Unix. The buttons (including the tilt and rotate on the right) > have no visible text. They do work. Labels do display if I turn them on. > My suspicion is that the labels for the buttons are not displaying > due to background=foreground or some similar attribute problem. > > I have a working copy (including the recent patch 1) on a Linux machine, > so I know pretty much what the display should look like. P.S. I meant do xdpyinfo on the Digital box. Did the problem stop when turning double buffering off on the Linux or on the Digital box? Mark -- Mark Shinwell -- President, Cambridge University Caving Club Queens' College, Cambridge, UK Mail: mrs30@cam.ac.uk Web: http://mrs30.quns.cam.ac.uk From benchoff@vt.edu Tue, 21 Mar 2000 12:50:48 -0500 Date: Tue, 21 Mar 2000 12:50:48 -0500 From: Phil Benchoff benchoff@vt.edu Subject: [SURVEX] More on xcaverot vs Digital Unix -- PS. On Tue, Mar 21, 2000 at 05:43:25PM +0000, Mark Shinwell wrote: > P.S. I meant do xdpyinfo on the Digital box. Did the problem stop when turning > double buffering off on the Linux or on the Digital box? Everything appears to work on the Linux box. Here is the output of xdpyinfo -queryExtensions on the Digital Unix box: name of display: :0.0 version number: 11.0 vendor string: DECWINDOWS Digital Equipment Corporation Digital UNIX V4.0 vendor release number: 1 maximum request size: 4194300 bytes motion buffer size: 100 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 6 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 12, bits_per_pixel 32, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x1c0000d, revert to None number of extensions: 20 Adobe-DPS-Extension (opcode: 0, base event: 248, base error: 255) BIG-REQUESTS (opcode: 132) DEC-XTRAP (opcode: 136, base event: 83, base error: 137) DOUBLE-BUFFER (opcode: 135, base error: 136) DPMS (opcode: 134) DPSExtension (opcode: 0, base event: 248, base error: 255) Keyboard-Management-Extension (opcode: 137) MIT-SCREEN-SAVER (opcode: 138, base event: 84) MIT-SHM (opcode: 129, base event: 65, base error: 129) MIT-SUNDRY-NONSTANDARD (opcode: 139) Multi-Buffering (opcode: 140, base event: 85, base error: 146) SHAPE (opcode: 133, base event: 82) SYNC (opcode: 141, base event: 87, base error: 147) Shared-Memory Transport (opcode: 130, base event: 66, base error: 130) XC-MISC (opcode: 142) XIE (opcode: 143, base event: 89, base error: 149) XInputExtension (opcode: 131, base event: 67, base error: 131) XKEYBOARD (opcode: 128, base event: 64, base error: 128) XTEST (opcode: 144) XVideo (opcode: 145, base event: 94, base error: 156) default screen number: 0 number of screens: 1 screen #0: dimensions: 1280x1024 pixels (342x274 millimeters) resolution: 95x95 dots per inch depths (4): 8, 12, 24, 4 root window id: 0x3a depth of root window: 24 planes number of colormaps: minimum 2, maximum 6 default colormap: 0x21 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store YES, save-unders YES largest cursor: 64x64 current input event mask: 0xfa203f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask ButtonMotionMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals: 21 default visual id: 0x31 visual: visual id: 0x22 class: PseudoColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x23 class: PseudoColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x24 class: DirectColor depth: 8 planes available colormap entries: 8 per subfield red, green, blue masks: 0xe0, 0x1c, 0x3 significant bits in color specification: 3 bits visual: visual id: 0x25 class: GrayScale depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x26 class: StaticGray depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x27 class: StaticColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0xe0, 0x1c, 0x3 significant bits in color specification: 8 bits visual: visual id: 0x28 class: TrueColor depth: 8 planes available colormap entries: 8 per subfield red, green, blue masks: 0xe0, 0x1c, 0x3 significant bits in color specification: 3 bits visual: visual id: 0x29 class: TrueColor depth: 8 planes available colormap entries: 8 per subfield red, green, blue masks: 0xe0, 0x1c, 0x3 significant bits in color specification: 3 bits visual: visual id: 0x2a class: TrueColor depth: 8 planes available colormap entries: 8 per subfield red, green, blue masks: 0xe0, 0x1c, 0x3 significant bits in color specification: 3 bits visual: visual id: 0x2b class: TrueColor depth: 8 planes available colormap entries: 8 per subfield red, green, blue masks: 0xe0, 0x1c, 0x3 significant bits in color specification: 3 bits visual: visual id: 0x2c class: TrueColor depth: 12 planes available colormap entries: 16 per subfield red, green, blue masks: 0xf00, 0xf0, 0xf significant bits in color specification: 4 bits visual: visual id: 0x2d class: TrueColor depth: 12 planes available colormap entries: 16 per subfield red, green, blue masks: 0xf00, 0xf0, 0xf significant bits in color specification: 4 bits visual: visual id: 0x2e class: TrueColor depth: 12 planes available colormap entries: 16 per subfield red, green, blue masks: 0xf00, 0xf0, 0xf significant bits in color specification: 4 bits visual: visual id: 0x2f class: TrueColor depth: 12 planes available colormap entries: 16 per subfield red, green, blue masks: 0xf00, 0xf0, 0xf significant bits in color specification: 4 bits visual: visual id: 0x30 class: DirectColor depth: 12 planes available colormap entries: 16 per subfield red, green, blue masks: 0xf00, 0xf0, 0xf significant bits in color specification: 4 bits visual: visual id: 0x31 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x32 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x33 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x34 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x35 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x36 class: PseudoColor depth: 4 planes available colormap entries: 16 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 4 bits From mrs30@cam.ac.uk Tue, 21 Mar 2000 18:26:29 +0000 Date: Tue, 21 Mar 2000 18:26:29 +0000 From: Mark Shinwell mrs30@cam.ac.uk Subject: [SURVEX] More on xcaverot vs Digital Unix On Tue, Mar 21, 2000 at 12:50:48PM -0500, Phil Benchoff wrote: > On Tue, Mar 21, 2000 at 05:43:25PM +0000, Mark Shinwell wrote: > > P.S. I meant do xdpyinfo on the Digital box. Did the problem stop when turning > > double buffering off on the Linux or on the Digital box? > > Everything appears to work on the Linux box. > > Here is the output of xdpyinfo -queryExtensions on the Digital Unix > box: > (snip) Try this. In xcaverot.c insert the following line after line 1318: XColor col; and insert the following after the (new) line 1387 [ "&dbwinattr);" ]: XAllocNamedColor(mydisplay, color_map, "black", &col, &col); black = ind_bg = mybackground = col.pixel; XAllocNamedColor(mydisplay, color_map, "white", &col, &col); white = ind_fg = myforeground = col.pixel; See if that works... Mark -- Mark Shinwell -- President, Cambridge University Caving Club Queens' College, Cambridge, UK Mail: mrs30@cam.ac.uk Web: http://mrs30.quns.cam.ac.uk From leandro@dybal.eti.br Wed, 22 Mar 2000 15:27:47 -0300 Date: Wed, 22 Mar 2000 15:27:47 -0300 From: Leandro Dybal Bertoni leandro@dybal.eti.br Subject: xcaverot patch 2 This is a multi-part message in MIME format. --------------03B5A538CE299F44FC1E2AFA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This patch: - tides up the conditional code for the menu buttons (there where some ifdefs missing) - fixes the keyboard shortcuts - fixes the station markers color I hope that with this one the basic functionality of xcaverot is now working. Enjoy, Leandro --------------03B5A538CE299F44FC1E2AFA Content-Type: text/plain; charset=us-ascii; name="xcaverot-0.93-patch.2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xcaverot-0.93-patch.2" --- survex-0.93.1/src/xcaverot.c Tue Mar 21 13:23:26 2000 +++ survex-0.93.new/src/xcaverot.c Wed Mar 22 14:58:23 2000 @@ -103,6 +103,9 @@ #define BUTWIDTH 60 #define BUTHEIGHT 25 +/* length of cross station marker */ +#define CROSSLENGHT 3 + /* Width and height of compass and elevation indicator windows */ #define FONTSPACE 20 #define INDWIDTH 100 /* FIXME: allow INDWIDTH to be set dynamically - 50 is nice */ @@ -526,7 +529,11 @@ sprintf(temp, "%d m", (int)sbar); else sprintf(temp, "%d km", (int)sbar/1000); +#ifdef XCAVEROT_BUTTONS XDrawString(mydisplay, mywindow, slab_gc, 8, BUTHEIGHT+5+FONTSPACE, temp, strlen(temp)); +#else + XDrawString(mydisplay, mywindow, slab_gc, 8, FONTSPACE, temp, strlen(temp)); +#endif } /* FIXME: Zoom In -> In / Zoom Out -> Out ??? */ @@ -537,7 +544,6 @@ scale *= zoomfactor; changedscale = 1; flip_button(display, mainwin, button, egc, mygc, "Zoom in"); - draw_scalebar(); fill_segment_cache(); } @@ -548,7 +554,6 @@ scale /= zoomfactor; changedscale = 1; flip_button(display, mainwin, button, egc, mygc, "Zoom out"); - draw_scalebar(); fill_segment_cache(); } @@ -958,8 +963,10 @@ x2 = toscreen_x(p); y2 = toscreen_y(p); if (crossing) { - XDrawLine(display, window, gcs[srvy], x2 - 10, y2, x2 + 10, y2); - XDrawLine(display, window, gcs[srvy], x2, y2 - 10, x2, y2 + 10); + XDrawLine(display, window, gcs[lab_col_ind], x2 - CROSSLENGHT, y2, x2 + CROSSLENGHT, y2); + XDrawLine(display, window, gcs[lab_col_ind], x2, y2 - CROSSLENGHT, x2, y2 + CROSSLENGHT); + /* XDrawLine(display, window, gcs[srvy], x2 - 10, y2, x2 + 10, y2); + XDrawLine(display, window, gcs[srvy], x2, y2 - 10, x2, y2 + 10); */ } if (labelling) { @@ -986,7 +993,11 @@ else sprintf(temp, "%d km", (int)sbar / 1000); // FIXME: add BUTHEIGHT to FONTSPACE if buttons on +#ifdef XCAVEROT_BUTTONS + XDrawString(mydisplay, window, slab_gc, 8, BUTHEIGHT+5+FONTSPACE, temp, strlen(temp)); +#else XDrawString(mydisplay, window, slab_gc, 8, FONTSPACE, temp, strlen(temp)); +#endif } static void @@ -1212,14 +1223,12 @@ view_angle -= 360.0; /*dy = -dy; */ - /* U-D => scaling */ if (fabs((float)dy) <= 1.0) { a = 0.0; } else { a = log(fabs((float)dy)) / 3; } - if (dy <= 0) { /* mouse moved up or back to starting pt */ scale = rotsc_scale * pow(2, a); @@ -1228,14 +1237,11 @@ scale = rotsc_scale * pow(2, -a); } changedscale = 1; - draw_scalebar(); } - fill_segment_cache(); } #ifdef XCAVEROT_BUTTONS -// FIXME: void draw_buttons(Display * display, Window mainwin, GC mygc, GC egc) { @@ -1462,16 +1468,16 @@ ind_elev = XCreateSimpleWindow(mydisplay, mywindow, attr.width - INDWIDTH * 2 - 1, 0, INDWIDTH, INDDEPTH, 1, ind_fg, ind_bg); -#if 0 - scalebar = - XCreateSimpleWindow(mydisplay, mywindow, 0, BUTHEIGHT + 5 + FONTSPACE, - 23, attr.height - (BUTHEIGHT + FONTSPACE + 5), 0, - ind_fg, ind_bg); -#else +#ifdef XCAVEROT_BUTTONS scalebar = XCreateSimpleWindow(mydisplay, mywindow, 0, BUTHEIGHT+FONTSPACE+10, 23, - attr.height - (BUTHEIGHT + FONTSPACE + 10) -5, 0, ind_fg, - ind_bg); + attr.height - (BUTHEIGHT + FONTSPACE + 10) -5, 0, ind_fg, + ind_bg); +#else + scalebar = + XCreateSimpleWindow(mydisplay, mywindow, 0, FONTSPACE, + 23, attr.height - 5, 0, + ind_fg, ind_bg); #endif rot_but = XCreateSimpleWindow(mydisplay, mywindow, attr.width - INDWIDTH * 2 @@ -1638,7 +1644,8 @@ /* right button has been released => stop dragging cave about */ release_right_button(); } - } else if (myevent.type == ButtonPress) { + } + else if (myevent.type == ButtonPress) { orig.x = myevent.xbutton.x; orig.y = myevent.xbutton.y; #if 0 @@ -1680,7 +1687,6 @@ redraw = 0; } else if (myevent.xbutton.window == scalebar) { scale_orig = scale; - draw_scalebar(); } else if (myevent.xbutton.window == mywindow) { press_left_button(myevent.xbutton.x, myevent.xbutton.y); /* process_focus(mydisplay, mywindow, @@ -1698,7 +1704,8 @@ /* translate cave */ press_right_button(myevent.xbutton.x, myevent.xbutton.y); } - } else if (myevent.type == MotionNotify) { + } + else if (myevent.type == MotionNotify) { if (myevent.xmotion.window == ind_com) { int old_angle = (int)view_angle; @@ -1722,7 +1729,6 @@ ); changedscale = 1; - draw_scalebar(); } else if (myevent.xmotion.window == mywindow) { /* drag cave about / alter rotation or scale */ @@ -1730,7 +1736,7 @@ myevent.xmotion.y); } } - if (myevent.xany.window == mywindow) { + else if (myevent.xany.window == mywindow) { switch (myevent.type) { case KeyPress: { @@ -1775,6 +1781,7 @@ break; case 127: /* Delete => restore defaults */ set_defaults(); + fill_segment_cache(); break; case 'q': done = 1; @@ -1783,11 +1790,15 @@ elev_angle += 3.0; if (elev_angle > 90.0) elev_angle = 90.0; + fill_segment_cache(); + redraw = 1; break; case 'd': /* cave down */ elev_angle -= 3.0; if (elev_angle < -90.0) elev_angle = -90.0; + fill_segment_cache(); + redraw = 1; break; case 'l': /* switch to elevation */ switch_to_elevation(); @@ -1810,6 +1821,7 @@ if (scale < 0.001) { scale = 0.001; } + changedscale = 1; fill_segment_cache(); redraw = 1; break; @@ -1818,6 +1830,7 @@ if (scale > 0.4) { scale = 0.4; } + changedscale = 1; fill_segment_cache(); redraw = 1; break; @@ -1898,8 +1911,6 @@ myevent.xconfigure.width - INDWIDTH - 1, 0); XMoveWindow(mydisplay, ind_elev, myevent.xconfigure.width - (2 * INDWIDTH) - 1, 0); - - draw_scalebar(); break; } } --------------03B5A538CE299F44FC1E2AFA-- From olly@survex.com Mon, 27 Mar 2000 09:06:43 +0100 Date: Mon, 27 Mar 2000 09:06:43 +0100 From: Olly Betts olly@survex.com Subject: Error with Survex In message , "Peter Wilton-Jo nes" writes: >Please find attached an error that I obtained when trying to process this >attached data with Cavern >It says that the matrix did not invert. >I am using Survex 0.93 with windows 98. I have run it on two machines (both >98) and the same error occurred. Is it the data or is it an error? It's a bug in the program - you shouldn't be able to trigger that message whatever data you feed in. Unfortunately I'm now in Australia until June. Mike Lake has lent me an internet connection, but it's badly lagged to the UK. Maybe I can take a look while I'm over here, but otherwise I'm afraid the only workaround is to drop back to 0.91 (which isn't on www.survex.com any more - if anyone needs it mail me and I'll see what I can do). Cheers, Olly From wookey@aleph1.co.uk Mon, 27 Mar 2000 23:10:45 +0100 (BST) Date: Mon, 27 Mar 2000 23:10:45 +0100 (BST) From: Wookey wookey@aleph1.co.uk Subject: Ignore specific message patch This message is in MIME format. If you are reading this text, then your mail package doesn't fully support MIME - there may be a newer release available from your supplier. Created using the !Marcel mail package from ANT Ltd --3543563-971770350-954198645=:2031478333 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Here's a rather naff patch I just hacked up to solve a problem. It may be of use to others so I'm posting it. The way we structure our data (combined with the way another group structures its related data) means that we get a lot of 'fixed point already fixed at same co-ordinates' warnings. Also I remember immoh saying he got a lot of warnings that he'd like to be able to just turn off. So, I've added a *IGNOREMSG nn command which will mean that the message number given (you need to look them up in the messages.txt file) will just be ignored. This only works for errors generated at the time the file is being parsed, as the info goes in the begin/end structure. So messages that only come out at the end like 'station not attached to fixed point' can't (apparently) be turned off this way. The crummy implementation means you can only select one message - if anyone can be bothered, then making a short array, a list or a bitmap to hold the 'ignore these' numbers would be better. It's also just occurred to ne that you probably shouldn't be allowed to do this for fatal errors... The fact that it doesn't always do the trick got me thinking that what I really want to do is to be able to specify some fixed points as 'not necessarily used'. The most common being GPS locations. The obvious thing is the add a 'type' the the *FIX command *FIX GPS nnnn nnn nnn (GPS implies NOWARN as well as some SDs, perhaps) *FIX NORMAL nnn nnn nnn *FIX NOWARN nnn nnnn nnn but this changes the format of the command, which is bad. I'm not sure if we can easily allow both syntaxes - probably, in which case that would seem sensible. But maybe we should have a *GPS command, although that seems like gratuitious extra commands - *FIX already does what we want, it's just a matter of the details. Another approach to the problem would be a more general attribute mechanism which would have 'Don't warn about non-use' as one of the possibilities. I think I posted a list of attribute possibilities to this list a couple of months back, but didn't get much response. Maybe I'm just imagingin it? Anyway, suggestions as to what others want might suggest a sensible way to go. I can just hack something up for my own purposes, but unless it's too hard I might as well try and do it properly in a generically useful manner. Perhaps setting a general 'warning level' might be a good idea. Which warnings do people find a problem (apart from the two mentionned above)? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ --3543563-971770350-954198645=:2031478333 Content-Type: TEXT/Plain; NAME=commpatch Content-Transfer-Encoding: QUOTED-PRINTABLE diff -u survex-0.93.orig/src/cavern.h survex-0.93/src/cavern.h --- survex-0.93.orig/src/cavern.h=09Mon Mar 13 00:04:08 2000 +++ survex-0.93/src/cavern.h=09Mon Mar 27 20:30:14 2000 @@ -209,9 +209,10 @@ real Var[Q_MAC]; real z[Q_MAC]; real sc[Q_MAC]; real units[Q_MAC]; =20 datum *ordering; int begin_lineno; /* 0 means no block started in this file */ + int ignoremesg; /* warning/error to be ignored, should be a list, or bi= tmap?*/ struct Settings *next; } settings; =20 diff -u survex-0.93.orig/src/commands.c survex-0.93/src/commands.c --- survex-0.93.orig/src/commands.c=09Mon Mar 13 00:04:08 2000 +++ survex-0.93/src/commands.c=09Mon Mar 27 21:35:18 2000 @@ -140,6 +140,13 @@ } } =20 +static void +default_ignoremesg(settings *s) +{ + s->ignoremesg =3D 0; +} + + extern void default_all(settings *s) { @@ -152,13 +159,14 @@ default_grade(s); default_units(s); default_calib(s); + default_ignoremesg(s); } =20 =20 skipblanks(); @@ -232,11 +240,11 @@ } =20 typedef enum {CMD_NULL =3D -1, CMD_BEGIN, CMD_CALIBRATE, CMD_CASE, CMD_DAT= A, - CMD_DEFAULT, CMD_END, CMD_EQUATE, CMD_FIX, CMD_INCLUDE, CMD_INFER, + CMD_DEFAULT, CMD_END, CMD_EQUATE, CMD_FIX, CMD_IGNOREMESG, CMD_INCLUDE,= CMD_INFER, CMD_LRUD, CMD_MEASURE, CMD_PREFIX, CMD_SD, CMD_SET, CMD_SOLVE, CMD_TITL= E, CMD_TRUNCATE, CMD_UNITS } cmds; -=20 + static sztok cmd_tab[] =3D { {"BEGIN", CMD_BEGIN}, {"CALIBRATE", CMD_CALIBRATE}, @@ -246,6 +254,7 @@ {"END", CMD_END}, {"EQUATE", CMD_EQUATE}, {"FIX", CMD_FIX}, + {"IGNOREMSG", CMD_IGNOREMESG}, {"INCLUDE", CMD_INCLUDE}, {"INFER", CMD_INFER}, {"LRUD", CMD_LRUD}, =20 @@ -1013,18 +1022,28 @@ =09 } else { =09 ch =3D 'F'; =09 read_numeric(fFalse); -=09 NOT_YET;=09 =20 +=09 NOT_YET; =09 } } else { =09 ch =3D 'O'; =09 read_numeric(fFalse); -=09 NOT_YET;=09 =20 - } =20 +=09 NOT_YET; + } } /* for backward compatibility, "*truncate 0" means "*truncate off" */ pcs->Truncate =3D (truncate_at < 1) ? INT_MAX : truncate_at; } =20 +/* set message number to be ignored - 0 means don't ignore any */ +/* this is kind of primitive and should allow more than one skippable mess= sage */ +static void +set_ignoremesg(void) +{ + int mesgnum; + mesgnum =3D (int) read_numeric(fFalse); + pcs->ignoremesg =3D mesgnum; +} + extern void handle_command(void) { @@ -1054,8 +1073,9 @@ case CMD_SET: set_chars(); break; case CMD_TITLE: set_title(); break; case CMD_TRUNCATE: set_truncate(); break; + case CMD_IGNOREMESG: set_ignoremesg(); break; default: compile_error(/*Unknown command in data file - line ignored*/12); showandskipline(NULL, strlen(buffer)); - } =20 + } } diff -u survex-0.93.orig/src/datain.c survex-0.93/src/datain.c --- survex-0.93.orig/src/datain.c=09Mon Mar 13 00:04:08 2000 +++ survex-0.93/src/datain.c=09Mon Mar 27 20:38:21 2000 @@ -77,20 +77,26 @@ compile_error(int en, ...) { va_list ap; - va_start(ap, en); - error_list_parent_files(); - v_report(1, file.filename, file.line, en, ap); - va_end(ap); + if(pcs->ignoremesg !=3D en) + { + va_start(ap, en); + error_list_parent_files(); + v_report(1, file.filename, file.line, en, ap); + va_end(ap); + } } =20 void compile_warning(int en, ...) { va_list ap; - va_start(ap, en); - error_list_parent_files(); - v_report(0, file.filename, file.line, en, ap); - va_end(ap); + if(pcs->ignoremesg !=3D en) + { + va_start(ap, en); + error_list_parent_files(); + v_report(0, file.filename, file.line, en, ap); + va_end(ap); + } } =20 /* This function makes a note where to put output files */ --3543563-971770350-954198645=:2031478333-- From olly@survex.com Tue, 28 Mar 2000 07:50:45 +0100 Date: Tue, 28 Mar 2000 07:50:45 +0100 From: Olly Betts olly@survex.com Subject: Error with Survex >>It says that the matrix did not invert. > >It's a bug in the program - you shouldn't be able to trigger that message >whatever data you feed in. > >Unfortunately I'm now in Australia until June. Mike Lake has lent me an >internet connection, but it's badly lagged to the UK. Maybe I can take a >look while I'm over here, but otherwise I'm afraid the only workaround is to >drop back to 0.91 Actually there's a better way (sorry, I was a bit jet-lagged yesterday). You can use the '-z' debugging command line option to turn off certain network optimisations. The one you probably want it 'cavern -zd mysurvey.svx', but you can use any combinations of the letters 'l', 'p', and 'd' after the '-z'. Repeating letters has no effect. Order is unimportant. Cheers, Olly From olly@survex.com Tue, 28 Mar 2000 08:08:52 +0100 Date: Tue, 28 Mar 2000 08:08:52 +0100 From: Olly Betts olly@survex.com Subject: Error with Survex >The one you probably want it 'cavern -zd mysurvey.svx', but you can use any >combinations of the letters 'l', 'p', and 'd' after the '-z'. Repeating >letters has no effect. Order is unimportant. Tsk, not thinking straight here. The leters after z say which to use, not which to disable, so it's probably '-zlp' that you want (the default is all enabled: '-zlpd'; if you want to disable them all, you have to use '-z='. Cheers, Olly From leandro@dybal.eti.br Tue, 28 Mar 2000 11:10:41 -0300 Date: Tue, 28 Mar 2000 11:10:41 -0300 From: Leandro Dybal Bertoni leandro@dybal.eti.br Subject: Cavern 0.93 segfaults Hi, folks! cavern is segfaulting on one of my datasets. The point seems to be that I load the good data, solve it, and then load the bad data - it segfaults in articulate() on the second solve. I cut down the dataset to the minimal set that still shows this behavior and can mail it if someone wishes to replicate the bug. Cheers, Leandro From Survex@pennine.demon.co.uk Tue, 28 Mar 2000 12:46:05 BST Date: Tue, 28 Mar 2000 12:46:05 BST From: Andy Waddington on Survey stuff Survex@pennine.demon.co.uk Subject: Ignore specific message Wookey discusses fixes to turn off "Fixed point not used" and/or "point already fixed" errors. I think there is a philosophy error in Survex (!). Just because there is no survey fixed to a fixed point doesn't mean that a fixed point isn't used ! Maybe the fixed point was put in so that the (human) user could use it ? This is what I do all the time - I want the entrances shown, but not the surface survey which fixed them. So the entrance coordinates are all *FIXed from a previous run of Survex. The same could apply to any kind of useful landmark points fixed by neans outside's Survex's scope (like a professional land survey, or GPS coordinates). The user wants to know where they are, and wants them in the 3d file, but doesn't have any reason to connect a survey to them. I feel that *FIX should *never* generate a not used error, but perhaps we could invent a sensible name for a *FIX_AND_TELL_ME_IF_NOTHING_CONNECTS_HERE ... command Connected with the same problem that prompted Wookey to devise this hack is the "Point already fixed at the same coordinates" error. So what ? If I think the point is in the same place as I thought it was before, that's fine, just get on with it. If for some reason (and I can't imagine one at the moment) you actually want this warning, then we should invent a *FIX_UNIQUELY directive or something similar. Of course, if I am *FIXing something at _Different_ coordinates then I do want a warning. One workaround for the "fix not used" error is to add a zero-length survey leg to each fixed point - messy, but then it depends whether you are happier ignoring kludges in your data, or screeds of ignorable warnings. Ignoring warnings in transient output is not a problem, until there is a single error hidden somewhere in the great screed of warnings that scroll past. Andy From wookey@aleph1.co.uk Tue, 28 Mar 2000 18:18:21 +0100 (BST) Date: Tue, 28 Mar 2000 18:18:21 +0100 (BST) From: Wookey wookey@aleph1.co.uk Subject: Ignore specific message On Tue 28 Mar, Andy Waddington on Survey stuff wrote: > Wookey discusses fixes to turn off "Fixed point not used" and/or "point > already fixed" errors. > > I think there is a philosophy error in Survex (!). Just because there is no > survey fixed to a fixed point doesn't mean that a fixed point isn't used ! Back in the days when cave surveys were of one cave and you fixed an entrance location, this used to be a useful warning (warning you that you have put it the fixed point but forgotten to link to it). For the sort of multi-cave datasets we have now it's just a pain. So people using Survcex for simple dataset probably still find it useful. Anyone here still find it useful? > I feel that *FIX should *never* generate a not used error, > *FIX_AND_TELL_ME_IF_NOTHING_CONNECTS_HERE ... command Yes, I think the correct approach is to have modifiers for the *FIX commands, which set whether you want to be told if it's not used, and probably change the survex default to not tell you, and imply SDs. > Connected with the same problem that prompted Wookey to devise this > hack is the "Point already fixed at the same coordinates" error. > So what ? If I think the point is in the same place as I thought it > was before, that's fine, just get on with it. If for some reason > (and I can't imagine one at the moment) you actually want this > warning, then we should invent a > > *FIX_UNIQUELY directive or something similar. > > Of course, if I am *FIXing something at _Different_ coordinates then > I do want a warning. I agree - this is completely pointless - unless someone can thing of a good reason we should just get rid of this warning, or at least relegate it to '--fussy' status. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From John.Halleck@utah.edu Tue, 28 Mar 2000 11:25:02 -0700 (MST) Date: Tue, 28 Mar 2000 11:25:02 -0700 (MST) From: John Halleck John.Halleck@utah.edu Subject: Ignore specific message On Tue, 28 Mar 2000, Andy Waddington on Survey stuff wrote: > Date: Tue, 28 Mar 2000 12:46:05 BST > From: Andy Waddington on Survey stuff > To: survex@survex.com > Subject: re: Ignore specific message > > Wookey discusses fixes to turn off "Fixed point not used" and/or "point > already fixed" errors. My personal opinion, though nobody asked, is that the first is not intrinsicly an error, but a warning note that you should be able to choose or not. The second seems to be serious... and I think I'm missing why the data should have this problem. (If someone could enlighten me [possibly by private email instead of the list] I'd appreciate it.] I think I much agree with what Andy Waddington wrote, which I'll mostly delete from this reply. > I think there is a philosophy error in Survex (!). In recent conversation with Olly Betts, he made statements about possibly making the changes to the way fixed points were handled, since in this day of GPS you might have several GPS fixed points, and they have uncertainty that would have to be accounted for... So... I suspect that the discussion might become a lot more interesting when Olly gets back... > [... Much Andy Waddington text removed ...] > One workaround for the "fix not used" error is to add a zero-length survey > leg to each fixed point - messy, but then it depends whether you are happier > ignoring kludges in your data, or screeds of ignorable warnings. Ignoring > warnings in transient output is not a problem, until there is a single error > hidden somewhere in the great screed of warnings that scroll past. In the standard (Matrix, Normal) equations, it is possible to deal with multiple (weighted) fixed points rather trivally. Since that is the matrix that the Cholesky Factorization in servex is being done on, I don't see why adding zero length survey legs would be usefull. (Except for some explainitory purposes.) But if someone could explain this to me (possibly privately) I'd be willing to become educated. > Andy > -- > Survex http://lists.tartarus.org/mailman/listinfo/survex ------------------------------------------------------------- Fat ugly cavers R us: http://www.cc.utah.edu/~nahaj/ From wookey@aleph1.co.uk Tue, 28 Mar 2000 20:11:03 +0100 (BST) Date: Tue, 28 Mar 2000 20:11:03 +0100 (BST) From: Wookey wookey@aleph1.co.uk Subject: Ignore specific message On Tue 28 Mar, John Halleck wrote: > On Tue, 28 Mar 2000, Andy Waddington on Survey stuff wrote: > > > Date: Tue, 28 Mar 2000 12:46:05 BST > > From: Andy Waddington on Survey stuff > > To: survex@survex.com > > Subject: re: Ignore specific message > > > > Wookey discusses fixes to turn off "Fixed point not used" and/or "point > > already fixed" errors. > > My personal opinion, though nobody asked, is that the first is not > intrinsicly an error, but a warning note that you should be able > to choose or not. Agred, but should it be chosen as a 'warning level' a-la compilers )specific to a run), or as a feature of the dataset (specific to particular points in a dataset), or both/either? > The second seems to be serious... and I think I'm missing why > the data should have this problem. (If someone could enlighten me > [possibly by private email instead of the list] I'd appreciate it.] It happens if (for example) you have an overall file that fixes all the entrance locations, but you also have the fixes in indivdual cave overview files (because they want to be able to generate them on their own with real-world co-ordinates, and don't like all the 'Fixed point not used' warnings they get doing it the other way :-). Having them in two places causes a maintainance problem, but in fact, stepping back even further, the only reason we do it this way is because we need to separate surface an underground data for diplay purposes, but we want to preserve the entrance location derived from the full dataset even when only processing partial datasets. Once we have a mechanism for toggling display of surface legs (new 3d format) then we can always just run the whole dataset and this 'problem' will disappear. (the 'unused point' one won't though. > In recent conversation with Olly Betts, he made statements about possibly > making the changes to the way fixed points were handled, since in this > day of GPS you might have several GPS fixed points, and they have uncertainty > that would have to be accounted for... The *FIX syntax already allows for X,Y,Z SDs to be specified after the co=ordinates, but this info is not yet used. Presumably you were discussing the sums implementation. I'm really just thinking about the data-format/user interface implementation. Thinking about it I'm not sure that this is the right answer, as I don't want to have to specify 3 extra numbers on every single GPS entry. I just want to say they are GPS entries and get a ensible default, or perhaps even specify a GPS entry and a time (SDs decrease with time of logging), or some other quality indicator. I suppose what this amounts to is DATA styles for points as well as legs....maybe that's the way to go. > So... I suspect that the discussion might become a lot more interesting > when Olly gets back... yes, but in the meantime we can establish what we think is correct behaviour/what problems people have/relevant features they would like. So long as said features don't include any sums then other people are capable fixing the code accordingly (I avoid the bits with the sums in like the plague!) > > One workaround for the "fix not used" error is to add a zero-length > > survey leg to each fixed point - messy, but then it depends whether > > you are happier ignoring kludges in your data, or screeds of > > ignorable warnings. Ignoring warnings in transient output is not a > > problem, until there is a single error hidden somewhere in the great > > screed of warnings that scroll past. > > In the standard (Matrix, Normal) equations, it is possible to deal with > multiple (weighted) fixed points rather trivally. Since that is the > matrix that the Cholesky Factorization in servex is being done on, I don't > see why adding zero length survey legs would be usefull. (Except for > some explainitory purposes.) It's useful because it stops the error saying you didn't use the fixed point, even though you used it in a manner which reduces to exactly what you had before. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From John.Halleck@utah.edu Tue, 28 Mar 2000 12:56:06 -0700 (MST) Date: Tue, 28 Mar 2000 12:56:06 -0700 (MST) From: John Halleck John.Halleck@utah.edu Subject: Ignore specific message On Tue, 28 Mar 2000, Wookey wrote: > [...] > > In recent conversation with Olly Betts, he made statements about possibly > > making the changes to the way fixed points were handled, since in this > > day of GPS you might have several GPS fixed points, and they have uncertainty > > that would have to be accounted for... > > The *FIX syntax already allows for X,Y,Z SDs to be specified after the (And hopefully the XY, YZ, and XY STD's?) > co=ordinates, but this info is not yet used. Presumably you were > discussing the sums implementation. I'm really just thinking about the > data-format/user interface implementation. I'm much interested in the underlying maths, but not much in the data-format/user-interface issues... So I suspect I won't have much usefull to add to the discussion. > Thinking about it I'm not sure that this is the right answer, as I don't > want to have to specify 3 extra numbers on every single GPS entry. I just There are six numbers... Since this is a 3D problem and not three 1D problems... But I'm being nitpicky. > want to say they are GPS entries and get a ensible default, or perhaps > even specify a GPS entry and a time (SDs decrease with time of logging), > or some other quality indicator. There is a goodly deal of information availiable on the accuracy of GPS measurements. I have no doubt that some general purpose defaults could be agreed upon. > I suppose what this amounts to is DATA styles for points as well as > legs....maybe that's the way to go. > > So... I suspect that the discussion might become a lot more interesting > > when Olly gets back... > > yes, but in the meantime we can establish what we think is correct > behaviour/what problems people have/relevant features they would like. So > long as said features don't include any sums then other people are > capable fixing the code accordingly (I avoid the bits with the sums in > like the plague!) Good point. > [...] From jose@matcom.uh.cu Tue, 28 Mar 2000 16:34:41 -0500 Date: Tue, 28 Mar 2000 16:34:41 -0500 From: =?iso-8859-1?Q?Jos=E9_Luis_Casta=F1eda_Lorenzo?= jose@matcom.uh.cu Subject: We need some help This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BF98D3.845249D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We are two Cuban students in Computer science, and our thesis is a = program that map caves and we need some information about polygonal = closures algorithms. We try to find some information on internet but we = can find anything. Please if you can help us, we appreciate your help. Thanks This is our email address jose@matcom.uh.cu and jeffymildrey@yahoo.com=20 Ludwig and Jose Luis. ------=_NextPart_000_000B_01BF98D3.845249D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We are two Cuban students in Computer science, and our thesis is a = program=20 that map caves and we need some information about polygonal closures = algorithms.=20 We try to find some information on internet but we can find = anything.

Please if you can help us, we appreciate your help.

Thanks

This is our email address jose@matcom.uh.cu and jeffymildrey@yahoo.com

Ludwig and Jose Luis.

------=_NextPart_000_000B_01BF98D3.845249D0-- From wookey@aleph1.co.uk Wed, 29 Mar 2000 13:59:28 +0100 (BST) Date: Wed, 29 Mar 2000 13:59:28 +0100 (BST) From: Wookey wookey@aleph1.co.uk Subject: We need some help On Tue 28 Mar, Jos=E9_Luis_Casta=F1eda_Lorenzo wrote: > We are two Cuban students in Computer science, and our thesis is a > program that map caves and we need some information about polygonal > closures algorithms. We try to find some information on internet but > we can find anything. Welcome. > Please if you can help us, we appreciate your help. There are a couple of resources I am aware of. By far the best is John Halleck's (unfunished, but still useful) work: http://www.cc.utah.edu/~nahaj/cave/survey/changes.html which starts with the basics and principles and describes the corresponding maths. Some example programs are also provided. The only other info on-line is a few old (and probably rather outdated) bits and bobs used in the authouring of survex on the Cave Surveying Groups site at: http://www.sat.dundee.ac.uk/~arb/surveying/ This gives a basic reduction algorithm, and some instrument error sums. The Survex source provides a useful engine for processing data which you may find useful as either a reference or a starting point. It is the only existing survey reduction engine that uses co-variance info (apart from John Halleck's demo code). You might find some stuff of interest in the Cave Surveying Groups journals' which are online up to about a year ago. http://www.chaos.org.uk/survex/cp/index.htm You might also want to join the Cave surveying Group, as we are keen to have interested members from all nations. Details are on the web page. One other resource is the cave-surveying mailing list, which has a more technical and wider-based readership than the survex mailing list which you posted to. They are both hosted on the same site. Wookey --=20 Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From John.Halleck@utah.edu Wed, 29 Mar 2000 08:50:42 -0700 (MST) Date: Wed, 29 Mar 2000 08:50:42 -0700 (MST) From: John Halleck John.Halleck@utah.edu Subject: We need some help On Wed, 29 Mar 2000, Wookey wrote: > [... pointing them to my article ...] I *REALLY* need to get back to that project... > The Survex source provides a useful engine for processing data which you > may find useful as either a reference or a starting point. It is the only > existing survey reduction engine that uses co-variance info (apart from > John Halleck's demo code). And my demo code is not complete... Picky point: There are lots of engines that compute full 3D weights from the full covariance matrix. *BUT* there aren't many that are non-commercial, and therefore there are not many publicly availiable. There are also any number of books (for surveyors) that cover the subject in almost painfull detail. I have some bibliography at: http://www.cc.utah.edu/~nahaj/cave/survey/bibliography.html The one I've found clearest is "Analysis and Adjustment of Survey Measurements" by Mikhail and Gracie. From olly@survex.com Wed, 29 Mar 2000 18:16:57 -0800 Date: Wed, 29 Mar 2000 18:16:57 -0800 From: olly@survex.com olly@survex.com Subject: Cavern 0.93 segfaults Leandro Dybal Bertoni wrote: > Hi, folks! > > cavern is segfaulting on one of my datasets. > > The point seems to be that I load the good data, solve it, and then load > the bad data - it segfaults in articulate() on the second solve. Hmm, I wonder if the articulation code is failing to reset some static state on the second run. Sadly there's no easy workaround if that is the problem (other than not using *fix). > I cut down the dataset to the minimal set that still shows this behavior > and can mail it if someone wishes to replicate the bug. Send a copy my way, though I doubt I can do much about it until I get back to the UK (in June). Cheers, Olly ______________________________________________________ Get your free web-based email at http://www.xoom.com Birthday? Anniversary? Send FREE animated greeting cards for any occasion at http://greetings.xoom.com